What does SBOM stand for?

Software Bill of Materials — a structured, machine-readable inventory of all the open-source and third-party components that make up a piece of software, including their versions and suppliers.

What are the main SBOM formats?

SPDX (Software Package Data Exchange), originally a Linux Foundation project and also adopted as an ISO/IEC standard, and CycloneDX, which originated in the OWASP ecosystem with a focus on application security use cases.

Does an SBOM tell you if a vulnerability is actually exploitable?

No. An SBOM is an inventory of what's present, not a risk assessment. Whether a listed component's vulnerability is actually exploitable in that product is a separate question, typically answered by complementary VEX (Vulnerability Exploitability eXchange) data.

Why do enterprise buyers ask for an SBOM now?

Two drivers: supply chain vulnerability events made 'what's inside this software' an urgent question, and U.S. federal policy, including the 2021 Executive Order on Improving the Nation's Cybersecurity, pushed SBOM requirements into government software procurement, which increased broader market awareness.

How often should a vendor's SBOM be updated?

Ideally tied to each release, or continuously for SaaS products that change between formal releases. A static SBOM generated once and never refreshed goes stale as dependencies change.

What is an SBOM? A practical definition

Glossary · enterprise · 4 min read · last verified 2026-07-21

Reviewed before publication Editorial board Independent commercial review

In shortAn SBOM is a machine-readable inventory of every component inside a piece of software, typically in SPDX or CycloneDX format. It tells you what's present, not whether it's exploitable — that's a separate question VEX data answers.

The short definition

A software bill of materials (SBOM) is a formal, structured inventory of the components that make up a piece of software — every open-source library, third-party dependency, and package it's built on, along with details like version and supplier. The concept borrows directly from manufacturing, where a bill of materials lists every part in a physical product. An SBOM does the same thing for code: it answers "what's actually inside this software" in a machine-readable format, rather than relying on a vendor's word for it.

The two formats that actually matter

Two SBOM formats have real adoption and tooling support, and a credible SBOM request or delivery should reference one of them by name:

SPDX (Software Package Data Exchange) — originated as a Linux Foundation project, now maintained through an open standards process, and has also been adopted as an international standard through ISO/IEC. It's widely supported across software composition analysis and open-source compliance tooling.
CycloneDX — originated within the OWASP (Open Web Application Security Project) ecosystem, designed specifically with application security use cases in mind, and has strong tooling support in the DevSecOps and supply-chain security space.

Both are legitimate, both are machine-readable (typically JSON or XML), and most modern SBOM-generation tooling can produce either. Neither is universally "the" standard — which format a vendor uses often comes down to their existing toolchain rather than one format being objectively superior. Asking "do you generate SBOMs, and in which format" is a more useful question than asking for "the" SBOM standard, since there isn't a single one.

Why SBOMs became a procurement topic, not just an engineering one

SBOMs moved from a niche software supply chain security practice to a mainstream enterprise procurement expectation for two connected reasons:

Supply chain vulnerability events made "what's inside this software" an urgent question. When a widely-used open-source component has a serious vulnerability disclosed, organizations that don't know which of their vendors' products depend on that component can't quickly assess their own exposure. An SBOM turns "which of our vendors are affected" from a frantic vendor-by-vendor email chain into a searchable inventory.

U.S. federal policy pushed SBOM requirements into government software procurement, most notably through the 2021 Executive Order on Improving the Nation's Cybersecurity (EO 14028), which directed federal agencies toward requiring SBOMs as part of software supply chain security for products sold to the government. That policy push, plus subsequent guidance work (including baseline "minimum elements" guidance from NTIA covering fields like component name, version, supplier, and dependency relationships), has meaningfully increased SBOM awareness and expectations well beyond the direct federal-vendor population, flowing into broader enterprise security questionnaires over time.

What a usable SBOM actually contains

A functional SBOM, regardless of format, generally captures for each component:

Component/package name
Version
Supplier or publisher
A unique identifier (such as a package URL or CPE) that disambiguates it from similarly-named components
License information
Dependency relationships — what depends on what, since vulnerabilities in a nested dependency are easy to miss without this
A timestamp indicating when the SBOM was generated, since dependency trees change with every build

What an SBOM does not tell you

This is the point buyers most often miss: an SBOM is an inventory, not a risk assessment. It tells you a component is present — it does not tell you whether that specific component, as used in that specific product, is actually exploitable. A library might be present in the dependency tree but never invoked in a way that triggers its vulnerable code path.

That's the gap the VEX (Vulnerability Exploitability eXchange) format is meant to close — a complementary document that states whether a known vulnerability in a component is actually exploitable, not exploitable, or under investigation, in the context of the specific product. An SBOM plus VEX data together are far more actionable than an SBOM alone: the SBOM tells you what's present, VEX tells you whether it matters.

When and how SBOMs typically get delivered

Point-in-time, at release — a static SBOM generated and attached to a specific software version, common for on-prem or shipped software.
Continuously updated, via API or portal — more common for SaaS, where the running product changes between formal releases and a static document goes stale quickly.
On request during procurement or security review — many vendors don't publish SBOMs proactively but will produce one on a signed request as part of the security questionnaire process.

What enterprise buyers should actually ask

"Do you generate SBOMs, and in SPDX or CycloneDX format?"
"How frequently is the SBOM regenerated — per release, or continuously?"
"Can you provide VEX data alongside the SBOM, so we know which listed components are actually exploitable in your product?"
"What's your process when a critical vulnerability is disclosed in a component you depend on — how fast do you notify customers?"

The practical takeaway

An SBOM is a real, standards-backed artifact — not a vague buzzword — but it solves visibility, not risk assessment. A vendor that can produce a current SBOM in SPDX or CycloneDX format, paired with some form of exploitability context, is demonstrating a materially more mature software supply chain security posture than one that can only say "we track our dependencies internally." This is general technical and process information, not a compliance or legal guarantee — specific regulatory SBOM requirements vary by industry and jurisdiction.