Provenance: Proving Where Your Software Came From
SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework developed by Google and now maintained by the OpenSSF (Open Source Security Foundation). It defines a graduated set of requirements for ensuring that software artifacts are built from the source you think they are, using the build process you think was used, and have not been tampered with in transit.
The core concept is provenance — a signed, verifiable record that answers: "Who built this artifact? From what source commit? Using what build system? When?"
SLSA Levels
SLSA defines four levels of increasing rigor:
| Level | Key Requirement | What It Prevents |
|---|---|---|
| SLSA 1 | Build process is documented and produces provenance | Accidental errors, basic accountability |
| SLSA 2 | Provenance is signed by the build service | Tampering after the build |
| SLSA 3 | Build runs in an isolated, ephemeral environment; source is verified | Compromised build machine, insider threats |
| SLSA 4 | Two-person review of all changes; hermetic, reproducible builds | Sophisticated insider attacks, SolarWinds-class attacks |
Most organizations target SLSA 2 or 3 as a practical goal. SLSA 4 requires significant investment and is typically reserved for critical infrastructure software.
Practical Implementation with GitHub Actions and Sigstore
The Sigstore project (cosign, fulcio, rekor) provides the cryptographic infrastructure for signing artifacts and storing transparency logs. GitHub Actions has native SLSA provenance generation for releases: a release workflow builds the artifact, computes its digest, and hands that digest to a dedicated reusable provenance-generator workflow, which produces a signed attestation at SLSA Level 3, published alongside the release artifact. Consumers can then verify that provenance against the artifact before trusting it, rather than trusting the artifact on the strength of "it came from the right URL" alone.
SLSA is increasingly appearing in senior DevOps and Platform Engineering interviews. The key insight to communicate is that SLSA is not a tool — it is a framework that defines what properties a build system must have. The SolarWinds attack would have been prevented at SLSA 3 because the build environment would have been isolated and ephemeral, making it impossible for attackers to persist malicious code in the build system between runs.