Software Bill of Materials (SBOM) Explained

In Omdia's 2026 software supply chain security report, 73% of organizations that generate SBOMs say they enable more efficient vulnerability mitigation — yet 86% still find the generation process challenging. That gap between recognized value and operational difficulty is where most teams are stuck. If you build or secure containerized applications, understanding what an SBOM is and how to make it useful is no longer optional.

This covers what SBOMs contain, why they matter for supply chain security, how the standard formats and tooling work, and where regulation is pushing the industry.

What Is an SBOM?

Every software artifact ships with dependencies. A container image based on Alpine might include dozens of system packages, each with its own version, license, and upstream maintainer. The application layer on top adds frameworks, libraries, and transitive dependencies the developer may never have explicitly chosen. The deeper the stack, the harder it gets to answer a basic question: what is actually running in production?

A software bill of materials answers that. It's a structured, machine-readable inventory of every component, library, and module inside a software artifact. Where a package manifest like package.json or requirements.txt lists declared dependencies, an SBOM captures the resolved dependency tree after the build — transitive dependencies, system-level packages, and metadata about each component's origin, version, and license. A nutrition label for software.

What an SBOM Contains

A well-formed SBOM includes several categories of metadata per component:

• Component identity — name, version, supplier (e.g. openssl 3.1.4, maintained by the OpenSSL Project)
• Licensing — the license governing redistribution and use (MIT, Apache 2.0, GPL)
• Dependency relationships — how components depend on each other, direct and transitive
• Unique identifiers — Package URLs (purl) or SWID tags for cross-referencing against vulnerability databases
• Checksums and digests — cryptographic hashes so consumers can verify a component hasn't been tampered with

This data is structured using open standards — primarily SPDX or CycloneDX — to stay machine-readable and interoperable across tools, registries, and compliance workflows. An SPDX entry for a single package looks like this:

{
  "name": "openssl",
  "SPDXID": "SPDXRef-Package-openssl",
  "versionInfo": "3.1.4",
  "supplier": "Organization: OpenSSL Project",
  "licenseDeclared": "Apache-2.0",
  "checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}

A real SBOM contains one entry like this for every component in the artifact, from the base image's OS packages up through the application's runtime dependencies.

Why SBOMs Matter for Supply Chain Security

The value becomes obvious the moment something goes wrong. When Log4Shell was disclosed in December 2021, organizations with current SBOMs queried their inventories and identified every affected image within minutes. Teams without them spent days manually tracing dependencies across registries and deployment manifests.

Sonatype's research found that nearly 65% of open source CVEs lack an NVD-assigned CVSS score — and when scored independently, 46% turned out to be high or critical. Without an SBOM, those unscored vulnerabilities are effectively invisible.

Faster incident response

When a new CVE drops, the first question is always where are we exposed? An SBOM makes that answerable in seconds rather than days. Cross-reference the affected package and version against your SBOM library and you have an immediate blast radius. Pair it with continuous vulnerability scanning and the process automates: new CVEs match against existing SBOMs, affected images get flagged, no manual tracing.

Regulatory compliance

SBOMs are moving from best practice to legal requirement. In the US, Executive Order 14028 set SBOM requirements in motion for software sold to federal agencies. CISA's 2025 Minimum Elements guidance clarifies what a useful SBOM should include. The EU's Cyber Resilience Act (CRA) extends similar requirements to products sold in the European market. For regulated industries — finance, healthcare, defense, critical infrastructure — SBOM delivery is becoming a procurement gate.

Proactive verification, not reactive trust

SBOMs shift the model from assuming software is safe to verifying it. Rather than trusting a base image is clean because the registry says so, you inspect the SBOM to confirm which packages are present, which versions run, and whether any known vulnerabilities apply.

In practice that means writing policies against SBOM data: no image ships if it contains a package from an unapproved supplier, no end-of-life component persists past a defined grace period, no image deploys without a matching SBOM attestation. These checks run automatically in CI, turning the SBOM from a passive document into an active gate. Combined with provenance attestations and cryptographic signatures, the SBOM becomes one layer in a verifiable chain of custody from source to deployment.

SBOM Formats and Standards

For an SBOM to be useful across teams, tools, and organizations, it needs a shared language. Two open standards dominate, each built for a different primary use case.

SPDX (Software Package Data Exchange) — developed by the Linux Foundation (ISO/IEC 5962:2021), the most widely adopted format for license compliance and open source auditing. It's the format BuildKit's built-in generator attaches as an attestation to the container image during build.

CycloneDX — developed by the OWASP Foundation, optimized for security workflows and DevSecOps pipelines. It includes fields for vulnerability metadata and dependency graphs, and integrates well with tools like OWASP Dependency-Track.

If you're building container images, start with SPDX — it's what BuildKit generates natively, so you get an SBOM as a build output with zero extra tooling. Your downstream scanners may prefer CycloneDX, which is fine; the two are interoperable and converters exist. Let the build produce SPDX, let consumption tools convert if they need to.

SWID (Software Identification Tags), a third format (ISO/IEC 19770-2), is used mainly for IT asset management in enterprise and government procurement, but has largely lost traction in cloud-native and container workflows.

How SBOMs Fit Into Container Workflows

Traditionally SBOMs get bolted on after the fact, as a compliance artifact during release. Container workflows offer a better approach: generate the SBOM at build time, as a native output of the image build.

Build-time generation

When you build with BuildKit, the builder scans the final image filesystem and produces an SBOM reflecting what actually shipped, not just what the Dockerfile declared. Because it captures the resolved state after all build stages complete, it includes OS-level packages, application dependencies, and anything copied in from external sources.

⚠️ This is the part that matters most. Source-level SBOMs generated from manifest files before the build routinely miss transitive dependencies and system packages — exactly the components that bite you during a Log4Shell-style incident, since the affected library is often a transitive dependency three levels deep. An image-layer SBOM reflects reality; a manifest-derived one reflects intentions. If you only do one thing here, generate at the image layer.

Attestation and provenance

An SBOM tells you what's in an image. Provenance attestations tell you how it was built: which builder, which source commit, which platform. Together they form a verifiable chain of evidence that auditors and policy engines can evaluate programmatically. This is the model SLSA (Supply-chain Levels for Software Artifacts) describes, where Build Level 3 requires hardened build platforms with non-falsifiable provenance. SLSA is the specification; in-toto is the attestation format it uses. The SBOM attaches to the image as an in-toto attestation using the SPDX predicate, and provenance attaches the same way, so both travel with the image as verifiable metadata.

Registry storage

Once built, the image and its attestations need to live where consumers can reach them. Pushing to an OCI-compliant registry keeps the SBOM co-located with the artifact it describes. This matters because an SBOM living in a separate system — a shared drive, a compliance portal, a CI artifact bucket — eventually drifts out of sync with the image it was generated from. Co-location eliminates the gap: pull the image, pull its SBOM and provenance with it.

Continuous scanning and policy enforcement

With SBOMs attached and stored, they become inputs for continuous monitoring. New CVEs match against the components listed in the SBOM without re-analyzing the image. Then policy engines act on the results: gate deployments on maximum CVE age, block unapproved suppliers, refuse end-of-life components, require a matching SBOM attestation. Scanning identifies risk; enforcement acts on it — and both run in CI before the image reaches production.

SBOM Maturity Model

Adoption isn't binary. Most organizations sit somewhere between ad hoc and fully scaled. Use this to assess where you are and what to prioritize next.

Omdia's 2026 survey found more than half of organizations generating SBOMs are only doing so case-by-case — which means most teams sit at ad hoc or pilot, not production.

Common Misconceptions

"SBOMs are just a compliance checkbox." Teams that generate them solely to satisfy procurement miss the operational value. An SBOM is most useful as a live data source for vulnerability management, incident response, and dependency tracking. One generated for an audit and filed away provides a false sense of coverage.

"They're the same as SCA." Software composition analysis scans code or images for known vulnerabilities. An SBOM is the inventory that makes that scanning possible. They work together — the SBOM is the inventory, SCA uses it (often generating its own) to check for vulnerabilities. Scanning is only as good as the inventory behind it.

"SBOMs are a one-time artifact." An SBOM is tied to a specific image digest. Every rebuild should regenerate it to reflect dependency changes. Stale SBOMs create a gap between what you think is running and what's deployed. Automated build-time generation eliminates the drift.

"SBOMs substitute for runtime security." They tell you what shipped, not what's happening at runtime. An SBOM won't catch an undisclosed zero-day, detect anomalous process behavior inside a running container, or verify application logic is correct. ⚠️ This is the one to internalize: SBOMs are inventory and composition, one layer in defense-in-depth. Runtime monitoring, network policies, and access controls handle the rest. A complete SBOM on an image with a compromised running process is still a compromised running process.

Getting Started

The common mistake is treating SBOM adoption as a large transformation project. It doesn't need to be.

1. Start with one image. Pick a production image and enable SBOM generation on the next build. With BuildKit it's a single flag:

docker buildx build --attest type=sbom --tag myapp:latest .

Review the output — this one step often reveals transitive dependencies and OS packages you didn't know were in the image.

2. Automate generation in CI. Extend the flag so every image build produces an SBOM automatically.
3. Store SBOMs alongside images. Attach them as attestations in your OCI registry so the SBOM stays co-located with what it describes.
4. Connect to monitoring. Feed SBOMs into a vulnerability tool that continuously matches components against new CVEs. This closes the loop between inventory and action.
5. Set policies. Define what's acceptable — maximum CVE age, required SBOM completeness, blocked licenses — and enforce in the pipeline so non-compliant images get flagged before deployment.

Bottom Line

SBOMs are the foundation of software supply chain security. They turn opaque artifacts into transparent, auditable inventories that security, compliance, and developers can all use. But an SBOM alone isn't enough. The value comes when they're generated at build time, paired with provenance attestations, and continuously monitored against emerging threats. Generate at the image layer, co-locate with the artifact, regenerate on every rebuild, and gate deployments on the results — that's the difference between an SBOM that satisfies an auditor and one that actually shortens your next incident.

References

• Docker: What Is an SBOM? (source)
• SPDX (Software Package Data Exchange)
• CycloneDX (OWASP)
• SLSA: Supply-chain Levels for Software Artifacts
• in-toto: Attestation Framework
• CISA: 2025 Minimum Elements for an SBOM
• NIST: Executive Order 14028 Software Supply Chain Security Guidance
• BuildKit SBOM Attestations
• OWASP Dependency-Track