Software Supply Chain Security: What an SBOM Proves and What It Does Not

A software bill of materials answers exactly one question well, which is whether a newly disclosed vulnerability is present in anything an organization ships, and it answers none of the three questions executives assume it covers: whether a dependency is malicious, whether an artifact was actually built from the source it claims, and whether the vulnerable code is ever executed. That gap is why so many supply chain programs produce inventory theatre. A generation tool runs in the build pipeline, emits a file, attaches it to an artifact nobody verifies, and stores it in a location nobody queries. The regulatory box is ticked and the organization is no more secure than it was, because the three layers that do the work an SBOM gets credit for were never built. This piece separates the four distinct problems that get lumped together, names the tooling and maturity of each, and gives a build order that produces security rather than paperwork.

Key Takeaways

• An SBOM is an inventory, not a control. Its genuine value is answering the Log4Shell question, which is whether an organization is affected by a new disclosure and where, in hours rather than weeks. That value is real and it is narrow.
• Three separate layers do the work an SBOM is usually credited with: build provenance and attestation prove an artifact came from the source it claims, signing and verification prove it was not swapped afterward, and admission policy is the only layer that actually refuses a build that fails either test.
• Without an enforcing admission gate, every layer above it is documentation. The most common maturity failure is a program that generates attestations nobody verifies at deploy time.
• Reachability analysis is the answer to alert fatigue. Vendor research consistently finds that only a small minority of flagged vulnerabilities sit in code paths an application can actually execute, and triaging by reachability is what makes the backlog finite.
• The regulatory pull is real and dated. US federal procurement already requires attestation, the EU Cyber Resilience Act places SBOM and vulnerability handling obligations on manufacturers with reporting duties starting in 2026 and full application in 2027, and FDA premarket submissions for medical devices already require one.

What an SBOM Actually Is

A software bill of materials is a structured, machine-readable inventory of the components inside a piece of software, including transitive dependencies, with enough identifying metadata to match each component against a vulnerability database. The analogy to an ingredients label is accurate and slightly misleading. An ingredients label is regulated, standardized, and printed on the product by the manufacturer who knows what went in. An SBOM is generated by tooling that infers contents from build artifacts, and the quality of that inference varies enormously by ecosystem.

Two formats matter, and the choice between them is close to arbitrary for most organizations.

SPDX originated at the Linux Foundation with a licensing-compliance heritage and is standardized as ISO/IEC 5962. It is the format most often specified in government contexts and is strong where license obligations are the concern.

CycloneDX originated in OWASP with a security heritage, is standardized through ECMA, and carries richer support for security-specific use cases including vulnerability data and, more recently, machine learning components.

Both are widely supported, converters exist in both directions, and tooling generally emits either. The format question consumes more meeting time than it deserves. The consequential decisions are when the SBOM is generated and how complete it is.

Build-time beats scan-time

An SBOM generated at build time, by the build system that resolved the dependency graph, records what was actually included. An SBOM generated afterward by scanning a container image infers contents from package manager metadata and file signatures, and it misses things: statically linked libraries, vendored source copied into the repository, dependencies installed by a script rather than a manifest. The gap is not marginal. Vendored and statically linked code is exactly where old vulnerable versions hide, because no package manager is tracking them.

The practical implication is that SBOM generation belongs in the pipeline next to the build, not in a separate scanning stage bolted on later. Organizations that already treat their delivery pipeline as defined, reviewable configuration, in the way described in infrastructure as code, find this a small addition. Organizations whose builds happen in ways nobody can fully describe find it a project, and that difficulty is itself the finding.

The Question an SBOM Genuinely Answers

In December 2021, a critical remote code execution vulnerability in Log4j, a logging library embedded in an enormous share of Java software, sent essentially every organization on earth into the same scramble: are we affected, and where. Most could not answer quickly. The library was often a transitive dependency four levels down, bundled inside vendor products, or vendored into an internal service years earlier by an engineer who had since left. Weeks of manual investigation followed, and many organizations never reached full confidence.

That is the question an SBOM answers, and it answers it well. With build-time SBOMs for every artifact, stored in a queryable system, the answer to "which of our services contain this component at this version range" is a database query returning results in minutes. The value is not theoretical and it repeats several times a year.

Two conditions have to hold for that value to be realized, and both are commonly missing. The SBOMs must be queryable in aggregate rather than sitting as files attached to individual artifacts, which means a repository with an index rather than a storage bucket. And the inventory must map to what is running in production, not merely to what was built, which requires the deployment linkage that a well-maintained service catalog provides. An SBOM for an artifact that may or may not be deployed anywhere answers a less useful question.

The Three Questions It Cannot Answer

Is this dependency malicious?

An SBOM lists what is present. It carries no signal about intent. The clearest illustration is the xz utils backdoor discovered in 2024, in which a maintainer with years of legitimate contribution history inserted a backdoor into the compression library's release tarballs. The compromised versions were legitimate releases from the legitimate project, published through normal channels. Every SBOM generated from software including them would have listed a normal entry with a normal version number, and every vulnerability scanner would have reported nothing until a CVE was assigned days later.

Detecting that class requires behavioral analysis of package contents, maintainer and provenance signals, and install-time monitoring. It is a different discipline with different tooling, and an inventory contributes nothing to it.

Was this artifact built from the source it claims?

An SBOM describes contents. It says nothing about origin. If a build system is compromised and injects code during compilation, as happened in the SolarWinds Orion compromise, the resulting SBOM is an accurate inventory of a malicious artifact. The source repository is clean, the SBOM is correct, and the shipped binary contains something nobody wrote. This is the gap that build provenance exists to fill.

Is the vulnerable code path reachable?

An SBOM plus a vulnerability database produces a list of CVEs present. It does not indicate which of them matter. A vulnerability in a function the application never calls, in a code path that requires a configuration the application does not use, is on the list at the same severity as one sitting in the request-handling path. This is the mechanism behind alert fatigue, and it is why security backlogs grow without bound.

The Four Layers, and Which One Does the Work

The table contains the central point of this piece. Layers one through three produce evidence. Only layer four acts on it. A program with excellent SBOMs, complete provenance attestations, and signed artifacts, but no admission gate, has built a filing cabinet. The moment a deploy path exists that does not verify, the entire chain above it is advisory.

Build provenance and SLSA

SLSA, the framework for Supply-chain Levels for Software Artifacts published through the OpenSSF, is best understood as a ladder of claims about how an artifact was built. Its build track runs from provenance merely existing, through provenance generated by a hosted build platform rather than by the developer's own machine, up to a hardened build service where the provenance is resistant to tampering by the people who can modify the build definition. in-toto provides the attestation format underneath.

The executive translation is that provenance turns "this came from our repository" from an assertion into a verifiable claim, signed by the build system, checkable by anyone. It is the layer that would have made the SolarWinds pattern detectable.

Signing, and why the objection expired

Artifact signing is old technology whose adoption was historically blocked by key management. Sigstore changed that with keyless signing: a short-lived certificate is issued against an existing workload or developer identity, the signature is recorded in a public transparency log, and no organization has to operate a signing key infrastructure. That removed the principal reason teams gave for not signing.

Admission policy is the whole program

The verification gate belongs at deployment, enforced by the cluster or platform, refusing artifacts whose signature is missing, whose provenance does not match the expected source repository and build system, or whose SBOM is absent. The policy should be an explicit allow rather than a block list, which is the same default-deny reasoning that governs zero trust architecture applied to artifacts instead of network traffic.

The predictable objection is that enforcement will break deployments. It will, immediately, and that is the value. Every deployment it breaks is a path that was shipping unverified software. Running the gate in audit mode first, publishing the list of what would have been refused, and setting a date for enforcement is how this lands without a revolt.

Reachability Is the Answer to Alert Fatigue

Most flagged vulnerabilities are in code paths that never execute. Vendor research using function-level reachability analysis consistently reports that only a small fraction of vulnerabilities found in dependencies, often well under a fifth, sit in code the application can actually reach. The rest are present in a linked library and unreachable from any entry point the application exposes.

This changes the economics of vulnerability management. A backlog of several thousand findings is unworkable and gets ignored, which means the genuinely urgent item is ignored along with everything else. The same backlog filtered to reachable findings is a few hundred items, which a team can actually clear, and clearing it produces more risk reduction than gesturing at the larger list.

Two mechanisms are worth distinguishing. Static reachability analysis traces call graphs from application entry points to the vulnerable function and reports whether a path exists. Runtime analysis observes which libraries and functions are actually loaded and executed in production, which is less complete but harder to argue with. VEX, the vulnerability exploitability exchange format promoted by CISA, is the standardized way to publish the resulting judgment so that downstream consumers inherit it rather than re-deriving it.

There is a governance benefit that gets overlooked. An unreachable vulnerability that is nonetheless documented as assessed and deprioritized is a defensible position in an audit. An unreachable vulnerability sitting untouched in a backlog looks identical to negligence. The analysis converts an accumulating liability into a recorded decision, which is the same transformation that makes technical debt measurement useful to a board.

The Regulatory Pull, Stated Plainly

Three regimes are driving procurement requirements, and their timelines are specific enough to plan against.

United States federal procurement. Executive Order 14028 directed the federal government to require SBOMs from software suppliers, with minimum elements defined by NTIA. Subsequent OMB guidance converted this into a self-attestation requirement for producers selling to federal agencies, using a standard form. The practical effect for vendors is that the attestation is a condition of sale, and it is signed by a company officer.

European Union Cyber Resilience Act. The CRA entered into force in December 2024 and applies to products with digital elements placed on the EU market. It obliges manufacturers to identify and document components including through an SBOM covering at minimum top-level dependencies, to handle vulnerabilities across the support period, and to report actively exploited vulnerabilities and severe incidents to authorities. Reporting obligations begin in September 2026 and the bulk of obligations apply from December 2027. The scope is the part executives most often misread: this is product regulation with market access consequences, not a security guideline, and it reaches manufacturers outside the EU who place products on the EU market.

FDA medical devices. Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023, requires cyber device premarket submissions to include an SBOM covering commercial, open source, and off-the-shelf components, along with a plan for monitoring and addressing vulnerabilities. This one is already in force and enforced through the submission process.

The common thread is that SBOM has moved from best practice to market access condition in three separate jurisdictions, which changes who owns the decision. It is now a commercial question rather than an engineering preference.

The AI Wrinkle That Is Genuinely New

Machine learning systems introduce dependency types with no mature inventory story. A deployed model depends on weights whose training data is often undisclosed, on a base model that may itself be a fine-tune of something else, on datasets with licensing terms that may be unclear or contested, and on prompt assets and tool definitions that behave like code while living outside every code-tracking system.

CycloneDX has moved first here, adding support for machine learning components so that models and datasets can appear as first-class entries. The specification exists; the ecosystem that would populate and consume those entries mostly does not. Very few model providers publish anything resembling a complete bill of materials for a model, and for many models the information required to produce one is not available at any price.

There is a second effect that is less discussed and more immediate. AI coding assistants raise the rate at which dependencies enter a codebase, because suggesting an import is frictionless and reviewing it is not. Some of those suggestions name packages that do not exist, a failure mode attackers have already learned to exploit by registering the hallucinated names. The control is the same registry allowlisting and provenance checking described above, now applied to a stream of dependency introductions moving faster than human review was sized for.

A Build Order Worth Having

The order matters. Reachability before provenance, because a team drowning in findings will not have the capacity to build anything else. Provenance before enforcement, because there is nothing to enforce against otherwise. And supplier requirements last, because an organization that cannot produce this evidence for its own software has no standing to demand it from vendors, and will not know how to evaluate what arrives.

Frequently Asked Questions

What does an SBOM actually prove?

It proves what components are inside an artifact, including transitive dependencies, in a machine-readable form that can be matched against vulnerability databases. That makes it the tool for answering whether an organization is affected by a newly disclosed vulnerability and where, in hours instead of weeks. It proves nothing about whether those components are malicious, whether the artifact was built from the source it claims, or whether the vulnerable code is ever executed.

What is the difference between SPDX and CycloneDX?

SPDX came from the Linux Foundation with a license compliance heritage and is standardized as ISO/IEC 5962, making it the format most frequently named in government contexts. CycloneDX came from OWASP with a security focus, is standardized through ECMA, and carries richer support for vulnerability data and machine learning components. Both are widely supported and converters exist in both directions, so the choice rarely justifies the debate it generates.

What is SLSA provenance and why does it matter?

SLSA is a framework of graded requirements for how software is built, and provenance is the signed statement the build system emits describing which source produced which artifact using which build process. It matters because an SBOM cannot detect a compromised build system: if code is injected during compilation, the SBOM accurately inventories a malicious artifact. Provenance turns the claim that an artifact came from a given repository into something a deployment gate can independently verify.

Does the EU Cyber Resilience Act require an SBOM?

Yes. The CRA requires manufacturers of products with digital elements to identify and document components, including through an SBOM covering at minimum the top-level dependencies, alongside vulnerability handling obligations across the support period. Reporting duties for actively exploited vulnerabilities begin in September 2026 and the main obligations apply from December 2027. It reaches manufacturers outside the EU who place products on the EU market, and non-compliance affects market access rather than producing only a fine.

Why do most SBOM programs fail to improve security?

Because they stop at generation. An SBOM stored as a file attached to an artifact, never aggregated into a queryable index and never linked to what is deployed, cannot answer the one question it is good at. More fundamentally, the evidence layers above inventory only matter if something refuses to deploy when they fail, and most programs never build that admission gate. Without enforcement, the entire chain is documentation.

The Bottom Line

The useful diagnostic question for any supply chain program is not whether it produces SBOMs. It is what happens when an unsigned artifact with no provenance reaches the deployment path. In most organizations the answer is that it deploys, because the gate does not exist, and every layer of evidence above it is a report nobody reads.

That reframes the investment. Generating SBOMs is cheap and nearly solved, and it will not move the risk needle on its own. The expensive and valuable work is aggregating that inventory into something queryable and linked to production, filtering findings by reachability so the backlog becomes finite, emitting provenance from builds, and then, at the point where it becomes uncomfortable, turning on a gate that refuses what fails. The discomfort is the signal that the program has started working. Everything before that point is preparation, and a program that never reaches it has bought an ingredients label for a kitchen with an unlocked back door.