Software Bill of Materials (SBOM)

This page defines what an SBOM contains, how products and components relate within it, and which formats encode that information.

What is an SBOM

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of software components and their relationships. It records names, versions, and dependency relationships for every component in a software product.

Each SBOM describes a specific software release at the time it was built. SBOMs are static artifacts: when the software changes, producers generate a new SBOM rather than updating the original. When a vulnerability is disclosed, a separate artifact (VEX) communicates whether that vulnerability affects the product.

For organisations that procure software from suppliers, SBOMs are often the only way to know what components run inside products they have no source access to.

What an SBOM contains

An SBOM records four categories of information:

• Component inventory. Every library, module, or service in the software. Each entry carries a name, version, and an identifier tied to its ecosystem (package URL, CPE, or SWID tag).
• Dependency relationships. Which components depend on which others, including transitive dependencies pulled in by other libraries rather than chosen directly by the development team.
• Metadata. Who produced the SBOM, when, with what tools, and which software release it describes.
• Licenses. The license governing each component.

The U.S. NTIA defined minimum elements for SBOMs: supplier name, component name, version, dependency relationship, unique identifier, timestamp, and author. These fields establish a baseline but do not prescribe what good content looks like for each field. The SBOM Requirements section of this framework provides that guidance through L1 and L2 maturity levels.

A security engineer checking whether a disclosed CVE affects a product needs version numbers and dependency trees. Component names alone do not narrow the search.

Product, software, and component

SBOMs describe software at three levels:

• Product. A complete system delivered to end users: a web application, a network appliance, a medical device. The product is the top-level subject of an SBOM.
• Software. The executable code, libraries, frameworks, and firmware that provide functionality within a product. This includes both proprietary and open-source code.
• Component. A discrete, independently versioned unit of software: a library, package, or service. Each component carries its own identity, version history, and vulnerability profile.

In an SBOM, the product appears as the subject in the metadata section. Components appear in the inventory. Dependency relationships connect them into a hierarchy that shows what depends on what.

SBOM formats

Two formats dominate:

• CycloneDX. Created by the OWASP Foundation for software supply chain security. Standardised as ECMA-424.
• SPDX. Developed by the Linux Foundation, originally for license compliance, now covering full component metadata. Standardised as ISO/IEC 5962:2021.

Both standards support JSON, XML, and protocol buffers as serialisation formats. JSON is the most common in practice and the primary format in this framework's Content Requirements. The Standards and Frameworks page covers format specifications, tooling, and quality frameworks in detail.

Related concepts

• VEX: how producers communicate whether a vulnerability in a component affects their product