SLSA Levels Explained: Build Provenance from Level 1 to 4
Digital Engineering
SLSA is the framework that turns build pipelines from convenient automation into auditable supply chain controls. We walk through what each level actually requires, what it costs to implement, and which level is realistic for most teams within a single quarter of focused work.
By Arjun Raghavan, Security & Systems Lead, BIPI · August 5, 2023 · 9 min read
SLSA, pronounced salsa, is the supply chain integrity framework that came out of Google and is now stewarded by the OpenSSF. Its job is to answer one question. How confident can you be that the binary you are about to deploy came from the source code you think it came from.
The framework defines four levels. Each level adds friction and adds assurance. Most teams should aim for Level 3 within a quarter of starting. Level 4 is a destination, not a starting point.
Level 1: Documented build process
All Level 1 asks is that the build is scripted and that it produces a provenance document describing how the artifact was made. No signing, no isolation guarantees, just a written record. If your build is a Jenkinsfile or a GitHub Actions workflow, you are already most of the way there.
- Build is fully scripted, no manual steps
- Provenance document is generated and stored
- Provenance describes the source, the builder, and the materials
Level 2: Hosted build service, signed provenance
Level 2 requires the build to run on a hosted service, not on a developer laptop, and the provenance to be signed by that service. GitHub Actions, GitLab CI, and Google Cloud Build all qualify as hosted builders. The signature proves the provenance came from the builder, not from someone with write access to the artifact.
This is the realistic minimum bar for any production workload in 2023.
Level 3: Hardened builder, non-falsifiable provenance
Level 3 is where things get interesting. The builder must be hardened so that a malicious build step cannot forge provenance for a different source repo or commit. Ephemeral build environments, isolated workers, and out-of-band provenance generation are all required.
The slsa-github-generator project from the SLSA team gives you Level 3 on GitHub Actions for free, as long as you use the reusable workflows it ships and do not bypass them.
Level 3 is the first level where a compromised build step cannot silently change the provenance to point at a different commit.
Level 4: Two-party review, reproducible builds
Level 4 requires every change to the source to be reviewed by a second party, and the build itself to be reproducible bit-for-bit by an independent verifier. Reproducibility is hard. It means stripping timestamps, sorting file lists, pinning every transitive dependency, and removing every source of nondeterminism from the toolchain.
Bazel, Nix, and Guix make this tractable. Maven, Gradle, and pip make it painful. If you are not already on a reproducible build system, Level 4 is a multi-quarter project.
What we tell clients
- Audit where you are today, most teams are between Level 1 and Level 2
- Move to hosted builders if you are not already there
- Adopt slsa-github-generator or the equivalent for your CI
- Publish provenance attestations to Rekor or an equivalent transparency log
- Verify provenance at deploy time, not just at build time
- Reach Level 3 across all production images before chasing Level 4
The verification gap
Generating provenance is the easy half. The harder half is verifying it at deploy time. A SLSA Level 3 artifact that is deployed without verification is functionally Level 0. Kyverno, Sigstore policy-controller, and Conftest can all run the verify step inside an admission controller. Wire it in before you celebrate the achievement.
Closing
SLSA gives you a vocabulary for talking about build integrity with auditors, customers, and your own engineering organization. Use the vocabulary, pick a target level, and treat the work as a build platform investment rather than a security ticket. The teams that succeed treat their builders as production infrastructure.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.