Build Provenance

Source code review, dependency pinning and vulnerability scanning all address the inputs to a build. None of them addresses the build itself. If the build system is compromised, the source is clean, every scan passes, and the artefact is malicious — and there is no signal anywhere in the pipeline that would reveal it.

Build provenance closes that gap: the build system emits a signed attestation stating what it built, from which commit, with which inputs, on which builder, at what time — and the deployment path refuses artefacts without a valid attestation matching an expected policy.

Why it matters

The build system is the highest-value target in most software organisations and typically the least protected. It has access to source, to credentials, to signing keys and to the deployment path, and it is often treated as internal tooling rather than as production infrastructure.

Provenance converts "we trust our build system" from an assumption into a verifiable claim. The verification at deploy time is the part that matters — an attestation that is generated and never checked provides exactly nothing, and this is the most common way the practice is implemented ineffectively.

It also provides the answer to the question every organisation asks during a supply-chain incident: "where did this binary come from, and is the version running in production the one we think it is?" Without provenance that is an investigation; with it, it is a query.

Implementation patterns

• Generate the attestation inside the build, covering source repository and commit, build definition, builder identity, resolved dependency digests, and the output artefact digest.
• Sign with a key the build definition cannot access — ideally a workload identity and a transparency-log backed signing service, so that a compromised build script cannot forge attestations for arbitrary content.
• Verify at admission, in the deployment path, as a hard gate: correct signer, expected source repository, expected builder, artefact digest matching the thing being deployed.
• Policy expressed as what is required, not what is forbidden: production accepts artefacts from these repositories built by these builders, and nothing else.
• Ephemeral, isolated build environments with no persistent state between builds and no standing production credentials — provenance about an untrustworthy builder is a record of an untrustworthy build.
• No secrets available to builds triggered from forks, which is a routine and severe exposure.
• Transparency logging, so attestations are publicly verifiable and cannot be quietly replaced.
• Reproducible builds where achievable, which upgrades the claim from "the builder says so" to "independently confirmable."

Industry example

The SLSA framework, developed following widely-publicised build-system compromises, formalises exactly this progression — from "there is a build service" through "provenance is generated" to "provenance is verified" and "builds are hermetic and reproducible." Major CI providers now emit signed provenance natively, and container registries and admission controllers support verifying it before a workload is allowed to run.

The driving incidents are instructive: compromises where the delivered artefact differed from the reviewed source, which no amount of code review, scanning or dependency pinning could have detected — because the attack was located in the one place none of those controls examine.

Failure scenarios

• Attestations generated and never verified, which is the common implementation and provides no protection.
• Signing keys accessible to the build script, so a compromised build forges its own provenance.
• Verification that checks only the signature, not the source repository or builder identity, so any legitimately-signed artefact passes.
• Builders with persistent state, allowing one build to influence the next.
• Fork-triggered builds with access to secrets.
• Provenance covering the artefact and not its dependencies, leaving the input path unverified.
• An emergency bypass used routinely, which removes the gate in practice while retaining it in documentation.
• No policy on what is expected, so verification succeeds against anything with a valid signature.

Trade-offs

Provenance adds a hard gate to the deployment path, and a hard gate fails: a key rotation, a builder migration or a policy error blocks legitimate deployments, sometimes urgently. That requires a break-glass path, and the break-glass path is the weakness — used casually, it nullifies the control.

It also requires the build system to be treated as production infrastructure, with the operational investment that implies, and it constrains build flexibility: hermetic, reproducible builds are meaningfully harder to construct than convenient ones.

The trade is deployment friction and build-system rigour in exchange for detecting the one class of attack that every input-focused control misses. For an organisation whose artefacts are widely distributed, or which is a plausible target for a supply-chain attack, the trade is clearly right. For a small internal application, dependency pinning and a locked-down builder deliver most of the value at a fraction of the cost.

Interview question

"Our source is reviewed, our dependencies are pinned and our scans are clean, and the binary in production is still malicious. Explain how, then tell me the minimum set of controls that would have caught it — and which of them we would have to verify at deploy time rather than at build time."