What does 'build provenance' actually mean in a supply-chain security context, and how would you start implementing it (e.g. via SLSA) for an existing CI pipeline?

Build provenance is a verifiable, tamper-resistant record of exactly how an artifact was built — what source commit, what build system, what build steps — so a consumer can cryptographically verify an artifact actually came from your claimed build process rather than being tampered with or substituted somewhere in the pipeline. SLSA (Supply-chain Levels for Software Artifacts) is a framework defining incremental levels of this guarantee; you'd typically start by generating and signing provenance attestations in CI (many CI providers now support this natively) before working toward SLSA's stricter build-isolation requirements at higher levels.

The problem build provenance solves is that a compromised or tampered build pipeline can produce a malicious artifact that's otherwise indistinguishable from a legitimate one — a compromised CI runner, a malicious build script injected mid-pipeline, or an artifact swapped after build but before deployment would all look identical to the correct artifact without some independent, verifiable record of exactly how it was actually produced.

• Provenance metadata must be generated automatically as part of the build, not manually after the fact (a manually-created record can't be trusted the same way).
• The provenance record must be cryptographically signed so it can't be forged or silently altered after generation.
• Consumers (your own deployment pipeline, or external customers) must be able to verify the provenance before trusting/using the artifact.

Start with provenance generation, even before full SLSA compliance: most modern CI platforms (GitHub Actions, GitLab CI) now have native or near-native support for generating signed build provenance attestations, capturing what source commit, workflow, and build steps produced a given artifact — this is a realistic, incremental starting point rather than needing to redesign your entire build system upfront.

Sign the provenance using a trusted signing mechanism: tools like Sigstore/cosign provide a practical way to sign both artifacts and their provenance without managing long-lived signing keys yourself (using short-lived, identity-based signing tied to your CI identity) — this is what makes the provenance actually trustworthy rather than just self-asserted metadata.

Verify provenance at consumption points: generating provenance only has value if something actually checks it — add verification steps in your deployment pipeline (refusing to deploy an artifact whose provenance doesn't verify) and, if you distribute artifacts externally, document how customers can verify provenance themselves.

Progress toward higher SLSA levels incrementally: SLSA's levels build from basic provenance generation (roughly Level 1-2) toward stronger build-isolation guarantees (Level 3+, where the build process itself is hardened against tampering even by someone with some access to the build system) — treat this as a maturity roadmap, not a single implementation project, since jumping straight to the highest level typically requires build infrastructure changes beyond just adding an attestation step.

Provenance generation and verification add real steps to your pipeline (generation time, signing infrastructure, verification gates that can block a deploy if something's wrong) — a meaningful investment for the security guarantee gained. Higher SLSA levels require genuine build-isolation changes (ephemeral, hardened build environments) that can mean real migration work if your current build infrastructure wasn't designed with that isolation in mind.

• Build provenance is a verifiable record of how an artifact was actually built, protecting against tampering anywhere in the build/deploy chain, not just against vulnerable dependencies.
• Start with signed provenance generation (often natively supported by modern CI platforms) rather than trying to hit the highest SLSA level immediately.
• Provenance only has security value if something actually verifies it before trusting the artifact — generation without verification is incomplete.
• Treat SLSA levels as an incremental maturity roadmap; higher levels require real build-isolation infrastructure work, not just an added attestation step.

• SLSA Framework
• Sigstore
• GitHub Docs: Using artifact attestations