Key takeaways
- Supply chain integrity framework with four levels of build provenance assurance — from basic (unsigned provenance) to hermetic (isolated, reproducible builds with signed provenance)
- Answers "where did this artifact come from?" with cryptographically verifiable build provenance attestations
- Google-originated, OpenSSF-maintained. GitHub Actions generators produce SLSA provenance automatically. Used by Go, npm, and major package registries
- Complements Sigstore (signing) and Scorecard (scoring) — together they form the trust infrastructure stack
FAQ
What is SLSA?
A supply chain integrity framework (pronounced "salsa") that defines four levels of build provenance assurance. Provides cryptographically verifiable attestations proving where software artifacts came from and how they were built. Google-originated, OpenSSF-maintained.
Overview
SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a supply chain integrity framework that defines four levels of build provenance assurance. It answers the fundamental trust question: "Where did this artifact come from, and can I verify it?"
Four levels from L1 (basic provenance documentation) to L4 (hermetic, reproducible builds with signed, non-falsifiable provenance). GitHub Actions generators produce SLSA provenance automatically.
Complements Sigstore (signing) and OpenSSF Scorecard (scoring) in the trust infrastructure stack.
Competitive Position
Strengths: Industry standard framework. Google + OpenSSF backing. GitHub Actions integration. Complementary to Sigstore/Scorecard.
Weaknesses: Framework, not a tool — requires tooling to implement. Higher levels (L3-L4) are difficult to achieve. Adoption outside large orgs is slow.
Research by Ry Walker Research