DEV Community

StarkMan
StarkMan

Posted on

What a build provenance attestation verifies, and what it leaves open

#supplychain #slsa #intoto #sigstore

What a build provenance attestation verifies, and what it leaves open

Supply chain security has a verification problem. Teams sign artefacts, publish software bills of materials and generate provenance, then treat a signed attestation as evidence that the artefact can be trusted. That inference reaches further than the evidence supports.

What the artefact actually says

A provenance attestation is a signed statement about how an artefact was produced. In the SLSA model, the statement is an in-toto attestation wrapped in a DSSE envelope, and the provenance is the predicate inside it. Two field groups carry the meaning.
The build definition records what the build consumed. It holds a buildType URI that identifies how to interpret the parameters, externalParameters that the caller controlled such as the repository and branch, internalParameters set by the platform, and resolvedDependencies listing the resolved inputs with their hashes.
The run details record who executed it: the builder identity, metadata such as build identifiers and timestamps, and byproducts such as logs.
Verification then checks three things. Is the signature valid against a trusted signer? Does the claimed builder correspond to a builder the verifier accepts? Do the resolved dependencies match the source that the verifier expected?
When a tool such as the SLSA verifier runs against an image, the checks it performs are signature validity, builder identity, source repository and build parameters against policy. GitHub Actions generates the same class of attestation using Sigstore, with a public transparency log for public repositories and an internal instance without a transparency log for private ones.

Where the boundary sits

The most useful sentence about this subject comes from a SLSA community write-up of a real supply chain incident: build platforms can accurately record what ran within their trust boundary, but they cannot vouch for whether what ran produced an uncompromised artefact. The boundary of observability is the boundary of the trust context.
Read that against a pipeline publishing packages through a legitimate CI workflow, with valid signatures and the correct builder, repository and workflow identifiers. Provenance verification passes. The attack still happened, because the build ran attacker-controlled code inside the trust boundary, and the platform truthfully recorded that it did so.
That boundary leaves several things provenance does not establish. It does not prove the source code that was reviewed is the source code that was built, unless the verifier compares the resolved dependency hash against a specific commit. It does not prove the builder is uncompromised. It does not prove that the build steps are the steps the maintainer intended. It does not prove absence of backdoors in dependencies that were resolved legitimately.

What it does change

Given the boundary, provenance is still worth deploying, and the reasons are specific.
It converts an unverifiable download into a policy decision. A verifier can reject an artefact whose builder is not on the accepted list, or whose source repository does not match the repository the consumer pinned. That closes substitution and typosquat-style attacks that rely on nobody checking.
It makes the trust context explicit. The question shifts from whether the artefact is safe to whether the named builder was supposed to produce it, which is a question a policy engine can answer.
It records the moment of compromise for investigations. When an incident is traced back to a package, the attestation narrows the search to the window and the inputs the platform logged.
It composes with keyless signing. Sigstore tooling lets a pipeline sign with an identity derived from the CI platform instead of a long-lived key, which removes the key management problem that has historically made signing programmes fail. Vendor tooling now extends the same pattern to machine images, with keyless signing and transparency logging applied to virtual machine artefacts.

Deployment guidance

Sign what consumers will actually verify. Generating an attestation that nobody validates adds cost and no control, and this is stated plainly in the platform documentation.
Pin the verifier policy rather than the artefact. The useful configuration is an accepted builder list, an expected source repository and a policy for what happens on failure. Enforcement matters more than coverage.
Combine provenance with source review. Provenance tells you which commit was built when the verifier is configured to check it, which is why it pairs naturally with protected branches and review requirements.
Monitor for the trust-boundary case. The residual risk is code that executes inside the build. That is where dependency review, build environment hardening and least-privilege CI credentials belong.

Limitations

Attestation coverage is uneven across ecosystems, and many consumers still install artefacts without verifying anything. Transparency logs are append-only records rather than correctness proofs. SLSA levels describe the strength of the build platform and the provenance it issues. A high level next to an unenforced verifier on the consumer side delivers paperwork instead of assurance.

References

Top comments (0)