SLSA

Definition

SLSA (Supply chain Levels for Software Artifacts) is a security framework that defines a set of incremental levels an organization can achieve to harden its software build and release process against tampering. Rather than a single tool, it is a checklist-style standard describing requirements such as build provenance, source integrity, and isolated build environments, letting a project or company measure and communicate how resistant its supply chain is to specific classes of attack.

Overview

SLSA emerged from the recognition that software supply chain compromises, such as a build system being tampered with to inject malicious code into an otherwise legitimate release, were happening in increasingly high-profile ways, and that the industry lacked a shared vocabulary or checklist for describing how hardened a given build pipeline actually was. SLSA was created to give organizations a common framework for that conversation, structured as a small number of increasing levels rather than a single pass/fail bar. Mechanically, SLSA defines requirements across areas like the build process, provenance generation, and source control, organized into levels: lower levels require basic practices such as a scripted, repeatable build and provenance metadata describing how an artifact was produced, while higher levels require a build to run on a hardened, isolated build service that ensures build steps cannot be tampered with by the code being built and that provenance is generated non-forgeably. Provenance in SLSA typically takes the form of a signed, machine-readable attestation, often produced using tooling like in-toto, describing the source, build steps, and materials used to produce an artifact, so a consumer can verify how it was built without trusting an unverifiable claim. SLSA does not itself sign or scan anything; it is a specification that other tools implement. Sigstore's Cosign is commonly used to sign the artifacts and attestations SLSA calls for, in-toto's attestation format is commonly used to structure the provenance metadata, and vulnerability scanners like Grype address a separate concern, code-level vulnerabilities, that SLSA's build-integrity focus does not cover. Because of this, SLSA is best understood as the goalposts, with in-toto and Sigstore among the tools used to reach them. In practice, open-source projects and companies use SLSA to assess their current build pipeline's maturity, identify gaps such as missing provenance generation or an unhardened build environment, and prioritize which improvements move them to the next level. Package ecosystems and consumers increasingly reference SLSA levels when deciding how much to trust a given dependency's build process, particularly after high-profile supply chain incidents raised awareness of the risk. A common misunderstanding is treating a SLSA level as a certification of code quality or vulnerability-free status; SLSA addresses build and provenance integrity specifically, not whether the code itself is well written or secure at the source level. Reaching the higher levels also requires real infrastructure investment, such as migrating to a hardened, ephemeral build service, which is a nontrivial lift for projects using traditional, long-lived build servers.

Specification

• Defines incremental levels rather than a single pass/fail security bar
• Requires scripted, repeatable builds at its foundational level
• Higher levels require hardened, isolated, non-tamperable build environments
• Specifies signed, machine-readable provenance describing how an artifact was built
• Framework-agnostic, implemented using tools like in-toto and Sigstore
• Helps consumers assess the build-integrity risk of a dependency
• Governed under the Open Source Security Foundation umbrella
• Distinguishes build and provenance integrity from source-level code quality

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps