Provenance: The Recipe, Not Just the Ingredients
Knowing what is in the software (SBOM) and who signed it (Sigstore) is necessary but not sufficient. You also need to know how it was built.
Provenance is a signed attestation — a document — that describes the build process that produced an artifact. A provenance attestation might say: "This container image with digest sha256:abc123 was built by GitHub Actions workflow release.yml, triggered by commit def456 on branch main, using the command docker build -t myapp ., at 14:32 UTC on 2024-01-15."
This matters because a developer could build an image on their compromised laptop, sign it with valid credentials, and push it. The signature would verify correctly. But the provenance would reveal it wasn't built by the trusted CI system — it was built on an uncontrolled machine.
SLSA: A Framework for Progressive Trust
SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework developed by Google and now governed by the OpenSSF. It defines four levels of supply chain security maturity, each building on the previous:
| Level | Key Requirement | What It Prevents |
|---|---|---|
| SLSA 0 | No guarantees | — |
| SLSA 1 | Build process is scripted; basic provenance generated | Ad-hoc, undocumented builds |
| SLSA 2 | Builds run on a hosted CI service; provenance is signed by the build service | Developer tampering after source checkout |
| SLSA 3 | Build platform is hardened; provenance is non-falsifiable even by platform admins | Compromised build infrastructure |
SLSA 4 (the original highest level) has been restructured in SLSA v1.0 into a track-based system, but the core principle remains: each level makes it progressively harder for an attacker to inject malicious code without detection.
Generating SLSA Provenance with GitHub Actions
The SLSA community maintains reusable GitHub Actions workflows that automatically generate and sign provenance for your artifacts. Your own build job builds and pushes the image and captures its digest, then hands that image reference and digest off to a separate, SLSA-community-maintained reusable workflow — the slsa-framework/slsa-github-generator — as a downstream job.
That reusable workflow runs in an isolated, ephemeral environment that your own workflow file cannot influence, generates a provenance attestation, signs it with Sigstore (Cosign), and attaches it to your image in the registry — all automatically. The isolation is the point: because the provenance-generating job runs independently of the calling workflow, even a developer with write access to your workflow file cannot forge or tamper with the resulting provenance.
Verifying Provenance
Verifying SLSA provenance with cosign verify-attestation follows the same identity-matching pattern as verifying a signature — you specify the expected provenance type, the identity of the trusted generator workflow, and its OIDC issuer, then decode the resulting payload to inspect the provenance predicate — the structured document describing exactly how the image was built.