SBOMs Are Not Compliance Documents. They Are Release Evidence

SBOMs should prove what you shipped, what is exposed, and what customers can trust.

SBOM, VEX, and Provenance turn software inventory into defensible release evidence.

The weakest SBOM question is:

Do we have a list of components?

The stronger question is:

Can we prove what we shipped, explain whether a finding is exploitable, defend that answer to a customer, and repeat the process for every release?

That is where SBOMs become useful.

Not as static files. Not as checkbox artifacts. Not as scanner output thrown into a release folder because someone asked for “the SBOM.”

SBOMs matter when they become evidence.

Evidence of what was built. Evidence of what was shipped. Evidence of what is affected. Evidence of what is not affected. Evidence a customer, auditor, security team, or regulator can actually use.

Generating SBOMs gets most of the attention. That is the easy part. The harder part is making them accurate, tied to a specific release, explainable under pressure, and safe to share.

The regulatory pressure is real

The EU Cyber Resilience Act changed the tone of this conversation in Europe.

The CRA entered into force on 10 December 2024. Its reporting obligations apply from 11 September 2026, while the main obligations apply from 11 December 2027.

The legal text defines a software bill of materials as a formal record containing component details and supply-chain relationships for software elements of a product with digital elements. Annex I also requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.

So yes, compliance matters.

But the wrong lesson is:

We need an SBOM because regulation says so.

The better lesson is:

We need evidence because modern software supply chains are too complex to explain from memory.

Customers are asking sharper questions. Security questionnaires are becoming more specific. Product teams are shipping faster. Dependencies are deeper. AI-assisted development is increasing both code volume and dependency ambiguity.

An SBOM is not the answer to all of that.

It is the first layer of truth.

Public vulnerability data is under pressure

The NVD shift makes this more urgent.

On 15 April 2026, NIST announced a new risk-based enrichment model for the National Vulnerability Database. CVE submissions increased 263% between 2020 and 2025, and submissions in the first three months of 2026 were nearly one-third higher than the same period in 2025. NIST also said it enriched nearly 42,000 CVEs in 2025, 45% more than any previous year, but that still was not enough to keep up.

Going forward, NIST will prioritize enrichment for CVEs in CISA’s Known Exploited Vulnerabilities catalog, software used within the US federal government, and critical software as defined by Executive Order 14028. CVEs outside those criteria will still be listed in the NVD, but they will not be immediately enriched.

Translation for engineering teams:

• You cannot outsource vulnerability context to public databases.
• The public data layer is still essential. But it is not enough.

You need internal product context:

• Did we ship this component?
• Which versions contain it?
• Is it runtime, build-time, test-only, or dead code?
• Is the vulnerable function reachable?
• Is the affected feature enabled?
• Is it exposed to untrusted input?
• Is there a compensating control?
• Which customers are actually affected?

This is where SBOMs need to connect to release governance, vulnerability triage, and customer assurance.

Otherwise, you just produce more data and less clarity.

Generation is the easy part

Most SBOM programs start the same way:

• Run a tool.
• Generate CycloneDX or SPDX.
• Upload the file.
• Declare progress.

That is not wrong. It is just early.

Modern SBOM formats are capable. CycloneDX **1.7** was released in October 2025, introducing capabilities around cryptographic assurance, intellectual-property visibility, distribution control, citations, and provenance transparency.

The format is not the bottleneck. The bottleneck is release fidelity.

Does the SBOM describe the actual artifact customers received? Does it include vendored and commercial dependencies? Does it map to the binary, installer, container image, or package that was shipped? Was it generated from the release build or from a nearby repository state? Can it be regenerated? Can it survive a customer escalation or incident review?

A scanner can tell you what it saw. An evidence system tells you what you shipped.

Those are different maturity levels.

Real products are messy

SBOM demos are usually clean.

A small container image. A package lockfile. A modern dependency graph. A scanner output that looks authoritative.

Real products are not always like that.

The gap widens for desktop software, native compiled codebases, embedded tooling, SDK-heavy commercial products, and long-lived enterprise software.

There may be:

• statically linked libraries
• manually copied DLLs
• vendored source trees
• commercial SDKs
• legacy components still present in the package
• build-time conditionals
• platform-specific dependency paths
• optional features
• old libraries present but not reachable in supported workflows
• dependencies that do not map cleanly to package URLs or CPEs

A simple scenario:

A commercial SDK ships a vulnerable parser statically linked into a binary. The package-manager SBOM misses it. A binary scan detects it. Engineering then confirms the affected parser path is not reachable in supported product workflows.

What is the customer-facing answer?

Not “the scanner found a CVE.” Not “we have an SBOM.” Not “it is fine, trust us.”

The answer needs evidence:

Component present: yes
Affected version shipped: yes
Reachable vulnerable code path: no
Reason: vulnerable parser path is not invoked by supported workflows
Status: not affected
Evidence: binary scan, engineering analysis, test notes, release version mapping

That is the practical gap between inventory and product security.

Presence is inventory. Exposure is analysis. Risk is context.

Keep that distinction clean, or the SBOM program becomes a false-positive factory.

SBOM without VEX becomes alert spam

An SBOM tells you what may exist.

It does not automatically tell you whether a vulnerability is exploitable in your product.

That is the role of VEX: Vulnerability Exploitability eXchange.

OpenSSF’s 2026 VEX discussion describes VEX adoption as gathering momentum because of regulation, customer expectations, and the need to reduce vulnerability noise.

OpenVEX requires a status for each VEX statement. A not_affected status must be backed by either a machine-readable justification or a written impact explanation, which is exactly the type of context scanners cannot infer by themselves.

Without that layer, raw SBOM matching creates noise:

Component present
- CVE matched
- scanner flags it
- customer escalates
- engineering investigates
- finding is not reachable
- same question returns next quarter

A mature loop looks different:

Component present
+ CVE matched
+ product impact assessed
+ VEX status recorded
+ evidence attached
+ customer response becomes repeatable

The goal is not only to know what exists. The goal is to explain what matters.

AI-assisted development raises the stakes

The AI angle is not theoretical anymore.

AI coding assistants and agents can hallucinate plausible but non-existent package names. Trend Micro describes this as **slopsquatting**: a supply-chain threat where malicious actors register AI-hallucinated package names and wait for developers or agents to install them. Their research notes that advanced coding agents and MCP-backed validation can reduce, but not eliminate, the risk of phantom dependencies.

This creates a new problem for DevSecOps:

• Generated code may look correct.
• The dependency name may look plausible.
• An attacker may register the hallucinated name in the gap between AI suggestion and developer installation.
• The package may exist by the time the build runs.
• The developer may not know whether the dependency came from a human decision, an AI suggestion, or an agentic install step.

In that world, “review the code” is necessary but insufficient.

You need verifiable evidence of what entered the build:

• approved package sources
• lockfile enforcement
• provenance
• dependency allowlists
• package age and reputation checks
• signed artifacts
• reproducible release metadata
• SBOMs tied to the final artifact, not just the repository

AI does not remove the need for SBOMs. It makes weak SBOMs more obvious.

The only durable defense against generated uncertainty is verifiable release evidence.

Provenance is the missing connective tissue

This is where SLSA matters.

SLSA describes provenance as verifiable information about software artifacts that explains where, when, and how something was produced. Its provenance model also connects produced artifacts back to the builder, recipe, materials, parameters, and build environment.

In plain terms, provenance helps answer:

• Which builder produced this artifact?
• From which source revision?
• With which build definition?
• With which externally controlled parameters?
• At what time?
• For which output artifact digest?

That is the bridge between:

We scanned a repository.

and:

We can prove what produced this release.

SBOM tells you what is inside. Provenance tells you how it came into existence. VEX tells you whether a known vulnerability matters in this product.

Separately, each is useful. Together, they become a product-security evidence chain.

A maturity model that actually works

A serious SBOM program has layers.

Not one scanner. Not one file. Not one dashboard.

A usable model looks like this:

1. Package-manager SBOM: Generated from lockfiles, package managers, build manifests.
2. Vendored / third-party dependency manifest: Covers commercial SDKs, copied binaries, manually managed libraries, platform SDKs, and dependencies outside normal package managers.
3. Binary / artifact-level scan: Validates what actually landed in the packaged artifact.
4. Build provenance: Proves where, when, how, and from which source the artifact was built.
5. VEX / exploitability layer: Records affected, not affected, fixed, or under investigation status.
6. Release attachment: Signed, versioned, attached to the shipped release, and retained.
7. Customer evidence package: Shareable externally without exposing unnecessary internal detail.

The goal is not perfection. The goal is defensible traceability.

When a zero-day lands, you should not need five meetings to discover whether the vulnerable component is inside your product.

You should already know where to look.

Be careful what you share

Another common mistake: assuming the same SBOM should be shared with every audience.

Internally, you want full fidelity.

Externally, you want accuracy, usefulness, and controlled disclosure.

A full internal SBOM may reveal:

• proprietary component names
• architecture hints
• commercial SDK usage
• legacy dependencies
• vulnerable components before remediation
• internal build structure
• supplier relationships

The CRA reflects this sensitivity: market surveillance authorities may request relevant SBOMs where necessary to verify compliance, and dependency information may be shared onward in anonymized and aggregated form in certain contexts.

So the better model is tiered:

• Internal SBOM: Full fidelity. Used by engineering, security, PSIRT, and release governance.
• Customer evidence package: Accurate and useful, but curated for disclosure.
• Regulator / authority SBOM: Provided where legally required, through the right process.
• VEX / advisory layer: Explains actual product impact, not just component presence.

Good transparency is not reckless transparency. It is controlled, accurate, and repeatable.

The real output is not sbom.json

The real output of an SBOM program is the ability to answer hard questions quickly:

• Did we ship this component?
• Which versions contain it?
• Is the vulnerable code reachable?
• Which customers are affected?
• Was the issue fixed?
• Which release fixed it?
• Can we prove that?
• Can we give the customer a clear answer without inventing language every time?

That is the difference between a document and a capability.

A document sits somewhere. A capability changes how the organization responds.

What good looks like

A mature SBOM program supports five workflows.

1. Release approval

Before shipping, the release has an attached SBOM, provenance, license view, known vulnerability status, and unresolved risk summary.

2. Vulnerability triage

When a CVE drops, the team can map it to affected products and versions without manually searching repositories, build machines, and old release folders.

3. Customer assurance

Security questionnaire answers become evidence-backed instead of improvised.

4. Incident response

During a zero-day, the team can identify exposure quickly and communicate with confidence.

5. Product governance

Security, engineering, legal, compliance, and customer-facing teams work from the same source of truth.

This is when SBOM stops being paperwork and starts becoming operating discipline.

The maturity test

If your SBOM cannot help answer a customer or incident question, it is not mature yet.

Not useless. Just immature.

The same applies to dashboards.

If a dashboard produces thousands of findings but cannot distinguish “present” from “exploitable,” it is not a risk system. It is a notification system.

Security teams do not need more notifications. They need evidence.

What SBOMs are actually for

SBOMs are often introduced as ingredient lists for software.

That metaphor is useful, but it is too small.

The future of SBOM is not inventory. The future of SBOM is evidence-driven product security.

Because when a customer asks whether they are exposed, they do not want a dependency tree.

They want confidence.

When a regulator asks what you shipped, they do not want a scanner screenshot.

They want traceability.

When a zero-day hits a library buried somewhere in your product, you do not want a panic meeting.

You want a release evidence trail.

A weak SBOM program produces files. A mature SBOM program produces answers.