The release of Executive Order 14028 in May 2021 put the term “Software Bill of Materials” (SBOM) into daily vernacular. But why is it so important that every company should have one?
Executive Order (EO) 14028 introduced new regulations for companies supplying products or services containing software to U.S. government agencies. The order directed the U.S. National Telecommunications and Information Administration (NTIA) to publish a set of minimum requirements for an SBOM, which it did in July 2021. If this seems fast, that’s because it was. But that’s in part because the NTIA has been working since 2018 to define and publish these standards. In some ways, the EO just made the work this team had been doing official.
An SBOM is a tool used when building mature security models. As the industry moves from a DevOps to a DevSecOps model, building and maintaining accurate SBOMs is a crucial step to securing the software supply chain. An SBOM lists all the open source and third-party components in a codebase as well as the component versions and the licenses that govern those components.
While the SBOM standards and best practices outlined in EO 14028 will technically only apply to federal departments and agencies and their technology suppliers, it is likely that — where practicable — they will also be adopted by broader categories of buyers and suppliers across critical infrastructure as a “North Star” for security expectations. In addition, the EO leverages the government’s procurement process and contractual language to drive compliance — a model that could be adopted in the commercial sector.
“This particular Executive Order recognizes that what we’ve been doing, and the pace at which we’ve been doing it, clearly isn’t working. We just need to look at all of the cyberincidents we see on the evening news. This EO recognizes that something different needs to happen, and is effectively a call to arms.”
The 2021 Building Security In Maturity Model (BSIMM) Report findings indicate that software risk is business risk, and to effectively manage business risk, companies must address software risk. Any organization that builds software needs to maintain an SBOM for its applications because organizations typically use a mix of custom-built code, commercial off-the-shelf code, and open source components to create software. If organizations don’t know what they have in their applications, they won’t be able to address areas of vulnerability as they are disclosed.
The BSIMM12 report also highlights how companies are responding to the increase in supply chain and ransomware attacks. From malicious supply chain breaches like SolarwindsOrion, to cyberattacks like the one that hit Schreiber Foods in October 2021 and disrupted the nation’s cream cheese supply just before the holiday season, it is increasingly clear that every business is a software business.
The report outlines three categories of security activity that companies in the BSIMM community have adopted over the last year. A key activity is securing the software supply chain, which starts with building and maintaining an accurate SBOM. The concept of an SBOM derives from manufacturing, where a Bill of Materials is an inventory detailing all the items required to create a product. In the automotive industry, for example, manufacturers maintain a detailed Bill of Materials for each vehicle. The BOM lists parts built by the original equipment manufacturer itself as well as parts from third-party suppliers. When a defective part is discovered, the auto manufacturer knows precisely which vehicles are affected and can notify vehicle owners of the need for repair or replacement.
The SBOM guidelines in Executive Order 14028
It’s important to remember that the guidance released in July describes the minimum regulatory elements. Your security teams should expect the guidelines around SBOM regulatory compliance to continue to develop. For now, though, the NTIA has defined the minimum elements of an SBOM, and has organized those elements into the following three categories:
- Data fields
- Automation support
- Practices and processes
Data fields
Data fields capture and maintain baseline data about each component so that it can be tracked across the software supply chain. This allows you to map the component to other sources of useful data, like vulnerability or license databases.
The minimum required data fields are:
- Supplier name
- Component name
- Component version
- Other unique identifiers
- Dependency relationship
- Author of SBOM data
- Timestamp
While this information seems pretty basic, it can be surprisingly complicated to capture. Product names, for example, can be obscured by any number of issues, from mergers and acquisitions, to rebranding, and even to typos that have come down in the codebases. There are a number of tools that can help you scan for and capture this information.
Automation support
In order to make SBOMs useable at scale and across organizations, and because the goal is to automate them, they need to be machine readable. The NTIA has approved the following formats:
Practices and processes
It’s still early days in defining the practices and processes that the NTIA will require for SBOM use. However, some preliminary guidelines have been released that describe how SBOMs should be distributed and shared. The NTIA document even includes a section on accommodating mistakes that acknowledges that in industries where velocity is crucial to success, expectations should not require perfection. This section reiterates that the overarching objective of these guidelines, EO 14028, and the SBOM process itself is to secure the software supply chain while moving quickly, and continuing to improve our security practices and processes.
To learn more about the SBOM process, visit Synopsys.
