What is an SBOM? The software bill of materials, explained

2 min read · Explainer
TL;DR

An SBOM is a machine-readable list of every component inside a piece of software: names, versions, identifiers, and the dependency relationships between them. It is the ingredients label for software, and regulators, customers, and your own incident response all increasingly depend on it.

An SBOM, a software bill of materials, is a machine-readable inventory of the components inside a piece of software: every library, package, and module, with versions, identifiers, and the relationships that connect them. The analogy everyone uses is the ingredients label, and it is apt: the point is that a consumer of software should be able to know what is in it without taking the vendor’s word.

What a real SBOM contains

The baseline, defined by the widely referenced NTIA minimum elements, is per component: supplier, name, version, unique identifiers, dependency relationships, plus the SBOM’s own author and timestamp. Two of these are chronically under-delivered:

  • Relationships. A flat list says what is present; the graph says how it got there and what to upgrade to remove it. Serious consumers require the graph.
  • Known-unknowns. Real software contains things scanners cannot fully resolve. A trustworthy SBOM declares them explicitly instead of silently omitting them, so its completeness is auditable rather than assumed.

Beyond the baseline, mature SBOMs carry hashes, license data, and generation provenance: which tool, what inputs, so any entry can be explained and reproduced.

Why the sudden ubiquity

Three converging forces made SBOMs unavoidable. Incidents: headline supply chain compromises turned “which of our systems contain this component” into a board-level question that took unequipped organizations weeks to answer. Regulation: multiple mandates now require SBOMs outright, from EU product regulation to US medical device law. Procurement: enterprise and government buyers ask for SBOMs before signing, and their review quality is rising fast.

The living-document part everyone misses

An SBOM’s real value begins after it is produced. Components age: new vulnerabilities are disclosed against old versions continuously. An SBOM stored per release and re-evaluated against updated vulnerability data turns the next headline CVE from an investigation into a query. This is the difference between SBOM as compliance paperwork and SBOM as operational capability, and it is where the practice is heading: every serious mandate now implies the living version.

Producing one

The non-negotiable rule: generate from real builds, never assemble by hand. Hand-built SBOMs drift from the artifact immediately and discredit themselves under review. SecuDep generates complete CycloneDX SBOMs from actual dependency resolution as a build step, offline, and BOMNexa manages them across releases: monitored, re-evaluated, and ready for whoever asks. Related inventories extend the same idea beyond software: the CBOM does for cryptography what the SBOM does for components.

Frequently asked questions

What formats do SBOMs use?

The two dominant machine-readable formats are CycloneDX and SPDX. Both carry components, identifiers, and relationships; CycloneDX has grown particularly strong support for security-adjacent data like vulnerability statements and cryptographic properties. Producing at least one of them, validated against its schema, is the practical baseline.

Who is asking for SBOMs?

Governments and regulators (US federal guidance, the EU Cyber Resilience Act, FDA premarket expectations for medical devices, and sector frameworks in several countries), enterprise customers during procurement, and increasingly your own security team, because SBOM-based monitoring is the fastest way to answer which products a new CVE affects.

What makes an SBOM good rather than merely present?

Generated from real builds rather than assembled by hand, complete with transitive dependencies and their relationships, honest about anything it could not resolve, schema-valid, and regenerated every release. SBOMs failing those properties are increasingly rejected by reviewers.

See SBOM in practice, on your own code
A 30-minute live session inside a network like yours.
Request a demo