What is an SBOM (software bill of materials)?

What is in a software bill of materials?

At its foundation, an SBOM is an inventory of all the components that make up a software application or online service. This includes any source components and dependencies. The source components can include a listing of the following:

• Shared objects, such as dynamic link libraries.
• Software libraries for different functions.
• Open source code used in the application.
• Middleware, containers, cloud services and programming frameworks on which an application operates.

An SBOM differs from a list of ingredients or a simple inventory because it should also provide lineage information about the origin of the components. Modern software development often follows the principle that one piece of application code is dependent on another. As such, a dependency tree is needed to help provide visibility into an application's core foundational components.

In 2021, the National Telecommunications and Information Administration (NTIA) issued definitive guidance in a report detailing the minimum elements for an SBOM, including the following three foundational areas:

1. Data fields. The data fields portion of an SBOM is the asset inventory component that outlines the dependency tree for an application. The fields should include the component's name, version, license information, supplier name, authorship and a timestamp for when the SBOM data was generated.
2. Automation support. Given the complexity of modern software development processes, manually developing an SBOM isn't advised. As such, NTIA recommends a minimum level of automation for SBOM generation and data transfer so that other systems can understand and use SBOM data.
3. Practices and processes. An SBOM requires the right processes in place to help enable the ongoing collection of data. There also needs to be a definition for how SBOMs are generated and accessed.

In 2024, the Cybersecurity and Infrastructure Security Agency (CISA) released a report titled "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)." This report expands on the NTIA's foundational areas. CISA's report defines the elements and attributes of an SBOM and includes details on how to implement one.

Types of SBOMs

SBOMs can be categorized in several different ways, depending on their level of depth, the detail needed or the use case. According to CISA, SBOMs can be categorized into the following six types:

1. Design. This type of SBOM is created by listing planned components before development begins. It is often created from design specifications and expected components.
2. Source. This SBOM is created by directly listing components from the development environment, source files and dependencies.
3. Build. This SBOM is created during the build process and reflects what components were actively compiled and put into the final software.
4. Analyzed. This SBOM is created based on observed components. Pieces like executables, containers and virtual machines are typically scanned using third-party tools after the software is built.
5. Deployed. This type of SBOM is created by recording software components and configuration information in deployment environments. This is meant to inventory what is available and is actively installed.
6. Runtime. This SBOM is designed to record only the components that are actively loaded and used during an application's execution.

Benefits of utilizing SBOMs

As organizations increasingly rely on software to run business-critical operations, it's imperative to have SBOMs for the following reasons:

• Improve security posture. SBOMs help organizations identify potential security risks and enable them to address these risks more efficiently.
• Help assess dependencies and supply chain risk. When software vulnerabilities are discovered, they are often found in components that are dependencies for other software applications. Knowing whether an organization is at risk from a third-party component is a challenge that is commonly referred to as supply chain risk.
• Enhance transparency. Many organizations struggle to understand whether they are at risk from a specific software vulnerability. SBOMs add more transparency and visibility into the exact components used in a software or service.
• Aid open source license compliance. In addition to helping with supply chain risk, an SBOM can assist organizations with open source software license compliance issues. Different open source licenses can have usage restrictions or require organizations to share any changes made to the source code. A well-constructed SBOM reveals not only the underlying open source software dependencies, but also the license restrictions that are in place.
• Support regulatory and policy compliance. After a string of supply chain attacks in 2020 and 2021, including the SolarWinds breach in March 2020 and the Colonial Pipeline hack in July 2021, the U.S. federal government published Executive Order 14028, which advocates for U.S. government agencies to only deal with software vendors that provide SBOMs, among other directives. The executive order also directed NTIA to define the minimum requirements for an SBOM, which were defined by the agency in a comprehensive report released in July 2021.

Challenges of utilizing SBOMs

Although SBOMs can benefit an organization by providing more visibility and a better security posture, they also come with the following challenges:

• Inconsistent integration with existing workflows. The implementation of an SBOM should be consistent across teams and any parties involved in the software supply chain. It should also align with existing development, compliance and security processes.
• Maintaining SBOM accuracy. Keeping an SBOM up to date can be difficult, as it needs to be maintained, scaled and updated with any changes to the software.
• Lacking vendor support. Third-party vendors might not provide detailed information about their components that an organization could use in its SBOM.

How to select an SBOM tool

When selecting a tool to create an SBOM, organizations should ensure it addresses the following:

• Provides scalability. The SBOM tool should be able to scale to projects of different sizes, from smaller applications to larger enterprise-grade systems.
• Integrates with existing workflows and systems. The correct tool must be able to properly integrate with an organization's development and operational systems. If the tool is going to be used for added security, it should integrate with existing security tools.
• Addresses the organization's needs. The chosen tool must fit the organization's plan for creating the SBOM.
• Provides automation capabilities. Some SBOM tools have features that automate SBOM generation and updates.
• Offers compliance features. The tool should support relevant standards, such as Software Package Data Exchange (SPDX) or CycloneDX, and help meet any regulatory SBOM requirements.
• Fits the budget. SBOM tools can be free, usage-based or subscription-based.

How to create a software bill of materials

Multiple tools can integrate with continuous integration/continuous delivery technology to build an SBOM as part of a development pipeline. An SBOM can be generated before, during or after the software application's development process using the following steps:

1. Define the SBOM scope. The organization must decide what software it is creating an SBOM for and if it depends on any internal, external or third-party dependencies.
2. Pick a format. For both developers and end-user organizations that want or need visibility into supply chain risk, it's critical to use an industry standard form for SBOM data exchange. Whether the organization is generating an SBOM during development -- with a software composition analysis (SCA) tool or otherwise -- the SBOM data must be in a format that is portable and well understood so that it can be used in other applications.
   
   One of the industry standards for SBOMs is International Organization for Standardization (ISO)/International Electrotechnical Commission 5962:2021 for the SPDX specification. SBOMs that are written to this specification can be consumed in software vulnerability, risk and patch management technologies to help understand what underlying software components an organization uses. ISO developed Software Identification tagging to help provide the data fields portion of an SBOM. CycloneDX, which is developed by the Open Web Application Security Project, is another common standard for helping organizations develop SBOM manifests.
3. Choose the SBOM tool. The organization should choose the SBOM tool it wants to use, such as the CycloneDX command-line interface, Grype, Syft or Tern. It needs to fit the type of SBOM the organization wants to implement.
4. Generate the SBOM. If generating the SBOM occurs during the build, for example, the SBOM tool might use SCA software to identify each application's components. SCA scanning can occur after an application is completed or during the application development process.
5. Maintain. The SBOM tool should be rerun whenever the software is updated or new dependencies are added.

Learn about the different SBOM tools that organizations can use to build their SBOMs and secure their software supply chains.