A Look Back at the Executive Order on Cybersecurity

It has officially been one year since the release of the Biden administration’s Executive Order on Cybersecurity, which outlines security requirements for software vendors selling software to the U.S. government.  These requirements include security testing in the development process and a software bill of materials for the open-source libraries in use so that known vulnerabilities are disclosed and able to be tracked in the future, among other things.

The Executive Order – put into motion following the cyberattacks on government agencies through software from SolarWinds and Microsoft – calls on the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) to establish the security initiatives necessary to meet the requirements in a given timeframe.

As we’ve seen over the past twelve months, NIST has met most of the timelines. So far, NIST has:

• Defined critical software
• Published guidance outlining security measures for critical software
• Published guidelines recommending minimum standards for vendors’ testing of their software source code  
• Issued preliminary guidelines for enhancing software supply chain security
• Identified IoT cybersecurity criteria for a consumer labeling program 
• Identified secure software development criteria for a consumer software labeling program

NIST still needs to:

• Issue additional information about its software supply chain guidance plans, including review and update procedures
• Provide the President with a report that reviews the progress made and additional steps needed to secure the software supply chain
• Submit a summary of what improvements can be made going forward

To commemorate the one-year anniversary, we interviewed our CTO and Co-Founder, Chris Wysopal, to get his take on how the Executive Order is going so far and what he envisions for the future.

One of the most important developments to come out of the Executive Order is “the updates to the Secure Software Development Framework”

When we asked Chris what he considers to be the most important aspect of the Executive Order, he quickly responded, “the updates to the Secure Software Development Framework (SSDF).” The updates to the SSDF, published by NIST and based on feedback solicited from the software security community, explicitly address secure software development practices in detail, mapping specific requirements from the EO into a practical tool that organizations can use to help ensure compliance. It’s no longer just “recommendations” or “good stuff to do.” There are now “concrete mappings in place” telling suppliers of the federal government exactly what they need to do to be compliant with the Executive Order.

“The next phase is actually putting things into motion”

“Now that guidelines and requirements have been established, the next phase is actually putting things into motion,” says Chris. “We can expect to see updated contracts and specific, detailed requests from federal agencies to vendors for everything from secure development environments to all digital components and their dependencies in their software. Recent attention on a software bill of materials (SBOM), or providing a certified ‘list of application ingredients,’ will be a necessary requirement for suppliers providing software to the U.S. government."

AppSec vendors have already started to make adjustments to help out suppliers. For example, you can now generate an SBOM with Veracode Software Composition Analysis. Veracode’s SBOM API response provides an inventory of the components within an application, including insight into the relationships that the various components have with each other and identifying which components are coming from third-party sources that make up the software supply chain. The SBOM API returns a response with the SBOM in CycloneDX JSON format, which is one of the approved formats for compliance with the U.S. Executive Order.

“The drivers that initially propelled the issuance of the Executive Order last year have only intensified”

“The drivers that initially propelled the issuance of the Executive Order last year – SolarWinds and Microsoft Exchange – intensified after the recent Log4j vulnerability which impacted the majority of Java users,” said Chris.

Veracode data showed that 95 percent of our customers with over 100 applications use Java, and 88 percent use some version of Log4j. Of that 88 percent, 58 percent use a vulnerable version of Log4j. Customers with software composition analysis (SCA) were able to quickly find and fix the vulnerability before an exploit. Customers without SCA hopefully viewed this as a wake-up call because, as we've seen from data in Veracode’s State of Software Security: Open-Source Edition, there is still a long way to go in getting organizations to adopt third-party scanning tools.

Our recent open-source SOSS report found that nearly 80 percent of the time, developers never update third-party libraries once they’ve been built into a codebase. The worst part is that 92 percent of flaws in third-party libraries can be fixed with an update. Once we start enforcing the Executive Order, the number of vulnerabilities in software provided to the U.S. government should drop significantly.

“Software security is no longer a ‘nice to have;’ it’s a federal requirement”

Chris explained that “As a result of the Executive Order, software security is no longer a ‘nice to have;’ it’s a federal requirement. Much in the same way seatbelts became federally mandated in cars, all organizations will eventually implement these practices and adhere to the standards for improved software safety and security for all citizens.”

In other words, all software vendors should be paying attention to the Executive Order, not just those who provide software to the U.S. federal government, because the EO will eventually trickle down to the private sector.

Whether you supply software to the U.S. government or not, you should start taking a serious look at your application security program. Make sure that you have testing tools in place for the entire software development lifecycle – ideally automated and integrated into your developer’s existing tools and processes. Stay on top of your open-source risk with a software composition analysis tool and SBOMs. Lastly, if you’re not already doing so, train your developers in secure coding.

Software security requirements are here to stay. Find an AppSec vendor committed to helping you comply with the requirements and stay up to date on the Executive Order.