SCA Tool

Making open source safe, easy, and fun to use

The Software Bill of Materials

A bill of materials (BOM) is a list of components (“materials”) that make up some artifact. A software bill of materials (SBOM) is a bill of materials where all the components are software components. It is important to have an as complete and correct SBOM for a software project or product as is possible, for two main reasons:

  • Critical data structure. Complete and correct SBOM data is critical for a host of engineering functions. The three most important functions that require an SBOM are:
    • Open source governance. To decide which components are acceptable to a project or product, you first need to know whether they are included, and then what licenses and other conditions they come with.
    • License compliance. To deliver your project to clients or your product to customers, you need to comply with the licenses of any open source code included in the software. The SBOM tells you what those are.
    • Security. To manage operational risk you need to understand what components are doing their job in a given software, whether there are known vulnerabilities, and whether new vulnerabilities have been discovered.
  • Non-functional requirement. A complete and correct SBOM has become a purchasing requirement by many customers.

Originally, large customers in a software supply chain would require from their suppliers that they provide SBOMs together with any software they were supplying. In the case of custom software projects, large customers would even request to receive sign-off authority on the use of open source components before they were incorporated into the software being built.

In 2020, the European Union announced the Cyber Resilience Act (CRA)[1]. This regulation complements the previous NIS-2 legislation to improve product security across the European Union. The CRA is set to enter force in 2024. Vendors of products that include software are required to provide an SBOM to customers as well as to proactively track and respond to any vulnerabilities that become known about their products.  

In 2021, the U.S. American government issued an executive order[2] requiring, among other things, that any U.S. federal purchaser of software be provided an SBOM for the software being purchased. While previous motivations for an SBOM were mostly about license compliance, the U.S. government cares more about cybersecurity and the risks from vulnerabilities in software.

It is safe to assume that other governments will follow suit.

For any given software, the SBOM needs to list the original code of the supplier, presumably with their proprietary license, as well as any third-party components. A third-party component is any code, including open source code, not owned by you. Such third-party components come in two main forms:

  1. Standalone components are the traditional libraries and components you are including in your project or product;
  2. Code snippets are chunks of source code that have been copied and pasted into your code or into the third-party code you are using.

The two prominent (and competing) specifications for representing SBOMs are the SPDX and the CycloneDX specifications. These specifications allow the presentation of an SBOM in a linear format (list) of records with each record representing a component and some of its metadata.

There are different types of SBOM, created for different purposes. The most common SBOM is the one given to customers as part of selling a product. Other types of SBOMs add tooling information to document how a software is being built or include verification information to comply with regulatory requirements.

To create an SBOM, you need to identify and gather all third-party components your code is using, whether a standalone component or a code snippet. For any such component, you need to gather the necessary metadata for each component.

It is impossible to create a complete and correct SBOM for a non-trivial piece of software. Too much copy and paste without tracking lineage in both open and closed-source software have ruined this opportunity.


[1] EU Cyber Resilience Act

[2] Executive Order on Improving the Nation’s Cybersecurity

Stay in the know!