software bill of materials (SBOM)

What is in a software bill of materials?

The foundational level of an SBOM is an inventory of the source components and dependencies in a specific application or online service. The source components includes a listing of the shared objects, such as dynamic link libraries (DLLs), that an application accesses in order to operate. SBOM also includes software libraries for different functions and application dependent open source code. Any usage or reliance on middleware components and programming frameworks on which an application operates need to be included in a complete SBOM manifest.

An SBOM differs from a list of ingredients or inventory because it should provide lineage information of where components come from as well. Often, modern software development follows that one piece of application code is dependent on another. As such, a dependency tree is needed to help provide visibility into the core foundational components of an application.

In July 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:

• 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 name of the component, version, license information and supplier name, as well as authorship and a timestamp for when the SBOM data was generated.
• Automation. With the complexity of modern software development processes, manually developing an SBOM isn't advised. As such, the NTIA recommends a minimum level of automation for SBOM generation and data transfer, such that other system can understand and make use of SBOM data.
• 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 how they are accessed.

Why do organizations need a software bill of materials?

As organizations increasingly rely on software to run business critical operations, it's imperative to have an SBOM.

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.

Many organizations face the challenge of understanding whether they are at risk from a specific software vulnerability. For example, the OpenSSL cryptographic library is a component of countless applications. When the Heartbleed vulnerability was disclosed in 2014, every application and service that relied on OpenSSL as a dependency needed to update. The same type of risk was also exposed by the Log4J open source software vulnerability that was disclosed in December 2021. Even after a source component or library is patched by the original project, it is incumbent upon every downstream vendor that relies on the component and every end user to also patch.

The string of supply chain attacks in 2020 and 2021, including SolarWinds in March 2020 and Colonial Pipelines in July 2021, motivated the U.S. government to act to help mitigate supply chain risks. In May 2021, 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 the NTIA to define the minimum requirements for an SBOM, which were then defined by the agency in a comprehensive report released in July 2021.

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 could impose requirements on organizations to share any changes made to the source coded. A well-constructed SBOM will not only reveal the underlying open source software dependencies, but also what license restrictions are in place.

In February 2022, the Linux Foundation released a report titled "The State of Software Bill of Materials and Cybersecurity Readiness," in which the Linux Foundation revealed that 78% of the 412 global organizations that were surveyed intend to adopt SBOMs by 2022.

How to make a software bill of materials

An SBOM can be generated during the development process for a software application. There are multiple tools that can integrate with continuous integration/continuous development (CI/CD) technology to build an SBOM as part of a development pipeline.

Another approach to generating an SBOM is by using software composition analysis (SCA) software that can identify what components are in each application. SCA scanning can occur after an application is completed, or even during the application development process.

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 an SCA tool or otherwise -- the SBOM data needs to be in a format that is portable and well understood so that it can be used in other application.

One of the industry standards for SBOMs is ISO/IEC 5962:2021 for the Software Package Data Exchange (SPDX) specification. SBOMs that are written to the SPDX format can be consumed in software vulnerability, risk and patch management technologies to help understand what underlying software components used by an organization. NTIA has also developed an effort known as Software Identification (SWID) tagging to help provide the data fields portion of an SBOM. CycloneDX, which is developed by Open Web Application Security Project (OWASP), is another common standard for helping organizations to develop SBOM manifests.