What is SLSA? Supply-chain Levels for Software Artifacts Explained
The 2020 SolarWinds breach changed how the industry thinks about software security. Attackers compromised the build system of a trusted vendor, slipped malicious code into a routine software update, and used that update as a delivery mechanism into thousands of downstream organizations, including federal agencies. The lesson was uncomfortable. Even when the source code is clean and the published binary is signed, the path between them, the build pipeline itself, can be subverted. Supply-chain attacks moved from a theoretical concern to a board-level priority almost overnight. SLSA, pronounced "salsa," is the framework that emerged as a serious answer to that problem. Originated at Google and now stewarded by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, SLSA gives organizations a structured way to harden their build pipelines and prove the integrity of the software they ship.
What SLSA Stands For
SLSA is short for Supply-chain Levels for Software Artifacts. It is a security framework, a checklist, and a common vocabulary all at once. Its purpose is to describe, in measurable terms, the integrity of the process that produced a piece of software. Rather than asking "is this binary safe to run," SLSA asks "can you prove how this binary was built, and can the build itself be trusted."
The framework originated inside Google as a generalization of an internal system called Binary Authorization for Borg, which Google had used for years to enforce that production workloads only ran from approved, verified builds. Google open-sourced the underlying ideas in 2021, and SLSA is now an OpenSSF project under the Linux Foundation. The current published version is SLSA v1.0, which restructured the original four-level model into focused tracks, with the Build track being the most mature.
SLSA is not a tool. It does not scan code, generate reports, or block deployments by itself. It is a specification that describes what good looks like, leaving the implementation to build platforms, signing tools, and verification systems that the community is steadily building around it.
The Four SLSA Levels
SLSA defines a progression of levels, each adding stronger guarantees about how an artifact was built and how trustworthy the resulting provenance is. The original SLSA framework described four levels, and that mental model remains a useful way to discuss maturity even after the v1.0 restructuring focused the formal requirements on Build levels L1 through L3 with L4 still under development.
| Level | Requirement | What It Proves |
|---|---|---|
| L1 | Build process is documented and produces provenance describing how the artifact was built. | Basic transparency. Consumers can see how a release was produced, even if they cannot yet verify it. |
| L2 | Builds run on a hosted build platform that generates and signs provenance automatically. | Provenance is authentic and tamper-evident, proving the artifact came from the claimed source via the claimed builder. |
| L3 | Hardened build platform with isolated, ephemeral build environments and non-falsifiable provenance. | An attacker who compromises one build cannot tamper with provenance for other builds or inject untracked steps. |
| L4 | Two-party reviewed changes and hermetic, reproducible builds. Currently a planned future level. | Strongest assurance that no single insider can introduce malicious code and that the build is fully deterministic. |
The levels are cumulative. Each higher level inherits the requirements of every level below it. Most organizations starting a SLSA program target Level 2 first, because it represents the largest single jump in actual security value relative to effort.
SLSA Provenance: What It Actually Is
The central artifact produced by a SLSA-conformant build is the provenance document. Provenance is a signed JSON file that records, in a structured and machine-readable format, exactly how a particular software artifact came into existence. It answers questions like: which builder produced this binary, from which source commit, using which build instructions, and with which input dependencies.
SLSA provenance follows the in-toto attestation framework, which gives every claim about an artifact a consistent envelope, signature, and statement structure. A typical provenance attestation includes:
- Subject: The artifact being described, identified by its cryptographic digest so the attestation cannot be silently swapped to point at something else.
- Builder: The identity of the build system that produced the artifact, such as a specific GitHub Actions workflow runner or a hosted CI service.
- Build type and invocation: The recipe used to produce the build, including parameters, environment, and the entry point that was executed.
- Materials or resolved dependencies: The inputs the build consumed, such as the source repository commit hash and any pinned dependency artifacts.
- Byproducts and metadata: Optional information about the build, including timing, the build platform's own version, and any additional artifacts produced.
Because the provenance is signed by the builder, downstream consumers can verify that the document genuinely came from that builder and was not modified, then make a policy decision based on its contents.
SLSA vs SBOM vs SSDF
SLSA is often discussed alongside Software Bill of Materials (SBOM) standards and the NIST Secure Software Development Framework (SSDF). The three are sometimes confused or used interchangeably, but they answer different questions and serve different audiences.
| Framework | Scope | Output | Primary Audience |
|---|---|---|---|
| SLSA | Integrity of the build process and the artifacts it produces. | Signed provenance attestations describing how the artifact was built. | Build platform owners, release engineers, security teams verifying upstream artifacts. |
| SBOM | Composition of an artifact: which components and dependencies it contains. | A structured document, typically in SPDX or CycloneDX format, listing components and versions. | Vulnerability management, license compliance, procurement and risk teams. |
| SSDF | Practices and processes a development organization should follow. | A set of recommended practices, tasks, and outcomes published by NIST as SP 800-218. | Engineering leadership, governance teams, organizations responding to federal procurement requirements. |
The three frameworks are complementary rather than competing. An SBOM tells a consumer what is inside a piece of software. SLSA provenance tells the consumer how that software was assembled. SSDF describes the broader development practices that produce trustworthy software in the first place. A mature program uses all three: SSDF to shape engineering practice, SLSA to harden the pipeline, and SBOMs to enable downstream vulnerability tracking.
How to Achieve SLSA Level 2
SLSA Level 2 is the most pragmatic starting point for the majority of organizations. It does not require redesigning the build system or rewriting tooling. The key shift is moving builds onto a hosted platform that automatically generates signed provenance, and then storing those attestations alongside the artifacts. A practical checklist looks like this:
- Use a hosted build platform: GitHub Actions, GitLab CI, Google Cloud Build, and similar managed services give the build a stable, observable identity that local laptop builds cannot.
- Generate provenance automatically: Tools like the SLSA GitHub generator produce in-toto attestations as part of the build, signed by the platform's identity.
- Store and publish attestations: Attestations should travel with the artifact, whether stored in a registry that supports OCI referrers, in a transparency log such as Sigstore's Rekor, or as release assets.
- Pin source revisions: Builds should reference specific commit hashes rather than mutable branch names so the provenance accurately describes the inputs.
- Verify on consumption: Downstream consumers, including internal teams pulling artifacts from a registry, should validate the provenance signature and the source identity before trusting the artifact.
Where SCA Fits Into a SLSA Program
SLSA hardens the process that produces an artifact. It does not, by itself, tell anyone whether the components inside that artifact are safe. A perfectly built artifact can still depend on a vulnerable open-source library three transitive hops down the dependency tree. That is where Software Composition Analysis becomes essential, and why SLSA assumes consumers already have visibility into their dependency graphs.
Provenance describes resolved materials, but a provenance document on its own does not flag a Log4Shell-class vulnerability inside one of those materials. SCA tooling reads the resolved dependency tree, including transitive dependencies, and matches each component against vulnerability databases. The combination is powerful: SLSA proves the artifact came from the claimed sources through a hardened pipeline, and SCA proves that those sources do not contain known vulnerabilities. GraphNode SCA provides exactly this dependency visibility, generating the SBOMs and continuous vulnerability tracking that a SLSA program needs as input.
The risk picture only fully resolves when both layers are in place. As covered in Transitive Dependencies and the Hidden Attack Surface, the majority of vulnerable code in a modern application enters through dependencies the development team never directly imported. SLSA can prove the build was honest. SCA can prove the inputs were safe. Together, they give a verifiable chain of custody from upstream maintainer to running production binary.
A Maturity Journey, Not a Checkbox
SLSA is best understood as a maturity model rather than a pass-or-fail certification. Each level closes a specific class of attacker capability, and most organizations reach Level 2 well before they reach Level 3 or beyond. That is appropriate. Level 2, achieved consistently across an entire portfolio, prevents whole categories of supply-chain attacks that would otherwise succeed against an undefended pipeline. Level 3 is meaningful for organizations whose binaries are themselves widely consumed, because it raises the cost of pipeline compromise dramatically. Wherever an organization lands, the value of SLSA comes from honest measurement and steady improvement, not from a single audit milestone.