What is a software bill of materials (SBOM)?

An inventory, not a scan and not a verdict

Audience: a founder or eng lead who has just been asked for an SBOM by a customer, a regulator, or a due-diligence team, and needs a plain answer before deciding what to produce. This page is not legal advice. It does not generate YOUR SBOM, does not determine whether a legal SBOM requirement applies to your product, and does not classify your components.

An SBOM answers 'what is actually in this software' — component names, versions, and the dependency relationships between them, machine-readable so tools can generate, merge, and query it automatically. It is not a vulnerability scan: the SBOM tells you what you have, and a separate scan (matching that inventory against advisory databases) tells you which of those components currently have reported issues. An SBOM with no follow-up analysis does not by itself tell you whether you are exposed to anything.

• The glossary entry on this site (a different kind and a different path, /guides/glossary/sbom) covers the plain-English definition and format basics in shorter form. This page goes deeper into the current 2026 minimum-elements guidance, formats, and jurisdictional requirement-vs-guidance distinction.
• The EOL-dependencies guide on this site is the natural next step once you can query an SBOM: finding which of those inventoried components are no longer supported. The detect-vulnerable-open-source-packages guide on this site covers matching an SBOM (or a lockfile) against advisory feeds.
• The vulnerability management pillar on this site is not published yet; naming it here is not a link.

SPDX vs CycloneDX: two open formats, both machine-readable

Two open, actively maintained formats dominate SBOM generation in practice. Neither format is 'the' legally mandated one anywhere this page has verified as of last check; both are commonly accepted as satisfying a 'commonly used, machine-readable' requirement where one exists. Last verified 10 September 2026.

• Both formats are machine-readable and widely supported by generation tooling (for example Syft, Trivy, and cdxgen commonly produce CycloneDX; scancode-toolkit and FOSSA commonly produce SPDX; several tools support both).
• Neither the CISA/NTIA minimum elements nor, as of last verification, the EU CRA names one format as exclusively required — both texts describe a 'commonly used and machine-readable' format requirement that either open standard is generally understood to satisfy.

Minimum elements: 2026 CISA guidance supersedes the 2021 NTIA baseline

US Executive Order 14028 (2021) directed the National Telecommunications and Information Administration (NTIA) to define the minimum elements an SBOM should contain; NTIA published that baseline in July 2021. As of last verification (10 September 2026), that 2021 baseline has been superseded: CISA, together with the NSA, the FBI, and international partners, published the finalized 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, following a 2025 public-comment draft. Anything still citing only the 2021 NTIA document as the current US government baseline is citing a superseded version.

The 2026 update preserves the 2021 document's core principles — automation is still treated as essential to security at scale — while adding new fields (including a component hash algorithm, component license, SBOM tool name, and SBOM generation context), renaming several existing fields for clarity (Author of SBOM Data became SBOM Author; Supplier Name became Component Producer; Version of the Component became Component Version), replacing the older 'Depth' element with a broader 'Coverage' concept, and removing Access Control as a standalone element (folded into Distribution and Delivery). CISA states the minimum elements apply to all software, including open-source, AI, and SaaS, though some software types may warrant additional elements beyond the baseline.

• This is US federal guidance, not a statute that binds private organizations directly. It shapes procurement expectations (e.g., what a federal agency may ask a vendor to supply) and is widely used as a private-sector reference for 'what should be in an SBOM,' but it does not by itself create a legal SBOM-production duty for a company that sells no software to the US government.

EU CRA: a legal SBOM floor, only if the CRA applies to YOU

Regulation (EU) 2024/2847 (the Cyber Resilience Act, 'CRA') is different in kind from NTIA and CISA's guidance: it is a directly applicable EU regulation, and if it applies to a given manufacturer and product, its SBOM-adjacent text is a legal requirement, not a recommendation. Annex I Part II point (1) states that manufacturers of products with digital elements shall 'identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.' That essential requirement, along with the rest of Annex I, applies from 11 December 2027 under Article 71(2) — a different date from CRA Article 14's incident-reporting duty, which applies from 11 September 2026.

Two honest limits on that CRA text, as of last verification: first, the legal floor is top-level dependencies only — the article's own words say 'at the very least the top-level dependencies,' so transitive/nested dependencies are not the stated legal minimum, even though many practitioners generate a fuller tree voluntarily. Second, Article 13(24) lets the European Commission later specify the SBOM's exact format and elements 'by means of implementing acts,' but as of last verification no such implementing act has been adopted — so 'commonly used and machine-readable' is not yet defined down to a named format or version by the regulation itself, and SPDX or CycloneDX are widely treated as satisfying that description without either one being named in the statute.

Recital 22 and Article 13(25) add a narrower, separate mechanism: an administrative cooperation group (ADCO) can decide to run a Union-wide software-dependency assessment for specific product categories, and market surveillance authorities may, for that purpose, request manufacturers in those categories to supply their SBOMs, which authorities then report to ADCO in anonymized, aggregated form. That is a possible future request mechanism tied to a dependency assessment, not a standing public-disclosure duty for every SBOM a manufacturer produces.

Why an SBOM matters in practice

The clearest operational payoff is vulnerability response: when a flaw is disclosed in a widely used library, an organization with current SBOMs can answer 'are we exposed, and where' in minutes by querying the inventory, instead of a manual repo-by-repo sweep. The same inventory supports license-compliance review and technical due diligence, where a buyer or auditor wants an independent view of what a codebase actually depends on.

An SBOM is evidence of composition, not a guarantee of safety. It describes what is present; it does not by itself say whether each component is patched, reachable in your deployment, or safely configured. Pairing an SBOM with a vulnerability scan against advisory data, and with dependency-tree resolution deep enough to catch transitive components, is what turns the inventory into an actual risk picture — the sbom-blast-radius guide on this site covers why a lockfile-derived answer is more trustworthy than a manifest-derived one for that step.

Pairing an SBOM with VEX: inventory plus exploitability status

An SBOM tells you what is present. A separate, complementary document called a Vulnerability Exploitability eXchange (VEX) statement tells you, for a specific known vulnerability in a specific component, whether the product is actually affected, not affected, a fix is available, or an investigation is under way — because a vulnerable component being present does not automatically mean the vulnerable code path is reachable or exploitable in that particular product. CycloneDX has carried native VEX support since version 1.4 (January 2022); SPDX 3.0's Security profile added native vulnerability and VEX-adjacent data that the older SPDX 2.x line did not have. Neither the CRA text nor the CISA/NTIA minimum elements cited above require a VEX statement as part of the SBOM itself — VEX is a separate, complementary artifact, not a mandatory SBOM field.

For a team building on top of an SBOM, this matters operationally: an SBOM without any VEX or reachability layer will, correctly, list a vulnerable component as present even in cases where the vulnerable function is never called by your code. That is not a false SBOM — the component genuinely is there — but it is an incomplete picture for prioritization, which is why the exploitability-vs-severity guide on this site treats presence of a vulnerable component as one input, not a verdict.

Generating an SBOM in practice

Three common generation approaches, each with a different trust level. Build-time generation (tools that hook into a package manager, container build, or CI pipeline and emit SPDX or CycloneDX directly from the resolved dependency graph) is generally the most trustworthy, because it reflects what was actually installed, including transitive dependencies pulled in by a lockfile, not just what a manifest declares. Post-hoc binary or container-image analysis (scanning a built artifact after the fact to infer its components) is useful when you cannot instrument the original build, but is inherently a best-effort reconstruction, since some metadata present at build time is not always recoverable from the finished artifact. Manually maintained component lists are the least reliable of the three and are not the automation CISA's 2026 guidance and the original NTIA baseline both treat as central to a usable SBOM.

Whichever approach you use, regenerate the SBOM per build or per release rather than treating it as a document written once. Dependencies change with every release; an SBOM that is months stale is a snapshot of a codebase that no longer exists.

What to do now

This page does not generate YOUR SBOM or determine which requirement, if any, applies to your product. The list below is a starting sequence.

• Determine whether you have an actual legal SBOM obligation (most plausibly the CRA, only if it applies to your product and market) versus a customer or procurement expectation shaped by NTIA/CISA guidance. Those are different binds with different consequences for missing them; counsel or your compliance lead answers which applies to you.
• Pick a format your tooling can generate automatically from your build — SPDX 3.0.1 or CycloneDX 1.7 are both current, open, and widely supported; regenerate per build rather than maintaining an SBOM by hand.
• If a CRA-adjacent obligation may apply, remember the stated legal floor is top-level dependencies only; decide separately whether you also want full transitive coverage for your own risk-management purposes, which most mature programs do.
• Do not wait for the European Commission's Article 13(24) implementing act to name a format before starting — none has been adopted as of last verification, and 'commonly used and machine-readable' already covers SPDX and CycloneDX in practice.
• Pair the SBOM with a vulnerability-matching process; an inventory alone does not tell you what is exploitable. The detect-vulnerable-open-source-packages guide on this site covers that step.

Where this shows up in ShipReady Metrics

Signed-in app → Security → Findings ingests dependency data (including from Dependabot and code-scanning connectors) and maps transitive-dependency blast radius across repositories, which is the operational use of an SBOM-like inventory: knowing which repositories use an affected component and at what resolved version. This product does not generate a CRA Annex I Part II(1)-conformant SBOM file, does not determine whether the CRA applies to your product, and does not file anything with a market surveillance authority. A named human on the team still owns SBOM production and any related legal determination.

This page does not document a public product demo path.

Primary sources (last verified 10 September 2026)

CISA, NSA, FBI, and international partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM) (published 29 July 2026, superseding NTIA's 2021 Minimum Elements for a Software Bill of Materials, issued pursuant to Executive Order 14028). SPDX 3.0.1 specification (Linux Foundation / SPDX project) and ISO/IEC 5962:2021 (recognizing SPDX 2.2.1; a revision for SPDX 3.0 is in progress at ISO as ISO/IEC DIS 5962, ballot closed 9 June 2026, not yet published as of last verification). OWASP CycloneDX 1.7 specification (October 2025; ECMA-424, 2nd Edition, December 2025). Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I Part II point (1), Article 13(24)-(25), Recital 22, and Article 71(2) — a legal requirement only if the CRA applies. Not legal advice. These are not a complete list of every jurisdiction's SBOM-adjacent rule.

The glossary entry on this site (/guides/glossary/sbom) covers the plain-English definition. The EOL-dependencies guide, the detect-vulnerable-open-source-packages guide, and the SBOM-blast-radius learn guide on this site are the closest related pages. The CRA docs hub on this site covers scope questions for the CRA Annex I text cited above.

Frequently asked questions