TL;DR
- SLSA is a ladder: higher levels mean more trustworthy build outputs.
- The core primitive is provenance: “this artifact came from this source, built by this workflow, with these dependencies.”
- Start with repeatable builds + CI hardening + signed attestations; don’t jump straight to maximalism.
What it is
SLSA (pronounced “salsa”) is a framework/maturity model that defines requirements for:
- source integrity
- build integrity
- provenance generation and verification
Key ideas
- Provenance beats vibes: you want machine-verifiable metadata.
- Build systems are attack surfaces: lock down runners, permissions, and dependencies.
- Verification is the endgame: storing provenance is not enough—you need policies that reject untrusted artifacts.
Recommended actions
- Now:
- Move builds to CI (not laptops).
- Enable branch protections + required reviews for release branches.
- Soon:
- Produce signed provenance/attestations for releases.
- Pin dependencies and lockfiles; monitor for tampering.
- Later:
- Enforce verification gates in deployment (reject artifacts without valid provenance).
Notes / caveats
- SLSA doesn’t magically fix supply-chain risk; it gives you a way to measure and enforce build trust.
Links
- Primary: slsa.dev