Build Integrity and Provenance
Understand how isolated builds, controlled inputs, and provenance evidence make artifact trust more inspectable without promising certainty.
In this lesson, you will learn to:
- Explain what build provenance can demonstrate, identify the controls needed to protect build inputs and outputs, and select an incremental integrity improvement.
Build Integrity and Provenance
This lesson introduces build integrity, provenance, and SLSA-style incremental assurance as practical tools for improving release trust.
Provenance records how an artifact was produced
Provenance is information about an artifact’s origin and build. A useful provenance record can describe the artifact, the source revision or inputs, the build process, the builder, and related metadata. It gives a consumer evidence to evaluate whether an artifact came from an expected process rather than merely appearing under a familiar name.
Provenance has value only when its generation and verification are trustworthy. If an attacker can alter the build definition, inject a dependency, control the builder, or forge the provenance record, the evidence may confirm a compromised process. Protecting build integrity therefore involves source controls, isolated or hardened builders, constrained build identities, explicit inputs, secured artifact storage, and verification by the deployment or consuming environment.
SLSA provides an incrementally adoptable specification for discussing these assurances. Its build track distinguishes the existence of provenance from stronger guarantees about a hosted build service and a hardened builder. Use such levels as a vocabulary for the requirements actually met, not as a marketing label. A higher level can offer stronger protection but may also require changes to platform architecture and operating practice.
Start with a release you can trace. Can you identify the source revision, build definition, inputs, builder, artifact digest, and publishing event? If not, improve visibility before making broad claims about integrity. If yes, decide which remaining threat—tampering after build, compromised build runner, or unreviewed source change—matters most.
Verify the artifact you deploy, not just the job that passed
A successful pipeline run is useful evidence, but it is not the same as verifying that the artifact being deployed is the one the approved build produced. Artifacts can be overwritten, mis-tagged, copied between environments, or substituted through a registry or deployment configuration change. Use immutable identifiers such as digests where practical and make deployment systems verify the expected artifact and its required evidence.
Separate build, publish, and deploy authority. A developer who submits code may legitimately trigger a test build, but not necessarily publish a production artifact or change the production deployment target. A deployment identity may need to retrieve one approved artifact, not list or alter every package in the registry. These boundaries reduce blast radius and make high-impact actions easier to explain.
Protect the build definition like source code. A minor workflow change can add a dependency, expose a secret, change a publishing destination, or skip a check. Require review appropriate to impact, pin or verify external build actions, restrict untrusted contributions from accessing secrets, and record the identity and configuration that ran a release build.
Test verification failure. What happens if a deployment references an artifact that lacks required provenance or does not match the approved digest? A secure policy that is only monitored may be useful during rollout, but a high-impact release path should eventually have an explicit decision about when a mismatch must block deployment.
Resources
- SLSA v1.2 specification — Use the current SLSA specification to understand incremental build-track guarantees, provenance, and the requirements behind supply-chain assurance claims.