What does SBOM stand for?

SBOM stands for Software Bill of Materials. It is a machine-readable inventory of the components and dependencies that make up a piece of software.

What is the difference between SPDX and CycloneDX?

Both are open, machine-readable SBOM formats. SPDX is an ISO/IEC standard with strong license and provenance support, while CycloneDX comes from OWASP and was designed primarily around security use cases such as vulnerability matching. Most tooling supports both.

Does an SBOM make my software secure?

No. An SBOM is an inventory, not a fix. Its value is that it lets you match your components against known vulnerabilities quickly, but you still have to assess and remediate the issues it surfaces.

Why did SBOMs become a requirement?

Supply-chain incidents such as Log4Shell showed that organizations often could not tell which products contained a vulnerable component. In the United States, Executive Order 14028 then directed federal agencies to require SBOMs from software suppliers.

What is an SBOM (Software Bill of Materials)?

Last reviewed June 2, 2026

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all the components, libraries, and dependencies that make up a piece of software. It lists each component, its version, and its relationships, much like a list of ingredients on a food label. SBOMs let organizations quickly answer the question, am I affected by this vulnerability, by matching the components they ship against known CVEs.

SBOM in one sentence

SBOM stands for Software Bill of Materials. It is a structured, machine-readable document that enumerates the components inside a piece of software - the open-source libraries, third-party packages, and modules it is built from - along with their versions and how they relate to one another.

The analogy most people use is the ingredients label on packaged food. The label does not tell you whether the product is safe for you, but it lets you check for ingredients you need to avoid. An SBOM plays the same role for software: it tells you what is inside so you can reason about risk.

Standard SBOM formats

Two formats dominate. Both are open standards and are widely supported by tooling, so most organizations choose based on existing integrations rather than a strong technical difference.

SPDX (Software Package Data Exchange): an ISO/IEC standard (ISO/IEC 5962:2021) originally developed under the Linux Foundation, with a strong focus on license and provenance metadata.
CycloneDX: a standard from the OWASP community, designed from the start around security use cases such as vulnerability matching and dependency tracking.
Both formats are machine-readable (JSON, XML, and similar serializations) so that scanners and dependency tools can consume them automatically.

Why SBOMs matter

The driving concern is software supply-chain risk. Modern applications are assembled largely from open-source dependencies, and a flaw in a single deeply nested library can affect thousands of products that never reference it directly.

The Log4Shell incident (CVE-2021-44228) made this concrete. When the Log4j vulnerability was disclosed, countless organizations could not answer a simple question quickly: do we use Log4j, and where. Teams with an accurate SBOM could query their inventory in minutes; teams without one spent weeks hunting through build systems.

Regulation followed. In the United States, Executive Order 14028 (May 2021) directed agencies to require SBOMs from software suppliers, which pushed SBOM generation into mainstream development and procurement.

How SBOMs connect to CVEs

An SBOM on its own is just an inventory. Its security value comes from matching that inventory against vulnerability data. Each listed component and version is checked against databases such as the NVD, the GitHub Advisory Database, and OSV to find known CVEs that affect it.

Component identity is usually expressed with a Package URL (purl) or a CPE, which lets automated tools line up an SBOM entry with the affected-version ranges in an advisory. When a new vulnerability is published, defenders can re-scan stored SBOMs to find every affected product without rebuilding anything.

Limitations to keep in mind

An SBOM is only as accurate as the tool that generated it; components introduced outside the build (for example, copied source or container base layers) can be missed.
An SBOM lists components but does not, by itself, prove whether a vulnerable function is actually reachable or exploitable in your usage.
SBOMs are snapshots. They must be regenerated as software changes, or they drift out of date.
Matching components to CVEs depends on clean identifiers; naming inconsistencies between an SBOM and a vulnerability database can cause both false positives and missed matches.

Keep exploring

Frequently asked questions

What does SBOM stand for?: SBOM stands for Software Bill of Materials. It is a machine-readable inventory of the components and dependencies that make up a piece of software.
What is the difference between SPDX and CycloneDX?: Both are open, machine-readable SBOM formats. SPDX is an ISO/IEC standard with strong license and provenance support, while CycloneDX comes from OWASP and was designed primarily around security use cases such as vulnerability matching. Most tooling supports both.
Does an SBOM make my software secure?: No. An SBOM is an inventory, not a fix. Its value is that it lets you match your components against known vulnerabilities quickly, but you still have to assess and remediate the issues it surfaces.
Why did SBOMs become a requirement?: Supply-chain incidents such as Log4Shell showed that organizations often could not tell which products contained a vulnerable component. In the United States, Executive Order 14028 then directed federal agencies to require SBOMs from software suppliers.