What’s in an SBOM?  

What's in an SBOM?

More and more organizations are deploying a software bill of materials (SBOM) to identify and track the various components of the software products they develop or use.

The goals of using SBOM might include a desire to enhance software security, comply with U.S. federal government mandates, improve the software supply chain or some other reason. Regardless of the motivation for deploying an SBOM strategy, it’s important to know exactly what goes into an SBOM.

What Should an SBOM Include?

The National Telecommunications and Information Administration (NTIA), part of the U.S. Department of Commerce, has issued guidance on what should be the minimum elements in an SBOM. The document provides a good sense of what makes up an SBOM.

NTIA breaks down SBOM into three main categories—data fields, automation support and practices and processes—and it’s the data fields segment that applies to what goes into an SBOM. As the administration notes, data fields contain baseline information about each component that should be tracked and maintained.

The goal of these fields, NTIA notes, is to enable sufficient identification of these components to track them across the software supply chain and map them to other beneficial sources of data, such as vulnerability databases or license databases. The baseline component information includes:

  • Name of the software supplier: This identifies the entity that created, defined, and identified components.
  • Component name: This is the designation assigned to a unit of software defined by the original supplier.
  • Version of the component: An identifier used by the supplier to specify a change in software from a previously identified version.
  • Other unique identifiers: These are other identifiers that are used to identify a component, or serve as a look-up key for relevant databases.
  • Dependency relationship: This characterizes the relationship that an upstream component X is included in software Y.
  • Author of SBOM data: Identifies the entity that created the SBOM data for a particular component.
  • Timestamp: This is the record of the date and time of the SBOM data assembly.

The majority of these fields help with the identification of a component to enable mapping to other sources of data, NTIA says. The capability for noting multiple names or aliases for both supplier and component name should be supported if possible, it says.

In addition to the data fields mentioned for the minimum elements, NTIA recommended that organizations consider other data fields for inclusion in SBOMs—particularly for efforts that are planned over several years or that require higher levels of security.

One is hash of the component. “When referring to a piece of software, robust identifiers are important for mapping the existence of a component to relevant sources of data, such as vulnerability data sources,” NTIA says. “A cryptographic hash would provide a foundational element to assist in this mapping, as well as helping in instances of renaming and whitelisting.”

Another is lifecycle phase. Data about software components can be collected at different stages in the software lifecycle, NTIA says, including from the software source, at build time, or after build through a binary analysis tool. “Due to unique features of each of these stages, the SBOM may have some differences depending on when and where the data was created,” it says.

A Software Bill of Materials is Only a Start

While an SBOM is not enough, it is only the beginning of risk mitigation. True defense of the software attack surface requires a Dynamic SBOM. A Dynamic SBOM creates a continuous inventory of all of your software components, maps any recognized vulnerability to these components, and assesses your attack surface. Learn more about how we can help you create a Dynamic SBOM at https://www.rezilion.com/platform/sca-dynamic-sbom/.

Reduce your patching efforts by
85% or more in less than 10 minutes