Software supply chain guide

What Is an SBOM? Software Bill of Materials Explained

An SBOM (software bill of materials) is a list of everything inside a piece of software: each component, its version, who supplies it and what depends on what. CISA calls it "a nested inventory, a list of ingredients that make up software components". When a library such as a logging package turns out to be vulnerable, an SBOM is how you find every product that contains it.

Below: the minimum elements, SPDX vs CycloneDX, how to produce one, and what to do with it once you have it. Sources are CISA, NTIA and the two standards bodies. Last reviewed 12 November 2026.

Updated 12 November 2026

The minimum elements

NTIA's 2021 report set the baseline most tools still follow. It has three parts.

Data field	What it records
Supplier	Who creates and identifies the component.
Component name	The name the supplier gives the unit of software.
Version	The supplier's identifier for this release.
Other unique identifiers	Identifiers such as CPE, SWID tags or package URLs that let tools match the component.
Dependency relationship	Which component includes which.
Author of SBOM data	Who produced this SBOM (not always the supplier).
Timestamp	When the SBOM data was assembled.

Automation support: machine-readable formats, named as SPDX, CycloneDX and SWID tags.
Practices and processes: frequency (a new build or release gets a new SBOM), depth (top-level components and their transitive dependencies where possible), known unknowns (say where the graph stops), distribution and delivery, access control, and accommodation of mistakes.

In July 2026 CISA, with NSA, FBI and international partners, published Minimum Elements for a Software Bill of Materials, which it says updates and replaces the NTIA 2021 list after a 2025 public comment period. If you are writing a contract or policy, cite the 2026 document.

SPDX vs CycloneDX

	SPDX	CycloneDX
Maintained by	Linux Foundation project	OWASP and Ecma International TC54
Standard	ISO/IEC 5962:2021	ECMA-424
Scope	Software packages, files and licences; version 3.0 released 2024	SBOM plus SaaSBOM, HBOM, CBOM, AI/ML-BOM and VEX

Pick the format your customers or regulator ask for. Tools can usually convert between them, although some fields do not map one to one.

How to create and use an SBOM

Generate it in the build. Point a generator at the lockfile, manifest or container image of the release you ship. Hand-written SBOMs go stale on the next commit.
Check the minimum fields. Every component needs a supplier, name, version and an identifier tools can match (a package URL or CPE).
Store it with the release and produce a new one for every build you ship.
Match it against vulnerability data. An SBOM is only useful when something reads it. Compare components with the CISA KEV catalog first, then order the rest with EPSS.
Ask suppliers for theirs. Put the SBOM format and refresh frequency in the contract, and accept VEX statements for components that are present but not exploitable in their product.

Frequently asked questions

What is an SBOM?

A software bill of materials (SBOM) is a list of the components inside a piece of software, with their versions, suppliers and how they depend on each other. CISA describes it as "a nested inventory, a list of ingredients that make up software components". It lets you answer "are we affected?" in minutes when a vulnerability is announced in a library.

What is an SBOM used for?

Finding out quickly whether you run a vulnerable or end-of-life component, checking licences, judging a supplier before you buy, and meeting customer or regulatory requests. Its value comes from being kept current and matched against vulnerability data, not from producing it once.

What is the difference between a BOM and an SBOM?

A bill of materials (BOM) is the manufacturing term for the list of parts in a product. An SBOM applies the same idea to software: the "parts" are libraries, packages and modules. CycloneDX also defines other BOM types, such as hardware (HBOM), cryptography (CBOM), SaaS (SaaSBOM) and AI/ML-BOM.

What are the minimum elements of an SBOM?

NTIA's 2021 minimum elements list seven data fields: supplier, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and a timestamp. They also require machine-readable formats (SPDX, CycloneDX or SWID tags) and practices covering frequency, depth, known unknowns, distribution, access control and accommodation of mistakes. In July 2026 CISA, NSA, FBI and international partners published joint guidance that updates and replaces the NTIA 2021 list; check that document for the current fields.

SPDX or CycloneDX?

Both are open standards and most tools read both. SPDX is a Linux Foundation project and an ISO standard (ISO/IEC 5962:2021). CycloneDX is driven by OWASP and Ecma International TC54 and is published as ECMA-424; it covers several BOM types beyond software. Use the one your customers and tools ask for; convert if you must.

How do you create an SBOM?

Generate it from the build, not by hand. A generator reads your lockfiles, package manifests or container image and writes SPDX or CycloneDX. Produce a new SBOM for every release (the NTIA practices say a new build or release needs a new SBOM), store it with the release, and state "known unknowns" where you could not see deeper dependencies.

What is VEX?

VEX (Vulnerability Exploitability eXchange) is, in CISA's words, "an attestation, a form of a security advisory that indicates whether a product or products are affected by a known vulnerability". It travels alongside an SBOM so a supplier can say a listed component's CVE does not affect the product.