SBOM (Software Bill of Materials)

What is an SBOM?

A software bill of materials (SBOM) is a structured inventory of the components and dependencies inside a piece of software, including versions, suppliers and, in a useful one, the relationships between them. It is the manifest that answers the question of what is actually inside a given build.

Key takeaways

• An SBOM is an inventory, not an assessment. It records what is present. It carries no judgement about whether any of it is exploitable in the environment where the software runs.
• Log4Shell created the demand. In December 2021 most organizations could not answer whether they were affected, because nobody held a reliable list of what their software contained.
• Two formats dominate. SPDX and CycloneDX cover the same ground with different emphases, and mature tooling exists to convert between them.
• Depth varies enormously. A flat list of top-level dependencies and a complete transitive graph are both called bills of materials and are not remotely comparable.
• It matters most for software nobody built in-house. For vendor and appliance software there is no source to analyse, so the supplier's inventory is the only visibility available.

Why it matters

The value of an inventory is answering one question quickly under time pressure. When a widely deployed component is found to be critically flawed, the organizations that respond in hours rather than weeks are those that can enumerate where it is deployed without launching an investigation. Everything else the format enables, from licence compliance to procurement diligence, is secondary.

The limit is equally clear. Knowing a Java logging library is present says nothing about whether the vulnerable code was ever callable, and in a large share of cases it was not, because the application bound its logging facade to a different backend. The library was loaded and the exposure was zero. An inventory cannot distinguish that case from an exploitable one, which is why an inventory-driven response overstates the affected population by a wide margin.

Formats and contents

• SPDX. An ISO-standardized format, ISO/IEC 5962, with a strong licence-compliance heritage and broad adoption in open-source distribution.
• CycloneDX. An OWASP specification designed with security use cases foremost, widely used in application security tooling and extended to services, hardware and machine learning models.
• Core fields. Component name, version, supplier, unique identifiers such as package URLs or CPE strings, and the author and timestamp of the document itself.
• Relationship data. Which component depends on which, expressed as a graph. This is what separates a genuinely useful document from a flat list.
• Exploitability companions. VEX statements, expressed through OpenVEX or CSAF, attach an assertion that a present component is or is not affected, which is the mechanism for communicating the Log4j case above.

Where SBOMs are required

Regulatory and contractual requirements have expanded steadily since United States Executive Order 14028 in 2021 and the minimum-elements guidance NTIA published alongside it. Comparable expectations now appear in European product-security legislation and in sector rules for medical devices, critical infrastructure and automotive software.

The consequence is a compliance-shaped adoption curve. Many organizations generate documents to satisfy an obligation, store them, and never query them. Few have wired the inventory into incident response, so the question of where a component is deployed is still answered by surveying engineering teams.

What an SBOM cannot do

It cannot indicate whether a component sits in a runtime path, or whether it is a build-time tool, a test fixture or a file left in a staging directory. It cannot indicate whether the vulnerable function inside a flagged component is called, or whether attacker-controlled data can reach it. It cannot predict what breaks on upgrade, and it cannot say which team owns the affected application.

Each of those needs a different technique: runtime observation, call graph analysis, data flow analysis, build verification, ownership attribution. The inventory is the input those techniques consume. Treating it as the answer produces a large, accurate and largely unactionable list.

How to evaluate an SBOM

• Transitive completeness. Does the document include the full resolved dependency graph, or only declared direct dependencies. Depth is the single biggest quality differentiator.
• Version precision. Resolved versions with unique identifiers, not declared ranges. A range cannot be matched reliably against an advisory.
• Relationship fidelity. Whether dependency edges are present, and whether the document distinguishes runtime, build and test scopes.
• Provenance and freshness. Who generated the document, from what build, and when. One produced by hand each quarter describes software nobody is running.
• Exploitability signalling. Whether the supplier will issue VEX statements against the inventory, which is what turns a component list into a usable answer during an incident.

Common misconceptions

• That generating one improves security. It improves the speed of answering a question. Security improves only if that answer changes what gets fixed.
• That the two formats are competitors requiring a choice. They overlap heavily and convert reliably. Consuming both is normally less work than mandating one across a supply chain.
• That an inventory equals a vulnerability report. Matching an inventory against advisories is a separate step, and doing it without reachability analysis reproduces the composition-analysis volume problem exactly.
• That vendors will not provide one. Provision has become routine in regulated procurement. The harder negotiation is depth and update cadence, not existence.

Standards and sources

The NTIA minimum-elements publication of 2021 remains the reference point for what a baseline document must contain, and is the definition most procurement language points at. SPDX is maintained by the Linux Foundation and standardized as ISO/IEC 5962; CycloneDX is maintained by OWASP. CISA has published guidance on sharing, consumption and VEX usage, and NIST Special Publication 800-218 places inventory generation within a secure development lifecycle.

FAQ

Does having an SBOM make an organization more secure? Only through what is done with it. It shortens the time to answer whether a component is present, which matters a great deal during an incident and very little on an ordinary day.

Should SBOMs be required from vendors? It is reasonable and increasingly standard. The contract should specify depth and cadence, because a top-level list is far less useful than a full transitive graph with relationships.

How often should an SBOM be regenerated? Every build. A dependency tree changes whenever anything in it is updated, so a stale document describes software that is no longer being shipped.

What is the difference between an SBOM and a VEX document? The inventory says what is present. A VEX statement says whether a present component is actually affected by a given vulnerability, which is the assertion that reduces investigation work.

Sources

• NTIA, The Minimum Elements for a Software Bill of Materials, 2021.
• Linux Foundation, SPDX Specification version 3.0 (ISO/IEC 5962), 2024.
• OWASP, CycloneDX Bill of Materials Specification version 1.6, 2024.
• CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX), 2023.
• NIST, Special Publication 800-218: Secure Software Development Framework version 1.1, 2022.