SLSA

Overview

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a supply chain integrity framework that defines verifiable levels of provenance assurance. It answers the fundamental trust question: "Where did this artifact come from, and can I verify it?"

The current specification is v1.2, approved in November 2025. The Build track defines levels L0–L3, from no provenance (L0) through provenance from a hosted build platform (L2) to hardened, tamper-resistant builds (L3). v1.2's headline change is promoting the Source track from experimental to approved — requirements for source history retention and continuous tamper protection on repositories, with its own verification summary attestations. (The old v0.1 "four levels L1–L4" model, including hermetic builds at L4, was retired with v1.0 in 2023; hermetic/reproducible requirements are deferred to a future Build L4.)

Google-originated, now maintained by a vendor-neutral steering committee under the OpenSSF, with the spec licensed under the Community Specification License 1.0. Contributing organizations include Google, Chainguard, Citi, CNCF, Datadog, Intel, Kusari, the Linux Foundation, and Verizon.

Complements Sigstore (signing) and OpenSSF Scorecard (scoring) in the trust infrastructure stack — SLSA provenance is typically signed and logged via Sigstore.

---

What's New (as of June 2026)

• Spec v1.2 approved (November 2025) — Source track graduates from experimental to approved, levels reordered around history and continuous enforcement, and source-level verification summary attestations become first-class. Backwards compatible with v1.1 and v1.0 Build track claims.
• Default-on in the ecosystem — GitHub Artifact Attestations provide SLSA v1.0 Build Level 2 out of the box for any Actions workflow, with Level 3 achievable via reusable workflows; public repos log to the Sigstore Public Good instance. npm trusted publishing (GitHub Actions, GitLab CI/CD) automatically generates and publishes provenance attestations — no extra configuration.
• Tooling shifts — the language-agnostic slsa-github-generator (575 GitHub stars, last pushed March 2026) predates GitHub's native attestations and now overlaps with them; the spec repo itself sits at ~1,900 stars with active weekly commits.
• Boundary-setting after npm worm attacks — a May 2026 SLSA blog post responding to the "Mini Shai-Hulud" npm compromise spells out what SLSA does and does not defend against: provenance proves build integrity, not that the source code is benign.

---

Pricing

Free. SLSA is an open specification (Community Specification License 1.0), not a product — there is nothing to buy from the project itself. Implementation costs live in tooling and platform choices: GitHub's and npm's implementations are bundled into their existing plans, and vendors like Chainguard sell compliance products around the framework.

---

Cautions

• Build L3 is genuinely hard — Chainguard's engineering write-up ("This Shit Is Hard: SLSA L3 and Beyond") details how L3's isolation requirements were "complicated to implement" even for supply-chain specialists; the spec itself warns that work done for lower levels may not carry forward, since reaching a higher level can require migrating build platforms entirely.
• Provenance is not safety — SLSA's own post-incident analysis is blunt: a compliant artifact can still ship malicious code that was honestly built from a compromised source. Treating "SLSA L3 compliant" as "safe" breeds overconfidence.
• Framework, not a tool — you still need a build platform, signing infrastructure, and a verifier; verification at install time remains the weakest, least-adopted link.
• Spec churn — v0.1 levels, v1.0 tracks, and the v1.2 Source track reordering mean older compliance claims and docs don't map cleanly onto current terminology.

---

Competitive Position

Strengths: The industry-standard provenance framework with no real competitor. OpenSSF governance with Google, Chainguard, Intel, Citi backing. Now default-on via GitHub Artifact Attestations and npm trusted publishing — adoption no longer requires opt-in tooling. Source track extends coverage upstream of the build.

Weaknesses: Framework, not a tool — requires platform support to mean anything. Build L3 remains costly to achieve outside hosted platforms that do it for you. Verification-side adoption lags generation. Recent npm attacks showed the limits of what provenance alone prevents.

---

Bottom Line

SLSA won the framing war: "what SLSA level is your build?" is now how the industry talks about build integrity, and the v1.2 Source track extends that language to repositories. The strategic shift since 2025 is that SLSA stopped being something you bolt on and became something platforms emit by default — GitHub at Build L2, npm via trusted publishing. The honest caveat, stated by the project itself, is that provenance proves integrity of the pipeline, not intent of the code.

Recommended for: Any team publishing packages or containers (take the free Build L2 from GitHub/npm); organizations setting procurement or compliance bars for software suppliers.

Not recommended for: Teams expecting a turnkey security product — SLSA is a measuring stick, and L3+ still demands real platform engineering.

Outlook: Build L2 becomes table stakes as registries default it on; the open questions are whether verification catches up with generation, and whether the new Source track gets real platform support the way the Build track did.

---

Research by Ry Walker Research • methodology