Software Bill Of Materials (SBOM).

What Is an SBOM?

SBOM stands for software bill of materials. CISA defines it as a nested inventory, a list of ingredients that make up software components. NIST defines it as a formal record containing the details and supply chain relationships of various components used in building software.

Think of the ingredients list on food packaging. An SBOM lists what is inside a piece of software, so that the buyer or user can see what it is made of.

What Does an SBOM Record?

NIST notes that software developers and vendors often create products by assembling existing open-source and commercial software components. The SBOM records those component details for the final product. The word nested in CISA’s definition means a component can itself contain other components, and the list can show that.

The supply chain relationships in the NIST definition matter here. They record how the parts connect to the finished product.

Why Do Buyers and Builders Ask for an SBOM?

CISA calls the SBOM a key building block in software security and software supply chain risk management. It promotes it as a transparency tool.

When a flaw is announced in a component, an inventory can help a team check whether that component is in the software it uses. A recent case is CVE-2026-108551 in the openapi-typescript-codegen build tool, which has no fixed release, so teams first need to find every project that uses it. The list is only as useful as it is complete and up to date. Shaded and aggregate Java artifacts are one example: see Apache Juneau vulnerabilities fixed in 9.2.1.

How Have the SBOM Minimum Elements Changed?

Minimum elements are the baseline an SBOM should include. Three official documents mark how that baseline moved.

CISA says some software types, such as AI and software as a service in cloud environments, may need additional elements. Any effort should begin with the minimum elements.

How Do You Put an SBOM to Work?

An SBOM is a record, so the value comes from how it is used.

• Ask suppliers for an SBOM for the software you buy, where it is available.
• Keep SBOMs for the software you build, so you know which components you ship.
• Compare the component list with new vulnerability announcements, such as CVE entries.
• Update the record when components change.

Is an SBOM the Same as a Vulnerability Scan?

No. An SBOM lists components. A vulnerability scan looks for known flaws. The two can work together, because a component list tells you what to check, but the list itself does not say whether any component is vulnerable.

Is an SBOM the Same as Protection from Supply Chain Attacks?

No. CISA presents the SBOM as a transparency tool and a building block, not a full defense. It helps you see what is in your software. It does not stop a poisoned component from being added. Related terms are supply chain attack and third-party risk.

Related Pages in the Knowledge Hub

• Supply chain and vendor risk
• Common Vulnerabilities and Exposures (CVE)
• Known Exploited Vulnerabilities (KEV) catalog

Sources

• CISA: CISA defines an SBOM as a nested inventory, a list of ingredients that make up software components. It calls it a key building block in software security and software supply chain risk management.
• NIST: NIST defines an SBOM as a formal record containing the details and supply chain relationships of various components used in building software. Developers and vendors often assemble products from existing open-source and commercial components.
• NTIA: The 2021 report on the minimum elements for an SBOM, dated 12 July 2021, called for by Executive Order 14028.
• CISA: The draft 2025 minimum elements, published 22 August 2025 with comments open until 3 October 2025.
• CISA: The 2026 minimum elements, published 29 July 2026 as joint guidance that replaces the 2021 NTIA document; notes that AI and SaaS may need additional elements.