SLSA stands for Supply-chain Levels for Software Artifacts, and it is pronounced "salsa." It began at Google, drawing on that company's internal build-integrity practices, and is now maintained as an open project under the Open Source Security Foundation. Its purpose is narrow and useful: to give a common vocabulary for how much you can trust the way a piece of software was built, and to define concrete, checkable levels that raise that trust step by step.
The framework is worth understanding because most of the supply-chain defenses people already know sit somewhere else in the pipeline. A software bill of materials tells you what went into a build. Code signing tells you who released the result. Reproducible builds let you check that source produces the expected binary. SLSA addresses a gap those leave open: whether the build process itself can be trusted, and whether there is tamper-evident evidence of how the artifact was actually produced.
Provenance is the core idea
The central concept in SLSA is provenance. Provenance is a signed statement, generated by the build system, that records how an artifact came to exist: what source commit it was built from, what build steps ran, what builder produced it, and what the resulting artifact's cryptographic hash is. If you have trustworthy provenance, you can check that the binary in front of you really did come from the commit you audited, built by the system you expected, and was not swapped or altered afterward.
SLSA expresses provenance using the in-toto attestation format, a standard way of writing signed claims about software artifacts. The attestation is the evidence. The SLSA levels are graded largely by how hard that evidence is to forge, which in turn depends on how the build platform is run.
Signing answers "who published this." Provenance answers "how was this actually built, from what, and by whom." An attacker who compromises the build step can still get a valid signature. Provenance is designed to make that tampering visible.
The build track levels
The current version of SLSA organizes its requirements into a Build track with three ascending levels, on top of a Level 0 that simply means no guarantees. Each level adds a requirement that closes off a category of attack. The higher you go, the less an attacker who controls part of the pipeline can lie about what happened.
| Level | What it requires | What it defends against |
|---|---|---|
| L0 | No requirements | Nothing. The baseline. |
| L1 | Provenance exists and is distributed with the artifact | Mistakes and casual tampering; makes build metadata available to verify |
| L2 | Provenance is signed and generated by a hosted build platform | Forged provenance from a developer's own machine; ties evidence to a build service |
| L3 | The build runs on a hardened platform with strong isolation, so provenance is non-forgeable even by the build's own steps | A compromised build script tampering with its own provenance or reaching other builds |
The jump that matters most is from Level 1 to Level 3. At Level 1, provenance exists, but a developer could in principle generate a plausible-looking attestation by hand. At Level 2, the provenance is signed by a hosted build service, so it is tied to a system rather than an individual laptop. At Level 3, the build platform is hardened so that the steps running inside a build cannot forge their own provenance or interfere with other builds. That isolation is what would have made the SolarWinds-style injection detectable, because the tampering would have contradicted the recorded provenance.
What SLSA deliberately does not cover
SLSA is careful about its own scope, and that honesty is part of what makes it usable. The current Build track does not, by itself, guarantee that the source code is free of malicious commits, that dependencies are safe, or that the developers are trustworthy. A project can reach a high build level and still ship a vulnerability that was in the source all along. Work on a separate source track, covering how code enters the repository, has been developing alongside the build track but is a distinct concern.
This is why SLSA is best understood as one instrument in a set rather than a single score for supply-chain safety. It pairs naturally with dependency scanning, with a bill of materials for what went in, and with reproducible builds so a third party can independently confirm the binary matches the source. Together those give you both a record of how something was built and a way to check that record against reality.
A signature tells you the door was locked by someone with a key. Provenance tells you what happened inside the room. After SolarWinds, the industry decided it needed both.
Why this matters beyond big companies
It is tempting to file supply-chain frameworks under enterprise compliance and move on. That misses the point for anyone who depends on software they did not write, which is everyone. The open-source libraries inside your messaging app, your password manager, and your operating system all pass through build pipelines, and a compromise at that layer reaches every user of the finished product regardless of how careful they personally are. Supply-chain attacks against privacy software are attractive precisely because they bypass the user entirely.
For a security-focused project, the practical takeaway is to build in a way that produces verifiable provenance and to publish enough that an outsider can check the chain from source to artifact. That is the same instinct behind open source and reproducible builds: reduce how much anyone has to take on faith. Haven's own move toward open, auditable builds is part of the same effort. The more of the path from source to running code that can be independently verified, the less any single point in the pipeline has to be trusted blindly.