Why SBOMs Are More Important Than Ever
The latest BSIMM12 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 past 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 three categories.
- Data fields
- Automation support
- Practices and processes
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
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.
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.