SLSA (Supply-chain Levels for Software Artifacts)
SLSA is a framework of build and source integrity levels, backed by signed provenance, that makes tampering with a software artifact detectable.
Definition
SLSA is an industry framework that defines increasing levels of supply-chain integrity for source code and build processes, requiring verifiable provenance that records what was built, from which source, by which build system, and how.
Context and scope
Use it when you need to prove that a released artifact came from a specific commit and a trusted build pipeline, not from a laptop or a manually modified release.
Common misconceptions
- SLSA certification guarantees the code is secure; it guarantees build integrity and provenance
- A provenance file is trustworthy just because it exists; it must be signed by a trusted builder
- Level 4 still exists; the current build track defines levels 1 through 3
Anti-patterns
- Generating provenance inside the same job that compiles the code, with no isolation
- Publishing artifacts and provenance from different pipelines
- Treating a SLSA badge as a substitute for vulnerability scanning
Related concepts
Related examples
Authoritative source
Provenance over promises
A build can be reproducible and still untrustworthy if the pipeline that produced it was compromised. SLSA shifts the question from “does this artifact work” to “can I verify how it was produced”. The answer is a signed provenance attestation that binds the artifact digest to a source repository, a commit, and a build system configuration.
How the levels work
Build level 1 means the build is scripted and provenance exists, though it may be incomplete or unsigned. Level 2 requires a hosted build service, signed provenance, and provenance generated by that service rather than the user’s job. Level 3 adds hardening: isolated builds, no user-controlled steps that can alter the output, and non-falsifiable provenance.
Verification happens at consumption time. A deploy pipeline downloads the artifact, fetches the attestation, checks the signature against the trusted builder identity, and compares the artifact digest and source URI with policy. If any link fails, the artifact is rejected.
When to use it
Adopt SLSA for release artifacts, container images, and packages distributed to customers. It is most valuable for open-source projects consumed widely and for organizations whose build systems are attractive targets. Start by generating provenance and verifying it internally before demanding a level from suppliers.
Trade-offs
Higher levels constrain how builds run: no custom signing steps in the job, isolated runners, and stricter identity controls. Provenance adds storage and verification steps to deployment. The framework covers build integrity, not code quality, dependency risk, or runtime security, so it must sit alongside SBOMs and scanning.
Example and misconceptions
A release pipeline downloads a binary and its provenance, verifies that the signing identity is the project’s hosted builder, and confirms the digest matches the artifact and the source commit. A manually uploaded replacement binary fails the digest check and is blocked.
The common misconception is that SLSA proves an artifact is malware-free. It proves the artifact matches a declared build; a malicious commit can still produce valid provenance.
Related concepts: Software Bill of Materials (SBOM), Supply Chain Security, and CI/CD.