SBOM stands for “software bill of materials.” At its most simplistic level, an SBOM is a list of “ingredients” that describes the components in a software application. More precisely (per the NTIA), a SBOM is a “complete, formally structured list of components, libraries and modules that are required to build a given piece of software and the supply chain relationships between them.”

When developers build software applications, they use a variety of sources, which may or may not contain vulnerabilities. An application is only as secure as the source code within it. A Software Bill of Materials provides transparency, so you know exactly what’s inside an application. 

For developers, SBOMs are a way to keep track of all the open-source, custom built, and commercial components within the applications they develop and manage. For software customers, an SBOM provides the full picture of what’s inside the application you’ve purchased.

What is in an SBOM?

The NTIA defines the minimum elements to be included in an SBOM.

• Supplier Name The name of an entity that creates, defines, and identifies components.
• Component Name Designation assigned to a unit of software defined by the original supplier.
• Version of the Component Identifier used by the supplier to specify a change in software from a previously identified version.
• Other Unique Identifiers Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases.
• Dependency Relationship Characterizing the relationship that an upstream component X is included in software Y.
• Author of SBOM Data The name of the entity that creates the SBOM data for this component.
• Timestamp Record of the date and time of the SBOM data assembly.

License information (and license text) is also often included. 

The leading formats for SBOMs are CycloneDX and Software Package Data Exchange (SPDX). SPDX has been around for more than a decade, and was originally created to help developers keep track of open source license development. CycloneDX is newer, and was developed primarily to track dependencies and manage vulnerabilities. Both have their advantages, but CycloneDX is generally more useful to enterprise owners looking to minimize the risk of cyber threats.

VEX documents (Vulnerability Exploitability Exchange) also often serves as a companion to SBOMs. Using VEX documents, asset owners are able to asses which vulnerabilities within an application are exploitable. VEX provides additional information about the level of risk.

Why Are SBOMs important?

SBOMs are important, because they provide an important layer of transparency and accountability to secure the software supply chain. Anyone who procures software for their organization should be requiring their vendors to provide SBOMs.

On May 12, 2021, President Biden issued the “Executive Order on Improving the Nation’s Cybersecurity (14028).” As a result of this legislation, going forward, any vendor that supplies software to the Federal Government will soon be required to provide an SBOM, to help secure the software supply chain and mitigate risk. Developers who fail to produce SBOMs risk losing important government IT contracts. Over time, we can expect SBOMs will become “table stakes” for all software vendors bidding on projects in both the public and private sectors.

How can you create your SBOM?

You could create your SBOM by researching every component your application is using by looking at your manifests. You would need to research each component. SOOS has a free site to help you do this research. For example Apache Log4J package 2.17.0 license and vulnerabilities would need to be stored and generated into the correct format.

An easier path is for developers to use SOOS’s Software Composition Analysis (SCA) Tools to easily generate SBOMs, and store the history of the project, providing transparency to the open source license changes over time. The SOOS software composition analysis tools include a deep dependency tree vulnerability scan of your open source packages to mitigate security risks. SOOS SCA management also includes an analysis of the open source licenses for every package in your project/manifest. SOOS supports SPDX, CycloneDX and VEX with Text, JSON and HTML reports available. Full support for Package Version URLs, License Text, License, and Vulnerabilities.

SOOS makes it simple and affordable for all software developers to access the tools they need to create SBOMs and comply with the Executive Order on Improving the Nation’s Cybersecurity (14028).