SLSA

How it works

SLSA (Supply-chain Levels for Software Artifacts) is a framework for describing and verifying how a software artifact was built. Its central artifact is a provenance attestation: a signed statement, in the in-toto format, recording the source repository and commit, the build platform, the entrypoint, and the build parameters. SLSA v1.0 defines Build levels 0 through 3. L1 requires provenance to exist and be available, L2 requires it to be signed by a hosted build platform, and L3 requires the platform to prevent a build from forging its own provenance through isolation and unreachable signing keys.

When it matters

It matters for anyone shipping containers or packages to others, and the generation half is nearly free on hosted CI: GitHub Actions artifact attestations and the SLSA generator reusable workflows produce signed provenance from a few lines of YAML. The expensive half is verification, which has to run at consumption time with a policy that checks the attestation contents, not merely that a signature is valid. See Verified Builds with SLSA and Sigstore.

Common misconceptions

• "Level 3 is the goal for everyone." L1 to L2 on hosted CI is close to free and captures most of the value. L3 on self-hosted infrastructure is a genuine engineering program.
• "Provenance replaces an SBOM." Provenance records how the artifact was assembled. An SBOM inventories what is inside it. Neither substitutes for the other.
• "Signing is supply chain security." An attacker who compromises the pipeline gets a valid signature from your legitimate workflow identity. Provenance plus a verifying policy is what makes that visible.