SLSA basics for build provenance

SLSA basics for build provenance

TL;DR

SLSA is a framework for answering "was this artifact really built from that source by that builder". Level 1 means provenance exists, level 2 means it is signed by a hosted build service, level 3 means the build is hardened against tampering, and level 4 means hermetic and reproducible. Most teams get to level 3 by using a hosted builder that generates provenance automatically, then verify the attestation before accepting a release.

SLSA basics for build provenance

Use this when

• A customer or auditor asks about your SLSA level
• You are evaluating whether your build pipeline is tamper-evident
• A release policy requires provenance for artifacts
• You want to verify a third-party release before running it

Not for this skill when

• You are building a SLSA-compliant build platform from scratch (that is a major project)
• You need threat modeling for the whole supply chain (broader than SLSA)
• You just want signed artifacts without provenance (use cosign alone)

Steps

1. Check whether you have any provenance at all

test -f [artifact].intoto.jsonl && echo "provenance present" || echo "no provenance attestation found"

Expected: tells you whether you clear even level 1. No attestation file means no provenance, and everything downstream is trust-me.

2. Understand the levels before targeting one

Level 1: provenance exists and describes how the artifact was built. Level 2: the provenance is signed and the build ran on a hosted service, so it is harder to forge. Level 3: hardened builds, non-falsifiable provenance, the level most serious teams target. Level 4: hermetic, reproducible builds with two-person review. Each level builds on the previous one, so do not skip.

3. Generate provenance with a hosted builder

The easiest path is a generator in your existing CI. For GitHub Actions, the SLSA generator workflow produces a level 3 attestation for your build artifacts. Feed it the artifact's hash:

sha256sum [artifact] | awk '{print $1}' | base64 -w0

Expected: a base64-encoded hash string to pass as the subject when invoking the generator workflow. The generator builds (or observes your build), signs the provenance, and uploads the .intoto.jsonl attestation next to your release assets.

4. Verify someone's provenance attestation

slsa-verifier verify-artifact [artifact] --provenance-path [artifact].intoto.jsonl --source-uri github.com/[org]/[repo]

Expected: confirmation that the signature is valid and the artifact was built from the expected source repo by the expected builder. A failure here means do not trust the artifact, regardless of how official the download page looks.

5. Read what the provenance actually claims

python3 -c "import json; p=json.load(open('[artifact].intoto.jsonl')); print(p['predicate']['builder']['id']); print(p['predicate']['materials'][0]['uri'])"

Expected: the builder identity and the source material URI printed. Check the builder is the one you expect and the source commit matches the release tag. Provenance you never read is decoration.

Variant: SLSA for container images

Generate provenance per image digest rather than per tarball, and verify the digest you deploy, not the tag. The same levels apply, the subject is the image digest.

Variant: verifying a third-party release

Download their attestation, run the verifier with their documented source URI and builder. If they publish no attestation, that is your answer about their SLSA level.

Variant: provenance without full SLSA

Sigstore attestations on artifacts give you signed "who built this" claims without the SLSA level machinery. Weaker guarantees, much less work, fine as a stepping stone.

Why this happens

"I downloaded the release from the official page" proves nothing about how those bytes were produced. Build machines get compromised, maintainers' laptops get compromised, and release processes get skipped. Provenance moves the trust from "the download page looked right" to "a known builder turned a known source commit into these exact bytes, and here is the signed receipt".

Edge cases and pitfalls

• Provenance is only as trustworthy as the builder. A self-hosted builder with weak access controls gives you level 1 theater.
• Always verify against the expected source URI. An attacker can generate valid provenance for their own repo.
• Tag-based verification is weaker than digest-based. Tags move, digests do not.
• Level 1 self-attestation (the builder signing its own claim with no hardening) is barely better than nothing. Know which level you actually have.
• Reproducible builds (level 4) are genuinely hard for most stacks. Target level 3 first and be honest about it.

Tool notes: slsa-verifier and the slsa-github-generator are the reference tooling. The framework spec lives at slsa.dev.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstErQZxKbjEKWjN9wFfHDOQ