An SBOM Is Not Build Provenance

“We generate an SBOM, so the software supply chain is covered.”

No. Not before you paste that into a procurement response.

An SBOM is not build provenance.

An SBOM says which components are reported in an artifact.

Build provenance says how that artifact was made.

Which build platform ran.

Which process ran.

Which top-level inputs it used.

Build isolation says whether a malicious, or merely contaminated, build run could alter that answer.

Three separate claims.

They need separate evidence.

This should not be difficult.

Nobody looks at an ingredients label and concludes that the factory’s doors were locked while the product was made.

Yet put the ingredients into JSON, call it a Software Bill of Materials, and suddenly inventory becomes a complete theory of build integrity.

It doesn’t.

SPDX and CycloneDX are useful precisely because they make component inventory machine-readable.

The NTIA describes the minimum SBOM material in three categories: data fields, automation support, and practices and processes.

Good.

Generate it, retain it, use it.

But a list of components can’t testify about your process that assembled them.

A grocery receipt isn’t an alibi.

1. “But the SBOM Lists Every Dependency.”

It lists components reported in the artifact.

That is an important claim, and a narrower one than the sentence people keep trying to make it carry.

SPDX, governed by the Linux Foundation, is recognized as ISO/IEC 5962:2021.

CycloneDX, maintained by OWASP and Ecma TC54, has been recognized since 2024 as ECMA-424.

Both can meet the NTIA minimum-element baseline.

SPDX-lite is built to meet the minimum data fields.

CycloneDX adds extensions.

VEX for whether a listed vulnerability is actually reachable, CBOM for cryptographic assets, HBOM for hardware.

All useful.

None of it tells a consumer whether the CI runner that made the release was changed during the build.

An SBOM can say your release contains a particular library at a particular version.

It cannot say the compiler, the source file presented to the compiler, the build script, or the artifact after compilation behaved as your reviewed pipeline definition intended.

It may faithfully inventory a binary that has been faithfully poisoned.

Which is the distinction.

Component inventory operates at the artifact-content layer. Provenance operates at the build-process layer. Isolation operates at the build-environment layer.

The first being useful doesn’t cause the second and third to materialize.

A highly structured list of ingredients is still a list of ingredients.

2. “But the Artifact Is Code-Signed.”

Code signing answers a different question again.

Did the holder of the signing identity produce this artifact?

It does not, by itself, establish that the holder’s build pipeline was uncompromised when it did.

SolarWinds made this painfully concrete.

Attackers had a foothold in the company’s build environment before October 2019.

SUNSPOT, the implant CrowdStrike later identified, carried a compiled timestamp of 20 February 2020.

It watched for MsBuild.exe compiling Orion.

Substituted a backdoored InventoryManager.cs during that compilation.

Then restored the original file after the compile finished.

The important defensive point isn’t the choreography.

It is where your control boundary failed.

The malicious source was not a normal repository change awaiting review.

The legitimate SolarWinds pipeline compiled it, then digitally signed the resulting binary.

The signature was genuine.

The build was not.

SUNBURST shipped in Orion Platform versions 2019.4 through 2020.2.1 HF1, released between March and June 2020.

Roughly 18,000 of 33,000 Orion customers downloaded a trojanized update.

Do not turn that into a count of organizations meaningfully compromised by follow-on activity.

That is a different number, and not one this evidence supports.

Signing an artifact proves something about the signer. It does not prove the signer’s build process was protected from tampering.

A certificate has no small interior detective examining every process that touched the binary.

3. “But the CI Pipeline Is Managed.”

Managed isn’t a security property.

It is usually a billing relationship, an operating model, or a comforting adjective placed next to a logo.

Your secure-development lifecycle gives your pipeline specific jobs.

Microsoft’s SDL separates “secure the engineering environment” from “secure the software supply chain,” and its current practice set contains ten practices.

OWASP SAMM organizes work across five business functions.

Governance, Design, Implementation, Verification, Operations, with fifteen practices in total.

Neither framework says a pipeline is trustworthy because somebody placed it under management.

Your pipeline should run checks on every commit or pull request.

A dependency, secrets, SAST or infrastructure-as-code finding can either block progress or merely report and permit it.

That is gate configuration, and the distinction isn’t cosmetic.

A warn-only dependency scan produces an accurate report while allowing the release straight through.

A gate that blocks critical and high findings while warning on medium and low makes a different claim: known high-severity component risk has to be resolved, or explicitly waived.

That is still not provenance verification.

Dependency gates operate on the known-vulnerability and policy layer.

They ask whether declared components have findings serious enough to stop a release.

Provenance verification operates on the artifact-origin layer.

It asks whether this particular artifact came from the expected build, and whether its supporting evidence checks out.

One detects an unacceptable dependency condition.

The other makes a build claim checkable.

A red dependency scan is not a compromised-build detector.

Just as a clean dependency scan is not a blessing for whatever happened on the runner.

4. “But Source Review Would Catch a Backdoor.”

Source review catches code that reaches source review.

That qualifier is doing the work.

SUNSPOT didn’t need a malicious commit in the Orion repository.

It substituted around one compilation.

Backed up the original source with a .bk extension.

Wrote a replacement through a .tmp file.

Moved it into place for the build.

Then restored the original and deleted the backup after MsBuild.exe finished.

Its MD5 check against expected original content apparently helped avoid breaking the build and attracting attention.

Which is why this incident belongs in a conversation about provenance rather than a sermon about developers missing a suspicious diff.

There may have been no suspicious diff.

The artifact was altered between the repository’s reviewed state and the signed release.

Source review operates at the source-control layer.

It is where your team evaluates a proposed change before it becomes accepted source.

It can’t review a transient input that an altered build environment substitutes after review.

Asking a reviewer to catch code absent from your review is like asking an accountant to notice a page swapped after your audit.

Admirable expectations.

Wrong layer.

The defensive response isn’t to stop reviewing code.

It is to stop treating source review as evidence about an unprotected build process.

5. “But SLSA Sounds Like a Vendor Questionnaire.”

It can certainly be reduced to one.

That is how standards become decorative PDF archaeology.

The build track is more useful read as a sequence of increasingly specific claims.

SLSA Build L0 is no SLSA-relevant guarantee at all.

L1 requires provenance describing the build platform, process and top-level inputs, distributed to consumers.

That record can catch mistakes through comparison with expected provenance, and unsigned L1 provenance is trivial to forge.

L2 adds a dedicated build platform that digitally signs the provenance it emits, and consumers verify that signature.

Now simple omission is no longer enough.

An explicit attack is required.

L3 adds the property SolarWinds needed its build environment to have: strong isolation between build runs, so one run cannot influence another.

It also keeps the provenance-signing key inaccessible to build steps.

That is not paperwork.

That is a boundary between “the build says this happened” and “a process inside the build can make it say whatever it likes.”

The level names are dated evidence.

The framework has revised its levels before.

The durable model is not: collect badges until the procurement spreadsheet becomes calm.

Your model is: identify the claim, identify who can forge it, and put the enforcement boundary where that forgery would occur.

At L1 your record exists.

At L2 it is signed by the dedicated platform.

At L3 the build runs cannot influence one another, and the build steps cannot reach your key attesting to the record.

Those are not interchangeable adjectives.

6. “But Hardening Builds Will Slow Releases.”

Some controls add work.

That is not a discovery.

It is what a control is: an obligation preventing a convenient unsafe transition.

Secure development already has six linked steps.

Design-phase threat modelling.

Secure coding practice.

Dependency management.

CI security gates.

Secrets handling.

Release.

The release proceeds when gated checks pass, or exceptions are explicitly documented.

“We ship continuously” is not an exception to that model.

SAMM’s continuous variant maps checks across steps two through five onto every commit.

It changes cadence and automation, not whether your controls exist.

The alternative to explicit build hardening is not frictionless delivery.

It is accepting that a build runner, a mutable pipeline definition, or an accessible signing key can become a path from reviewed source to trusted customer update without a new review event.

A very efficient release process, in the same way that leaving the warehouse door open is an efficient receiving process.

Treat the tradeoff honestly.

Dependency updates can run daily, weekly, monthly, quarterly, semiannually, yearly, or on a cron schedule.

Faster cadence shrinks the window after public disclosure and creates more review work and more chances for a breaking change.

Slower cadence batches the work and leaves known vulnerabilities live longer.

Gate thresholds shape both risk coverage and release friction the same way.

Those are tunable parameters.

Build provenance and isolation are not a claim that every release must move at the same speed.

They are a claim that speed does not excuse losing track of how the release was made.

7. No, This Does Not Mean SBOMs Are Pointless.

They aren’t.

An SBOM is essential inventory.

A dependency-management programme cannot compare components to vulnerability information when it does not know which components are present.

VEX can add the distinct question of whether a known vulnerability is reachable in context.

Federal procurement made this operationally important too.

Executive Order 14028, signed 12 May 2021, directed the work that put software supply-chain practice and SBOM minimum elements into that process.

But EO 14028 is not a self-executing rule saying every commercial vendor must emit one government format or pay a statutory fine.

Its leverage is federal purchasing power.

NIST’s Secure Software Development Framework, SP 800-218, is the practical translation layer.

Appendix A maps Section 4(e) clauses to SSDF practices and tasks.

That is useful governance evidence.

It is not evidence that a particular artifact was built without runtime tampering.

The overclaim is tempting because an SBOM is visible, exportable and easy to attach to a contract.

Build isolation is less photogenic.

Nobody opens a dashboard and says “wonderful, a build run could not influence another build run.”

You should still require it.

Inventory tells responders what may be affected. Provenance tells deployers what produced the artifact. Isolation protects the truthfulness of the provenance claim.

8. What You Should Actually Do

Generate and retain an SBOM for every release. Use SPDX or CycloneDX according to the consuming system’s needs; both can satisfy the NTIA baseline.

Use the inventory for dependency management, with a severity policy that blocks critical and high findings and warns on medium and low where that is your approved gate design.

Record every approved exception rather than silently waiving it.

Then add the controls the SBOM cannot provide. Issue signed provenance for every artifact.

Verify it before deployment against the expected build platform, process and top-level inputs.

Treat missing or invalid provenance as a release condition to resolve, not an invitation to deploy on the strength of a nice component list.

Isolate build runs so one cannot influence another. Keep the signing key used to attest provenance inaccessible to build steps.

Require pipeline definitions to be reviewed and pinned, because an unreviewed mutable definition is simply another input to the build with a better excuse.

Run the SDL as a system. Threat-model the design.

Apply secure coding practice.

Manage dependencies.

Run the CI gates.

Keep credentials out of source control, build logs and durable CI variable dumps.

Then release only after gated checks pass, or the exception is explicit.

Those controls operate at different layers because the risks do.

Do not ask a dependency scanner whether it trusts the build runner.

Do not ask a code signature whether the compiler saw reviewed source.

Do not ask an SBOM whether the process producing it was altered between source review and signing.

Each control has a job.

Let it do that job.

9. The Actual Model Is Not Complicated.

An SBOM answers: what components are reported in this artifact?

A dependency gate answers: do known component findings meet your policy for release?

Source review answers: was this proposed change accepted before it entered the repository?

Provenance answers: which platform, process and top-level inputs produced this artifact?

Build isolation answers: could one build run or step alter another run, or the evidence it emits?

Code signing answers: did this signing identity sign this artifact?

Use all of them where they apply.

The durable claim is simple.

Knowing an artifact’s declared ingredients and proving how it was built are different security claims.

The particular formats, SLSA levels and procurement rules will change.

The gap between an inventory and a protected build will not.

An SBOM is not build provenance.