A Closer Look at the Software Supply Chain Requirements in the Cybersecurity Executive Order

Software security is a big focus of the Biden administration’s recent executive order on cybersecurity. In fact, an entire section, or 25 percent, of the order is dedicated to software security requirements. In the wake of the SolarWinds cyberattack, the security of the software supply chain is clearly top of mind at the White House, and has prompted these unprecedented and detailed security requirements for any software vendor looking to do business with the federal government. The order states:

The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions.  The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.  There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended.  The security and integrity of “critical software” — software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) — is a particular concern.  Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.

How will the requirements be developed, and what do they cover?

The order mandates that NIST will identify existing or develop new standards for software security that “shall include criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.” NIST has 180 days to publish the preliminary guidelines, so we expect to see them before the end of the year.

Once the preliminary guidelines are published, NIST will then, within 60 days, issue guidance on best practices for securing the software supply chain (most likely early 2022). This guidance must include standards for:

• Secure software development environments
• Generating proof of adherence to the standards
• Employing automated tools to “ensure the integrity of code”
• Employing automated tools to check for vulnerabilities and remediate them
• Generating proof of the results of the automated tools’ findings
• Maintaining data on the origins of all software code
• Providing a software bill of materials
• Participating in a vulnerability disclosure program
• Attesting to conformity with secure software development practices
• Ensuring the integrity of open source software in use

The order covers both new software purchases, and a review of existing legacy software.

There will also be guidance coming on what constitutes a software bill of materials and what should be considered “critical software.”

Finally, the order requires the development of a pilot program that will examine a security labeling and rating system for consumer software products, including IoT devices.

What’s notable?

SBOM requirement: The requirement to provide a software bill of materials for each software product is a notable acknowledgement of the reality of modern software – very little of it is created from scratch, in-house. Just as requirements surrounding nutrition and ingredients labeling evolved over time as food products became more complicated and awareness of health risks increased, the government is now mandating transparency about what is in software as awareness of the security risks has increased.

Open source inclusion: As with the SBOM requirement, this inclusion acknowledges another reality of modern software – much of it is built on open source libraries, most of which contain vulnerabilities. In fact, our recent research found that 70 percent of applications contain a vulnerability in an open source library. This requirement highlights the fact that organizations today can’t call their software secure without assessing the security of the open source components of their applications.

Security testing specifics: This order gets more specific about software security testing than we had anticipated. It requires using automated tools (or comparable processes) that check for both known and potential vulnerabilities and remediate them. It also notes that the tools should operate regularly, or at least before product, version, or update releases. In the SaaS and PaaS world, this will mean these tools will need to become part of the development process and execute in the pipeline on each build since they often operate with continuous delivery. The emphasis on remediation is also important; we talk to a lot of organizations that feel like they’ve checked the software security box if they are testing their code. In reality, testing just reveals the problem, it doesn’t fix it.

The order also indicates that, within 60 days, NIST will publish guidelines recommending minimum standards for software security testing, including recommended types of testing, such as static and dynamic analysis, software composition analysis, and pen testing. This level of specificity is also important, since there is no software security silver bullet. All these testing types identify different types of vulnerabilities at different stages of the development process, and neglecting any of them widens your threat landscape. For instance, static analysis won’t find authorization issues or business logic problems, but dynamic analysis can’t point to the line of code where a vulnerability originates.

Development environment security: There has been a realization that the environment software is developed in has to have equal or greater security controls than the environment the software operates in. Critical software operated in the most restricted and controlled environments is often developed in environments with weak security controls.

IoT security: This is perhaps the most groundbreaking and far-reaching inclusion in the order. The order requires the development of pilot programs for IoT and consumer software security that will be “informed by existing consumer product labeling programs to educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices, and shall consider ways to incentivize manufacturers and developers to participate in these programs.” Recent legislation created requirements around the security of IoT devices purchased by the U.S. federal government, and Singapore and the UK have voluntary programs for labeling IoT. This executive order suggests that this type of regulation may expand to the U.S. consumer market. Consumers of software and IoT devices haven’t to this point overwhelmingly demanded that vendors create secure products, and haven’t been deterred by security, or a lack thereof, when purchasing. But as recent DDoS attacks perpetrated through IoT devices highlight, these interconnected devices create a wide and very dangerous attack surface. Establishing some requirements and transparency around the security of these consumer devices is overdue.

For more information on the executive order, see our previous blog post on the topic, and stay tuned for more posts in the coming days and weeks.