SBOM Explained: A Practitioner Guide to the Software Bill of Materials

Before 2021, the phrase "software bill of materials" lived in supply-chain working groups, hardware compliance literature, and a handful of pioneering open-source projects. Outside that circle, almost nobody asked for one. Then SolarWinds happened, then Kaseya, then Log4Shell, and the question every CISO and procurement lead suddenly needed to answer was the same: what is actually inside the software we ship and the software we buy. An SBOM is the artifact that answers that question. It enumerates components, versions, suppliers, and dependency relationships in a structured format that another tool can read, query, and compare against advisory databases over time.

This guide is a practitioner walkthrough of SBOMs end to end: the elements an SBOM must contain, the difference between CycloneDX and SPDX, how SBOMs are generated in real build pipelines, the open-source and commercial tooling landscape, how SBOMs are stored and shared with VEX documents and signatures, and the regulatory environment that increasingly makes them mandatory. It is vendor-neutral by design. The goal is to give you a clear enough mental model that whichever tool you eventually pick, you can tell whether its SBOM output is fit for purpose.

What an SBOM Actually Contains

The most cited specification of what an SBOM must contain is the National Telecommunications and Information Administration (NTIA) Minimum Elements for a Software Bill of Materials, published in July 2021 in response to Executive Order 14028. NTIA defined seven baseline data fields that every SBOM should carry. They are the floor, not the ceiling: any production-grade SBOM will include considerably more, but a document missing any of these is not a usable SBOM in the regulatory sense.

• Supplier name: The entity that creates, defines, and identifies the component. For an open-source library this is typically the maintaining project or organization; for a commercial component it is the vendor.
• Component name: The designation assigned by the supplier, such as log4j-core or spring-boot-starter-web.
• Version of the component: The specific resolved version string, not a version range. SBOMs describe what was actually shipped, not what was theoretically permitted.
• Other unique identifiers: Machine-readable coordinates such as a Package URL (purl), a Common Platform Enumeration (CPE) identifier, or a Software Identification (SWID) tag. These let downstream tools cross-reference the component against vulnerability and license feeds without ambiguity.
• Dependency relationship: How the components relate to each other. A modern SBOM is a graph, not a flat list: the document records which components include or depend on which others, recursively.
• Author of SBOM data: The entity that produced the SBOM document, which is often distinct from the supplier of the components themselves.
• Timestamp: When the SBOM was generated. SBOMs go stale as advisories evolve, so a timestamp is essential for downstream consumers deciding how much to trust a given document.

Real-world SBOMs go beyond the minimum elements with extensions that make the document usable for automation. Cryptographic hashes of each component (typically SHA-256 or SHA-512) let consumers verify that the component named in the SBOM is the same artifact present in the build. License declarations, expressed as SPDX identifiers, support compliance review alongside security review. External references point to source repositories, advisory databases, distribution registries, and project home pages so that a human triaging a finding can pivot from the SBOM entry directly to upstream context.

Two important nuances: an SBOM describes a single artifact at a single moment, and it does not by itself say anything about whether any component is vulnerable. The SBOM is the inventory; vulnerability matching is a separate continuous process layered on top of it.

The Two Standards: CycloneDX vs SPDX

Two standards dominate the SBOM ecosystem, and a third (SWID tags, defined in ISO/IEC 19770-2) appears mostly as an identifier carried inside the other two rather than as a transport format on its own.

CycloneDX began as an OWASP project in 2017 with an explicit focus on application security and supply-chain risk. It is now governed under OWASP's project process and has matured through multiple major versions, with v1.6 introducing extended support for cryptographic asset inventories, machine-learning model provenance, and SaaS service descriptions in addition to traditional software components. CycloneDX is intentionally extensible, lightweight, and oriented around vulnerability and exploitability metadata. It supports JSON, XML, and Protocol Buffers as serializations.

SPDX (Software Package Data Exchange) is older, originating in the Linux Foundation in 2010, and was historically rooted in license compliance. Its maturity in licensing terms is unmatched: the SPDX License List is the canonical source of standardized open-source license identifiers used across the industry. SPDX 3.0, released in 2024, restructured the specification into modular profiles (Core, Software, Build, AI, Dataset, Security, Licensing) so that an SBOM can carry exactly the dimensions a given use case needs. SPDX is also recognized as ISO/IEC 5962:2021, which gives it a level of formal international standing CycloneDX does not currently hold. Serializations include JSON, YAML, RDF, and the original tag-value text format.

Practical guidance: pick one as your primary internal format, but ensure your tooling can emit the other on demand. Customers, regulators, and partners differ in what they prefer to ingest, and translating between the two is well-supported through tools like the CycloneDX CLI and SPDX SBOM utilities. The two formats overlap heavily on the core data model, and most production SCA tools generate both directly from the same internal dependency graph.

A Real SBOM Example

The clearest way to understand an SBOM is to read one. Below is an annotated CycloneDX 1.5 JSON snippet showing a single component entry as it would appear inside the larger components array. This is not a complete document, but it covers the fields a downstream tool actually needs to reason about the component:

{
  "type": "library",
  "bom-ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
  "group": "org.apache.logging.log4j",
  "name": "log4j-core",
  "version": "2.17.1",
  "description": "The Apache Log4j Implementation",
  "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
  "hashes": [
    {
      "alg": "SHA-256",
      "content": "9e7c4c0aebbcd3f3c7e2f8b4c8dabe6e9d4d2fa8e3a4f0d6c1b9e7a5b2c1d3e4"
    }
  ],
  "licenses": [
    { "license": { "id": "Apache-2.0" } }
  ],
  "externalReferences": [
    { "type": "vcs", "url": "https://github.com/apache/logging-log4j2" },
    { "type": "website", "url": "https://logging.apache.org/log4j/2.x/" }
  ]
}

Five things to notice. The bom-ref is the document-internal handle that the SBOM's dependencies graph uses to point at this component. The purl is the universal coordinate that any external tool can use to query advisory databases without ambiguity. The hash lets a verifier confirm that the artifact in the build matches the one described in the SBOM. The license is given as an SPDX identifier, which is what makes downstream legal automation possible. The external references give a human triager somewhere to click. Multiply this entry by several hundred, wire them together with a dependency graph, wrap it all in metadata about who generated the document and when, and you have an SBOM.

How SBOMs Get Generated

There are three common generation strategies, and they trade off accuracy against where in the lifecycle they can be applied. Mature programs typically use more than one, because each strategy sees something the others miss.

Build-time generation is the preferred approach when you control the build. The SBOM tool runs as part of the CI pipeline, observes the actual resolved dependency graph the build system computed, and records exactly what went into the artifact. Maven, Gradle, npm, pip, Go, Cargo, and the rest expose that resolved graph through their own APIs and lockfiles, and tools that hook into the build read it directly. The CycloneDX project ships build plugins for Maven, Gradle, npm, and several other ecosystems that emit SBOMs as a build step, and the Microsoft SBOM tool integrates similarly into MSBuild and other Microsoft-stack builds. Build-time SBOMs are the most accurate because they describe the actual artifact, not an approximation of it.

Source-time generation reads the manifest and lockfile from a checked-out source tree without invoking the build. It is faster than a full build and useful in environments where running the build is expensive or impossible. The downside is that anything resolved dynamically at build time, anything injected by a build plugin, or anything that varies by platform may not appear correctly. Most SCA scanners that operate purely on source code take this path. SPDX SBOM Generator is a representative open-source tool in this category, and CycloneDX has source-time generators for many ecosystems as well.

Binary scanning works on artifacts you did not build yourself: container images pulled from a registry, a JAR file from a vendor, a firmware image. The tool inspects the artifact, identifies installed packages and embedded libraries by signature or metadata, and produces an SBOM after the fact. This is the only option when the source is unavailable. Syft (from Anchore) and Trivy (from Aqua Security) are the two open-source workhorses here, both of which generate CycloneDX and SPDX output and are widely embedded in container security pipelines. Tern is another open-source option focused specifically on container layers and the licenses present inside them.

The honest practitioner answer is that build-time is the gold standard for software you own, and binary scanning is what you fall back to for everything else. A program that combines both ends up with SBOMs that are both authoritative for its own releases and complete for its third-party supply chain.

The SBOM Tool Landscape

Buyers searching for sbom tools — whether they want a generator, a viewer, or one of the so-called best sbom tools that combine generation with continuous vulnerability tracking — usually arrive on a fragmented landscape that overlaps heavily with the broader SCA category. A practical sbom viewer is often just the dashboard inside an SCA platform that already produced the document; a dedicated standalone viewer (the OWASP Dependency-Track web UI is the canonical free option) is useful when you need to ingest SBOMs from third parties without running the upstream scanner yourself. The role of sbom cyber security tooling specifically is to keep the inventory continuously matched against the latest vulnerability and license advisories, not just to emit a one-time document.

The SBOM tooling space is large, fragmented, and increasingly indistinguishable from the broader SCA tooling space. Most teams will encounter some combination of the following. The list is not exhaustive, and the descriptions are deliberately limited to publicly documented capabilities.

A common architecture is to use a generator (Syft, Trivy, a CycloneDX build plugin, or the Microsoft SBOM tool) at build time, then upload the resulting SBOMs to a repository like OWASP Dependency-Track or a commercial equivalent that stores them centrally and continuously re-evaluates them against new vulnerability disclosures. This separates "produce the inventory" from "track risk against the inventory" and lets each tool do what it does best.

SBOM Sharing, Storage, and VEX

Generating an SBOM is the easy part. Storing it, sharing it with the right audiences, and keeping its risk picture current is the discipline that separates a checkbox SBOM program from a useful one.

Storage is increasingly handled by attaching SBOMs to release artifacts directly, often via the OCI referrers API for container images or as release assets next to the binary. CISA's published SBOM sharing guidance describes a continuum from private exchange under NDA, through controlled distribution to qualified parties, to fully public publication, and reasonable programs use different points on that continuum for different products.

Signing matters because an unsigned SBOM is not evidence of anything; a downstream consumer cannot tell whether the document was tampered with. The Sigstore project (cosign in particular) is the de facto open-source way to sign SBOMs and store the signatures in the Rekor transparency log, allowing consumers to verify both authorship and integrity.

VEX (Vulnerability Exploitability eXchange) is the companion artifact that makes a continuously evaluated SBOM operationally tolerable. A raw vulnerability match against an SBOM produces noise: a CVE in a transitive library may be present in the artifact but unreachable from any code path your application actually executes. A VEX statement is a machine-readable assertion from the supplier saying, in effect, "we know about CVE-X in component-Y at version-Z, and our analysis is that it is not exploitable in this product because [reason]." VEX is supported natively in CycloneDX and is published as a separate format by CISA and OASIS (CSAF VEX). It does not replace the SBOM; it overlays it, letting consumers separate "components present" from "vulnerabilities that actually warrant attention here."

SBOM Compliance: EO 14028, OMB M-22-18, and the EU CRA

SBOMs moved from "nice to have" to "regulatory requirement" in a remarkably short window. Three pieces of policy define the current landscape for most organizations.

Executive Order 14028, signed by President Biden on May 12, 2021, directed federal agencies to improve the nation's cybersecurity in the wake of SolarWinds. Section 4 of the order specifically addressed software supply-chain security, requiring NIST to publish guidelines for secure software development and directing that software sold to the federal government conform to those guidelines. The NTIA Minimum Elements for an SBOM, published in July 2021, was the direct downstream product that defined what a federally acceptable SBOM must contain.

OMB Memorandum M-22-18, issued in September 2022, operationalized EO 14028 for federal agencies. It required agencies to obtain self-attestations from software suppliers conforming to the NIST Secure Software Development Framework, and explicitly identified SBOMs as one of the supporting artifacts agencies could request. M-22-18 was further clarified by M-23-16 in 2023, which adjusted timelines and the exact attestation form, but the core obligation, that vendors selling to the federal government must demonstrate secure development practices and produce SBOMs on request, remains. The reference framework on the NIST side is SSDF (Secure Software Development Framework), published as NIST SP 800-218; we walk through the practices in our guide to NIST SSDF and SP 800-218.

The EU Cyber Resilience Act (CRA), adopted by the European Parliament and Council in October 2024 and entering force progressively over the following years, extends comparable obligations to manufacturers of "products with digital elements" sold into the European market. SBOM-style component documentation is part of the technical documentation manufacturers must maintain, and vulnerability handling and disclosure obligations attach across the product lifecycle. The CRA is broader than EO 14028 in scope, applying not only to government procurement but to commercial product sales, which means SBOM requirements are no longer a federal-contracts-only concern for any vendor selling internationally.

Beyond formal regulation, enterprise vendor risk management programs increasingly request SBOMs as part of standard due diligence. The practical effect, even before any law applies to your organization directly, is that customers are asking.

Building an SBOM Practice

A working SBOM practice is built around four habits, in this order:

• Generate at build time. Wire SBOM generation into CI so every release artifact is accompanied by a freshly produced SBOM in your chosen format. Build-time generation captures what was actually built, not an approximation, and removes the "we'll generate one when someone asks" failure mode.
• Store with the artifact. Attach the SBOM (and its signature) to the release in your artifact registry or release-management system so that anyone consuming the binary can also retrieve its inventory. Lost SBOMs are useless SBOMs.
• Consume continuously. Vulnerability disclosures arrive after release, often months or years after. Pipe stored SBOMs into a tool that re-evaluates them against the latest advisory feeds and notifies you when a previously clean component has a new CVE. OWASP Dependency-Track is the canonical open-source pattern; commercial SCA platforms ship equivalent capability.
• Share when asked. When a customer or regulator requests an SBOM, you should be able to produce one for any shipped release within minutes, not weeks. The previous three habits are what make that possible.

In practice, the SBOM and the SCA scan are two outputs of the same pipeline. The dependency tree the SCA tool computes to look up vulnerabilities is the same tree the SBOM serializes for downstream sharing. GraphNode SCA generates SBOMs as part of its dependency analysis, alongside vulnerability tracking and license compliance, so that the inventory and the risk picture move through the program together. For a deeper walk through what an SCA scan does mechanically, including how the resolved tree feeds the SBOM, see our SCA scan guide. For how SBOMs interact with the broader supply-chain integrity story, our SLSA overview covers how provenance and SBOMs answer different but complementary questions.

Frequently Asked Questions

What is an SBOM?

An SBOM, or Software Bill of Materials, is a structured, machine-readable inventory of every component inside a piece of software, including transitive open-source dependencies. It records each component's name, version, supplier, unique identifiers (such as Package URLs), dependency relationships, and the timestamp and author of the SBOM document itself. The two dominant SBOM formats are CycloneDX (OWASP) and SPDX (Linux Foundation, recognized as ISO/IEC 5962:2021). An SBOM is the foundation downstream tools use to track vulnerabilities, license obligations, and regulatory compliance across a software portfolio.

What is the difference between an SBOM and SCA?

SCA (Software Composition Analysis) is the process and tooling category that enumerates a project's open-source dependencies and matches them against vulnerability and license databases. An SBOM is one of the artifacts SCA tooling produces: the structured inventory output, in CycloneDX or SPDX, that describes the components SCA analyzed. Put differently, SCA is the activity, the SBOM is one of the deliverables. Modern SCA tools generate SBOMs as a standard export from the same dependency tree they use for vulnerability matching.

CycloneDX vs SPDX: which should I use?

Both are accepted under EO 14028 and CISA guidance, and both are well-supported across the tooling ecosystem. CycloneDX tends to be preferred when application security and vulnerability management are the primary drivers, given its native VEX support and modern extensibility model. SPDX tends to be preferred where license compliance and formal international standardization matter most, given its ISO/IEC 5962:2021 status and modular profiles in version 3.0. The pragmatic recommendation is to standardize on one internally for consistency, but ensure your tooling can emit the other on demand, because customers and regulators differ in their preferences.

Is an SBOM mandatory?

For software sold to the US federal government, yes, in effect: Executive Order 14028 (signed May 2021) and OMB Memorandum M-22-18 (issued September 2022) require self-attested conformance with the NIST Secure Software Development Framework and identify SBOMs as a supporting artifact agencies may request. The EU Cyber Resilience Act, adopted in October 2024, extends comparable obligations to manufacturers of digital products sold into the European market. Even outside formal regulation, enterprise vendor risk management programs increasingly require SBOMs as part of standard procurement due diligence, so the practical answer for most software vendors is moving toward "yes."

What is a VEX document?

VEX stands for Vulnerability Exploitability eXchange. It is a machine-readable assertion from a software supplier about whether a known CVE is actually exploitable in a specific product. A raw match between an SBOM and a vulnerability feed often surfaces CVEs that affect a component's code path that the application never invokes; VEX lets the supplier formally state "this CVE is present but not exploitable here, for this reason." VEX is supported natively in CycloneDX and as a standalone format through OASIS CSAF VEX and CISA's published guidance. It does not replace the SBOM; it overlays it, letting consumers prioritize the vulnerabilities that actually warrant attention.