Learn the vocabulary of verifying exactly how a software artifact was built.
0 / 5 completed
1 / 5
At standup, a dev mentions attaching a signed, verifiable record of exactly how a software artifact was built, including the source commit and build system used, so a consumer can confirm its origin. What is this record called?
Build provenance, as defined by the SLSA framework, is a signed, verifiable record of exactly how a software artifact was built, including details like the exact source commit and the build system that produced it, letting a consumer cryptographically confirm the artifact's true origin. A manually written changelog entry carries no cryptographic guarantee and could be inaccurate or tampered with. This verifiable provenance record is a core building block for establishing real trust in a software supply chain.
2 / 5
During a design review, the team wants their build process to run in an isolated, ephemeral environment so a compromised prior build can't tamper with a later one. Which capability supports this?
An isolated, ephemeral build environment runs each build in a fresh, temporary environment that's discarded afterward, so a compromised or tampered prior build state can't carry over and affect a later, separate build. Reusing the same persistent build environment across every build risks a contamination or tampering issue from one build silently affecting subsequent ones. This isolation is a key requirement at the higher SLSA levels for establishing genuinely trustworthy build provenance.
3 / 5
In a code review, a dev notices the build pipeline configuration itself is stored in version control and requires the same review process as any other code change, rather than being editable directly on the build server. What does this represent?
Treating build pipeline configuration as reviewed, version-controlled code requires the same review process as any other code change, preventing an unreviewed, undocumented modification to the build process itself. Allowing direct edits on the build server with no review creates an unaudited path for someone to tamper with how artifacts get built. This discipline extends the supply-chain trust boundary to include the build process's own configuration, not just the source code it builds.
4 / 5
An incident report shows a compromised build server injected malicious code into an artifact during the build step, and no provenance record existed to reveal the tampering had occurred. What practice would prevent this?
Generating and verifying signed build provenance for every artifact gives a consumer a way to detect an unexpected or invalid build origin, such as an artifact that doesn't match its claimed source commit or build system. Skipping provenance generation and simply trusting the build server removes the very mechanism that could have revealed the tampering. This verification step is exactly what the SLSA framework's provenance requirement exists to enable, turning an invisible compromise into a detectable one.
5 / 5
During a PR review, a teammate asks why the team generates a signed provenance record for every build instead of just trusting that their existing build pipeline works correctly. What is the reasoning?
Simply trusting that a build pipeline works correctly provides no way for a downstream consumer to independently verify that trust, especially if the pipeline itself were ever compromised. A signed provenance record lets that consumer cryptographically confirm the artifact's real origin rather than relying on unverifiable assumptions. The tradeoff is the added infrastructure needed to generate, sign, and distribute this provenance data alongside every build artifact.