What Is a Software Bill of Materials (SBOM)?

When Log4Shell broke on December 10, 2021, the first question in every SOC was not how to patch it. It was simpler and worse: do we even run Log4j, and where? CVE-2021-44228 scored a CVSS 10.0 and sat inside log4j-core, a logging library bundled three and four layers deep inside applications nobody thought of as "Java apps." Teams with an inventory of their software components answered in an afternoon. Teams without one spent weeks grepping build servers and emailing vendors.

A Software Bill of Materials (SBOM) is the artifact that answers that question before the incident. It is a formal, machine-readable list of every component that makes up a piece of software: each open-source library, each dependency, its version, its supplier, and how the pieces relate. The name is borrowed from manufacturing, where a bill of materials lists every part in a physical product. An SBOM does the same for code.

This guide covers what an SBOM contains, the two dominant formats (SPDX and CycloneDX), the policy that pushed SBOMs into the mainstream (Executive Order 14028 and the resulting CISA and NTIA guidance), how SBOMs are generated, and how a blue team actually uses one during vulnerability management and incident response.

What is a Software Bill of Materials (SBOM)?

A Software Bill of Materials is a structured, machine-readable inventory of the components and dependencies that make up a software product, recording each component's name, version, supplier, and relationship to the others. It is the ingredient list for an application: not the source code, but a complete accounting of what is inside the shipped artifact.

The reason it matters is that modern software is assembled, not written from scratch. A typical application is a thin layer of first-party code sitting on a deep stack of open-source libraries, which themselves pull in further dependencies. These transitive dependencies, the libraries your libraries depend on, are where the risk hides. A developer who adds one package can unknowingly pull in dozens more, and a vulnerability in any one of them becomes a vulnerability in the finished product. This is the heart of the software supply chain attack problem: you inherit the security posture of code you never wrote and may not know you depend on.

Without an SBOM, that dependency tree is invisible. You know your own code. You do not reliably know the version of every nested library three levels down, and that is exactly where a critical CVE will land. The SBOM makes the invisible visible: it is the difference between answering "are we exposed to this CVE" with a database query versus a fire drill.

An SBOM is descriptive, not a verdict. It does not say the software is secure. It says what the software is made of. The security work, matching components against known vulnerabilities, comes after, and the SBOM is what makes that work fast and complete instead of slow and partial.

What an SBOM contains: the minimum elements

An SBOM is only useful if every producer records the same baseline data. In July 2021, the National Telecommunications and Information Administration (NTIA) published "The Minimum Elements for a Software Bill of Materials," the reference baseline that later guidance builds on. It defines the minimum data fields every SBOM should carry.

The minimum elements are deliberately a floor, not a ceiling. The NTIA framing also calls for two things beyond the data fields: automation support, meaning the SBOM is produced in a machine-readable format a tool can ingest, and practices and processes, meaning the SBOM is generated and updated as part of the build rather than written by hand once.

Two fields carry more weight than they look. The unique identifier is what makes automated vulnerability matching possible: a Package URL like pkg:maven/org.apache.logging.log4j/[email protected] maps a component to vulnerability databases without guesswork. The dependency relationship is what exposes the transitive layer, the nested components that a flat list of "what we installed" would miss.

SPDX vs CycloneDX: the two formats

A machine-readable inventory needs a shared format, and two dominate. Both are open standards, both are accepted by US federal guidance, and both express the same core idea in different shapes.

SPDX (Software Package Data Exchange) came out of the Linux Foundation and was built first for license compliance, tracking which open-source licenses ship inside a product. It became an international standard, ISO/IEC 5962:2021, and the current specification is SPDX 3.0.0, released in April 2024. Its strength is depth and provenance: it can describe software down to the file and snippet level.

CycloneDX came out of the OWASP community and was designed from the start for security use cases. It is now standardized as ECMA-424, jointly advanced by OWASP and Ecma International's TC54, with the specification at version 1.7 as of October 2025. Its strength is the security ecosystem around it: it extends naturally to a SaaSBOM, a hardware BOM, a machine-learning BOM, a cryptography BOM, and it carries VEX (Vulnerability Exploitability eXchange) to state whether a known vulnerability in a listed component is actually exploitable in your product.

A third format, SWID (Software Identification) tags, an ISO/IEC 19770-2 standard, is recognized alongside these in federal guidance but is primarily an asset-management identifier rather than a full dependency inventory. In practice, SPDX and CycloneDX are the two you will encounter generating and consuming SBOMs.

The practical guidance is not to crown a winner. Pick based on the consumer. If license compliance and the broadest tooling matter, SPDX fits. If security workflows, VEX, and OWASP-ecosystem tools matter, CycloneDX fits. Many toolchains can emit both, and converters exist, because the two encode the same minimum elements.

Why SBOMs became mandatory: EO 14028 and CISA

SBOMs existed as a niche practice for years before policy turned them into a baseline expectation. The turning point was Executive Order 14028, "Improving the Nation's Cybersecurity," signed May 12, 2021, in the wake of the SolarWinds supply chain compromise.

EO 14028 directed the National Institute of Standards and Technology (NIST) and the NTIA to establish guidelines for software supply chain security, and it explicitly called for SBOMs from vendors selling software to the federal government. The logic was direct: if the government is going to buy software, it should know what is in that software. The NTIA Minimum Elements document followed in July 2021 as the answer to "what counts as an SBOM."

The Cybersecurity and Infrastructure Security Agency (CISA) then took over as the operational home for SBOM work. CISA maintains the ongoing community guidance: documents on SBOM types, on shared terminology, on how an SBOM should be produced and consumed, and the framing that connects SBOMs to VEX so that a long list of "components with known CVEs" can be narrowed to the ones that are actually exploitable. The reference list of accepted formats, SPDX, CycloneDX, and SWID, traces back to this NTIA and CISA lineage.

The effect was a ratchet. Once federal procurement expected SBOMs, the requirement propagated down the supply chain to every vendor that wanted to sell upward, and SBOM generation moved from a security team's nice-to-have into the default build pipeline. The policy did not invent the SBOM. It made the absence of one a procurement problem.

How SBOMs are generated

An SBOM is most trustworthy when a tool produces it automatically as part of the build, not when a human writes it after the fact. There are three common points in the lifecycle where one is generated, and they see different things.

At build time, an SBOM generator runs inside the CI/CD pipeline and reads the dependency manifests and lockfiles (package-lock.json, pom.xml, go.sum, and the like) to record exactly what was pulled in. This is the highest-fidelity moment, because the build system has ground truth about resolved versions, including the transitive dependencies. Tools that integrate here are the core instruments of DevSecOps: the same pipeline that builds the artifact emits its ingredient list.

By scanning a finished artifact, a tool inspects a container image, a binary, or a filesystem after the fact and infers the components present. This is how you generate an SBOM for software you did not build, including third-party and legacy artifacts. It is less precise than build-time generation, because some components are harder to identify once compiled, but it is often the only option for code you received rather than wrote.

At distribution or runtime, an SBOM travels with the software so the consumer can verify what they received, or a runtime tool reports what is actually loaded in a running system. The runtime view answers a different question from the build view: not "what could be present" but "what is actually executing."

The output of all three is the same kind of artifact, an SPDX or CycloneDX document, that downstream tools can ingest. Generation is the cheap part. The value comes from what you do with the SBOM next.

How blue teams use an SBOM

An SBOM is a build artifact, but its payoff lands on the defender's desk during vulnerability management, incident response, and procurement review. Reading and querying SBOMs is a practical blue-team skill.

Answer "are we affected" in minutes, not weeks. This is the Log4Shell scenario. When a critical CVE drops, the question is which of your applications contain the vulnerable component and version. With SBOMs stored and queryable, that is a search across your inventory: find every artifact whose dependency list includes log4j-core at an affected version. Without them, it is a manual hunt across teams and build systems while the clock runs.

Drive continuous vulnerability management. An SBOM is the input that makes component-level scanning complete. Matching each listed component and version against vulnerability databases turns a static inventory into a live risk feed, and it is what connects SBOMs to a real vulnerability management program rather than a one-time audit. New CVEs are matched against the existing SBOM the moment they are published, with no rescan of the source needed.

Cut the noise with VEX. A raw SBOM-plus-CVE match produces a long list, much of it not actually exploitable, because the vulnerable function may never be reached in your usage. VEX, the Vulnerability Exploitability eXchange that CycloneDX carries, lets a producer assert "this CVE is present but not exploitable here," turning an unmanageable list into a prioritized one. This is the difference between an SBOM that creates work and one that reduces it.

Vet third-party and open-source risk before you ship. Requesting an SBOM from a vendor, or generating one for an open-source package before adopting it, surfaces what you are about to depend on. It is a core input to assessing open-source software security and to deciding whether a dependency is worth the supply-chain exposure it brings. The SBOM turns "we trust this vendor" into "here is what this vendor ships, and here is its known-CVE status."

Scope an incident faster. When a component is found to be compromised at the source, a supply-chain attack rather than just a vulnerable version, the SBOM is the blast-radius map. It tells responders every product that includes the compromised component, so containment targets the right systems instead of guessing.

SBOM limitations to keep in sight

An SBOM is necessary, not sufficient, and treating it as a security guarantee is its own risk. A few limits matter for triage.

An SBOM lists components; it does not assess them. A component can be present, current, and still vulnerable, or present and vulnerable but unreachable in your code path. The SBOM is the input to that judgment, not the judgment itself, which is why VEX exists alongside it.

An SBOM is a snapshot. It is accurate for the build it describes and goes stale the moment dependencies change, so an SBOM that is not regenerated on every build slowly drifts from reality. Quality also varies: an SBOM that records direct dependencies but misses the transitive layer hides exactly the risk that matters most. Completeness and freshness are the two properties to check before you trust one.

None of this argues against SBOMs. It argues for treating the SBOM as the foundation of component-level security work, the inventory everything else is built on, rather than as the finished product.

Frequently Asked Questions

What is a Software Bill of Materials (SBOM)?

A Software Bill of Materials is a formal, machine-readable inventory of every component and dependency that makes up a software product, recording each component's name, version, supplier, and how the pieces relate. It is the ingredient list for an application. It does not assess security on its own; it is the inventory that makes fast, complete vulnerability matching possible.

What is the difference between SPDX and CycloneDX?

SPDX and CycloneDX are the two dominant SBOM formats. SPDX, stewarded by the Linux Foundation and standardized as ISO/IEC 5962:2021, originated in license compliance and offers deep, file-level provenance detail. CycloneDX, stewarded by OWASP and standardized as ECMA-424, was built for security use cases and extends to VEX, SaaSBOM, and other BOM types. Both encode the same minimum data elements, and many tools can emit either.

Why are SBOMs required now?

Executive Order 14028, signed May 12, 2021 after the SolarWinds compromise, directed federal agencies to require SBOMs from software vendors and tasked NIST and the NTIA with setting the guidelines. The NTIA published the minimum elements in July 2021, and CISA now maintains the ongoing guidance. Because federal procurement expects SBOMs, the requirement has propagated down the software supply chain.

What information does an SBOM contain?

At minimum, per the NTIA, an SBOM records seven data fields for each component: supplier name, component name, version, other unique identifiers (such as a Package URL or CPE), dependency relationship, the author of the SBOM data, and a timestamp. The framing also calls for the SBOM to be machine-readable and generated as part of a repeatable process rather than written by hand.

How is an SBOM generated?

The most reliable method is automatically at build time, when a generator runs in the CI/CD pipeline and reads dependency manifests and lockfiles to capture exact resolved versions, including transitive dependencies. SBOMs can also be produced by scanning a finished artifact such as a container image or binary, or reported at runtime. The output is a standard SPDX or CycloneDX document that downstream tools ingest.

How does an SBOM help during an incident like Log4Shell?

When a critical CVE such as Log4Shell (CVE-2021-44228) is disclosed, the first question is which systems contain the vulnerable component and version. If your SBOMs are stored and queryable, you answer it with a search across your inventory in minutes. Without SBOMs, the same question becomes a manual hunt across teams and build systems while the vulnerability is being actively exploited.

Is an SBOM enough to secure software?

No. An SBOM lists what software is made of; it does not assess whether those components are exploitable in your context. It is a snapshot that goes stale as dependencies change, and its value depends on completeness, especially of transitive dependencies. The SBOM is the foundation for component-level vulnerability management and VEX-based prioritization, not a security verdict by itself.

The bottom line

A Software Bill of Materials is the ingredient list for your software: every component, every version, every supplier, and how they nest. Modern applications are assembled from deep stacks of open-source dependencies, and the SBOM is what makes that hidden stack visible before a critical CVE forces the question.

Two open formats carry it. SPDX (ISO/IEC 5962:2021, Linux Foundation) leads on license compliance and provenance; CycloneDX (ECMA-424, OWASP) leads on security and carries VEX to separate "present" from "exploitable." Executive Order 14028 and the NTIA minimum elements turned the SBOM from a niche practice into a procurement baseline, with CISA maintaining the guidance.

For a defender, the SBOM is leverage at the worst moment. When the next Log4Shell drops, the team with queryable SBOMs answers "are we affected" in an afternoon, and the team without one starts a fire drill. Generate them automatically in the build, keep them complete down to the transitive layer, and pair them with VEX so the output reduces work instead of creating it.