Latest Cybersecurity Executive Order Requires an SBOM

On Wednesday, May 12, 2021, President Biden’s new and much-expected Executive Order on Improving the Nation’s Cybersecurity was published. This new executive order (EO) includes a major element outlining new guidelines for how US federal government programs are to interact with industry software suppliers and partners, moving forward.  

There are many notable improvements throughout the EO, but one area we at Anchore find particularly interesting, and timely, is around emerging requirements for sharing software bill of materials (SBOM) information when software is being delivered across organizational boundaries. Anchore believes that this is an important step toward defending against security incidents that use a software supply chain attack method – where an attacker infiltrates a software supplier ‘somewhere in the chain’ to either introduce or uncover an exploitable flaw, and then implements the attack against the end consumer of the software, who has deployed the compromised supplier software element in production. 

Presently, one area of weakness that can lead to a successful supply chain attack stems from the reality that there is often very little transparency between suppliers and consumers on exactly what software is included within a deliverable, and what software development/security practices are being performed by the supplier in the process of generating the deliverable. If this weakness were to be addressed between all participants of a given supply chain, it becomes possible for each organization to perform more comprehensive security checking and evaluation at each organizational boundary, increasing the overall security coverage of the supply chain. The foundational element that can be used for this purpose of sharing adequate information when delivering software between organization boundaries is the software bill of materials (SBOM).

Understanding the SBOM

An SBOM, referenced as such directly within the EO, is a document attached to a software deliverable that includes rich information about the software itself, and also importantly contains information about the software’s bundled dependencies. One thing the EO didn’t cover explicitly pertains to containers specifically, where an SBOM generated from a container image deliverable also contains additional information about the system packages inside the container itself, included in support of the application but not necessarily explicitly defined as a dependency of the application code, itself.

Besides just software names and versions, each software element has important metadata that may become an SBOM requirement:

• The software origin/maintainers
• Commercial and/or open source licenses
• Digital signatures/hashes of executable software and/or data/configuration files

Security vulnerability scanning tools and security engineering teams use SBOM data to:

• Perform vulnerability scans, matching SBOM elements against known/emerging software vulnerabilities
• Perform quality assurance checks using SBOM element versions to determine version status and other health characteristics
• Perform license compliance and conformance checks for OSS and commercial licenses (and combinations) for included SBOM elements 

Next Steps

Within sixty days from the May 12, 2021 release of the EO, the federal government will publish minimum elements for an SBOM.  Our recommendation is to take this time to consider where in your DevOps or DevSecOps pipelines you’ll be consuming SBOMs and using them for vulnerability, license, and compliance checks. In addition, this is the time to be considering the tools and processes that you need to put in place to produce SBOMs and how you’ll provide SBOMs to your compliance auditors and other consumers.

Also important for any organization taking part in a supply chain are that some larger organizations today require suppliers to provide elements when defining contracts around software purchasing. For example, OSS licenses and the requirement for communicating security practices guidelines from supplier to consumers. We at Anchore believe it’s becoming more commonplace practice to transmit detailed information between all organizations within a given supply chain from small/medium/large OSS project maintainers and distribution vendors, to companies providing proprietary software.

Bolstering software supply chain information quality requires all actors to participate, by taking these first necessary steps to integrate SBOM generation into existing development and publication practices.