Build Provenance & SBOM
Is the artifact you are about to deploy structurally the one your pipeline built? A software bill of materials plus build provenance attestation (SLSA-style) answers: these sources, these dependencies, this builder, this hash. A structural sensor aimed at the moment of deployment, where the artifact leaves the world you control.
In practice
A reading is two artifacts: the SBOM, and the attestation tying it to the artifact you are about to deploy.
artifact: payments-api@sha256:9f1c2b...
builder: https://ci.internal/builders/release (SLSA level 3)
build: run 8841, commit a41d2e9, 2026-08-19T14:02Z
signature: verified, sigstore keyless
components:
log4j-core 2.14.1 pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1
jackson-databind 2.15.2 pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.2
Cross-referenced against the vulnerability feed, the same reading says:
| Component | Version | Finding | Severity | Verdict |
|---|---|---|---|---|
| log4j-core | 2.14.1 | CVE-2021-44228, remote code execution | critical | block deploy |
| jackson-databind | 2.15.2 | no known CVEs | none | clear |
Reading it well:
- Verify the signature before reading the contents. An SBOM you cannot tie to the builder is a claim, not an attestation. The hash comparison is the whole sensor; everything else is commentary.
- Read versions, not names. Two minor versions can be the difference between clear and critical, and name-only matching misses it.
- Treat “not in the SBOM” as a finding. A component present in the artifact but absent from the manifest means the SBOM was generated from the wrong place, usually the source tree instead of the build.
Response playbook
When the sensor fires:
- Block the deploy on any mismatch. Unverified signature, hash mismatch, or missing attestation all mean the artifact does not ship. Do not deploy first and reconcile later; the artifact leaves the world you control at deploy time.
- Block on critical vulnerability findings. A critical CVE in a shipped component is a stop-ship condition. Confirm whether the component is reachable in your build; if it is dead weight, upgrade it anyway, because the next reader of the SBOM will not know.
- Rebuild from the attested source, not from the cached artifact. A mismatch usually means the build ran somewhere else, or the cache is stale. Re-run the pipeline and compare hashes again.
- Escalate signature failures, not just dependency failures. A vulnerable dependency is a fix; a bad or missing signature is a possible supply-chain event. Notify security before retrying.
- Record the attestation hash at deploy time. When a CVE ships next quarter, you need to answer which deployments carry it, from the SBOM, not from memory.
What it cannot detect
Malice inside the sources themselves, or a compromised builder that signs its own output faithfully. Provenance tells you the artifact is the one the pipeline produced; whether the pipeline was honest is a question for static security analysis and dependency auditing.
It also cannot see vendored code. An SBOM lists what the build
resolved — manifests, lockfiles, package metadata. A dependency that
was pasted into the source tree, or unzipped into third_party/ and
committed, was never resolved. There is no manifest line to generate a
component from, so none is generated, and to the tool it is
indistinguishable from code your team wrote. It ships anyway, carrying
whatever CVEs it had on the day it was copied, and no vulnerability
feed will ever match it.
This is worse than the “not in the SBOM is a finding” habit above can handle. That habit assumes something in the artifact disagrees with the manifest; vendored source compiles into the same binary as first-party code and disagrees with nothing. Binary composition analysis can sometimes fingerprint a copied library, but that is a separate and heuristic sensor. A clean SBOM is not evidence that a vendored dependency is absent — only that nobody declared one.
Supply chain security is a deeper topic than this catalog covers. Build provenance and SBOMs are one sensor in the structural family — they verify the artifact matches what the pipeline built — but the broader practice of supply chain security (dependency vulnerabilities, artifact signing trust roots, runtime attestation, policy enforcement) deserves its own resources. See SLSA and Sigstore for dedicated treatment.
Related sensors
References
Publications
- Reproducible Builds: Increasing the Integrity of Software Supply Chains —
- License Incompatibilities in Software Ecosystems —