Understanding the software supply chain security requirements in the cybersecurity Executive Order

President Biden’s cybersecurity executive order from last month should cause little surprise for anyone following news headlines over the past year. The order is the U.S. Federal Government’s important response to a long list of incidents, starting with the SolarWinds attack and ending with a recent ransomware attack against Colonial Pipeline — the largest known attack against a US energy firm.

Considering the fact that many of the recent attacks are software supply chain-related, it is also not surprising that software security, specifically software supply chain security, is a recurring theme across the order. The now-notorious SolarWinds attack affected a long list of government agencies, including the U.S. Pentagon, Department of State, Department of Homeland Security, together with private organizations like Microsoft, Intel, and Cisco, and brought the topic of software supply chain security to the fore.

Software supply chain attacks are not new. At Snyk, we’ve been talking about modern software development and composition being a weak link and potential conduit of malware distribution since 2018. But they are becoming more and more popular among attackers due to some noticeable changes in the way software applications are built today. President Biden’s order recognizes these changes and aims at minimizing the risk they pose by directing the Commerce Department to create strict standards for companies selling software to the Federal Government.  

What are software supply chain attacks?

In a software supply chain attack, attackers access and modify the software in the complex software development supply chain to be able to compromise a downstream target by inserting their malicious code. A software supply chain attack is not the end goal. It is used to open a window of opportunity for an attacker to insert malware or provide a backdoor for future access. In the SolarWinds attack, for example, hackers managed to access SolarWinds’ network and applications monitoring platform, Orion, to distribute malicious updates to the software’s thousands of users.

Software supply chain attacks are an extremely effective attack vector because of the way modern software is built. As with industrial supply chains, the software supply chain includes planning, supply of materials, manufacturing, and retail. Instead of materials, the software supply chain relies on code. This code can be proprietary but a growing portion is increasingly sourced from suppliers, commercial or open source. These dependencies can be used to insert malicious code into the software. Code is used to develop software, and in the modern software supply chain, development involves an ever-growing number of processes that can each be leveraged for the effective distribution of malware.

Federal requirements for software supply chain security

President Biden’s executive order calls for modernizing the Federal Government’s cybersecurity, better communication and collaboration on cybersecurity between the Federal Government and the private sector, and tighter security of the software purchased by the Federal Government. The risk posed by software supply chain attacks is clearly articulated at the beginning of section 4 of the order:

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... Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain...

Aiming to protect government agencies from this risk, the order calls for NIST to establish best practices, guidelines, and criteria for the future standards that software suppliers will need to comply with to be able to sell software to the Federal Government.

Software Bill of Materials (SBOM)

While a small amount of the code that makes up software is developed in-house from scratch, most of it is sourced using open source or third-party components. The order’s requirement for a Software Bill of Materials (SBOM)recognizes this fact, pointing to the need for better transparency as to what exactly is included within a piece of software to be able to mitigate the risk of software supply chain attacks.  

Secure development environment

Software suppliers will be required to attest to a secure development environment. The order calls for the formulation by NIST of criteria by which a development environment would be considered secure, including secure build processes, data encryption, auditing, authentication, and incident monitoring and management.

Secure development processes

Software suppliers will also be required to adhere to secure development practices and be able to attest to measures taken. This includes the use of automated security testing early on and during development for ensuring the integrity of code and finding and fixing vulnerabilities. “Artifacts” attesting to software development, and the execution of the tools and processes used, need to be available upon request.

Open source integrity

Commonly, 80-90% of the code making up an application is open source code. Acknowledging this reality, the order requires software suppliers to “ensure and attest to the integrity and provenance of the open source software used within any portion of a product”.

Improving software supply chain security

Preparing for the NIST guidelines by hardening your software supply chain starts with tighter application security. Providing a developer-first cloud native application security platform, Snyk supports the vast majority of the requirements outlined in the order.

Empowering developers

The successful implementation of secure development practices called for in the executive order depends on developers being able to easily integrate security into their development workflow. Secure development starts with the developers themselves. Developers are the ones deciding how to build their applications and ultimately, are also responsible for the integrity, quality, and security of their code. Traditional security models, integrating late in the development process and adding friction with unintuitive workflows, are no longer an option in a fast-paced development environment.

Snyk’s approach is to empower developers with developer-friendly tooling and proper guidance from the security team. The Snyk platform was designed to provide developers with a tool they actually enjoy using, a tool that acts and looks like any other developer tool in their toolkit, and that does not slow them down.

Automated security across the SDLC

To ensure the integrity of software early on in the software development process, the executive order calls for early implementation of automated security testing, “...which shall operate regularly, or at a minimum before product, version, or update release”. Snyk’s customers use a variety of available integrations, as well as the Snyk API, to automate security testing across the different stages of the software development process. This starts as early as within the developer’s local development environment, continues through Git-based workflows, the build process, and ends with the production environment. 

Securing ALL the code making up modern software

The executive order acknowledges the fact that the code making up an application has changed. Proprietary code, open source packages, containers, and the code responsible for provisioning cloud infrastructure (infrastructure as code) — these are the materials used in the modern software supply chain.

To enable organizations to manage and mitigate this new risk profile, a more holistic application security approach is required. Security teams focused on Static Application Security Testing (SAST) tools to secure the code their development teams are writing are ignoring the risk open source and container usage introduces, and vice versa — Software Composition Analysis (SCA) tools do not provide coverage for proprietary code. Snyk’s platform provides a comprehensive, developer-first solution, helping organizations secure all the code making up modern software.

Attestation and component-level reporting

As described above, providing transparency to the Federal Government about the processes and measures put in place as well as the materials used to build software in the form of an SBOM play a dominant part in the requirements stipulated in the executive order. Snyk provides extensive reporting capabilities to enable the viewing and exporting of an SBOM as well as other types of reports. Snyk’s customers also leverage the Snyk API to automatically integrate into third-party reporting and vulnerability management tools for continuous monitoring of the organization’s security and compliance posture.

Looking ahead

The order calls for the NIST to publish preliminary guidelines within six months, and final guidelines within a year.  While the requirements in the order are aimed at companies selling to the Federal Government, the standards will likely trickle down into the private sector and affect the software market as a whole.

It would be prudent to start planning by first closely examining the order and identifying major gaps with your existing software supply chain.

At Snyk, we will be tracking the evolution of guidelines as they are introduced by NIST and will follow up with additional information on our blog so stay tuned. We are also actively participating in NIST efforts to comply with the executive order, specifically around SBOM specifications via the SBOM SIG.

To learn more about how Snyk is helping government agencies meet the requirements of this order, please contact us at snyk_federal@snyk.io or visit our Snyk for Government webpage.