What is SLSA?

What problem does SLSA solve?

You can review every line of source code and still ship something else, because what users run is the output of a build. If the build is compromised, as it was at SolarWinds, clean source produces a poisoned release. SLSA focuses on that gap: can anyone verify that this artifact came from this source, through this process?

SLSA levels

SLSA organizes its requirements into tracks. The current version, 1.2, has a Build track and a Source track. The Build track has four levels.

Level	Name	What it requires	What it gives you
Build L0	No guarantees	Nothing	L0 is the absence of SLSA
Build L1	Provenance exists	A consistent build process, and provenance generated by the build platform and given to consumers	Helps prevent mistakes, but is trivial to bypass or forge
Build L2	Hosted build platform	Builds run on a hosted platform that generates and signs the provenance, and consumers verify it	Forging provenance now takes an explicit attack
Build L3	Hardened builds	Runs are isolated from each other, and the signing secret is out of reach of user-defined build steps	Forging provenance requires exploiting a vulnerability, beyond most adversaries

Levels are not a grade you must maximize. Each one protects against specific threats, so pick the level that fits your risk. Open source maintainers with a hosted CI service can often get to L2 without much work.

What is provenance?

Provenance is a record of how an artifact was made. In SLSA it says which platform built it, from which source, by which process and with which top-level inputs. Provenance at L2 and above is signed, so a consumer can check that it came from the build platform and has not been altered.

Think of an SBOM as the ingredients, and provenance as where and how the dish was cooked. They answer different questions and work well together: an SBOM lists what is inside, while provenance says where the artifact came from.

How to adopt SLSA

1. Build in CI, the same way every time. Stop releasing from laptops. This is most of the work of reaching L1.
2. Generate provenance. On GitHub, artifact attestations produce signed provenance. See how attestations work with SBOMs in GitHub Actions.
3. Verify it somewhere that matters. Signed provenance nobody checks protects nobody. Add verification to your deployment step or admission controller.
4. Harden the build. Isolate runs and keep signing keys away from build steps. See runner security compared.
5. Ask your dependencies. Prefer packages that publish provenance, as registries such as npm now support.

What SLSA does not cover

• Vulnerabilities. A perfectly built artifact can contain a flaw. SLSA says nothing about whether the code is safe.
• Malicious source. If an attacker commits to the repository, provenance faithfully records a build of that code. The Source track addresses part of this.
• What the build pulled in. Provenance lists top-level inputs. Nothing in the Build track requires a full list of dependencies, which is what an SBOM is for.
• Trusted insiders. The xz backdoor came through a trusted maintainer, and SLSA alone would not have stopped it.

SLSA and other frameworks

SLSA goes deep on build integrity. The NIST SSDF is much wider: it covers secure development as a whole, including a practice on protecting and archiving releases that SLSA provenance supports. SLSA is a project of the OpenSSF, and many teams use the two together. For the bigger picture, see what is software supply chain security.

Where CRACI fits

CRACI does not produce signed provenance and makes no claim to a SLSA level, so use GitHub artifact attestations or a similar service if you need one. What CRACI adds is what SLSA leaves out: a full record of what each GitHub Actions job pulled in. Each job runs in its own isolated virtual machine, every package it fetches goes into an SBOM, and an egress policy blocks connections the build does not need. See build-time SBOM generation.

SLSA: frequently asked questions

What does SLSA stand for?

Supply-chain Levels for Software Artifacts. It is pronounced "salsa".

What are the SLSA levels?

The Build track has four: L0, no guarantees; L1, provenance exists; L2, a hosted build platform that signs provenance; and L3, hardened builds with isolated runs and protected signing secrets. Version 1.2 also adds a Source track.

What is SLSA provenance?

A record of how an artifact was built: which platform, from which source, by which process and with which top-level inputs. At Build L2 and above it is signed, so consumers can verify it.

What is the difference between SLSA and an SBOM?

An SBOM lists what is inside a piece of software. SLSA provenance describes how and where it was built. You generally want both.

Is SLSA mandatory?

No. It is a voluntary framework from the OpenSSF community. Some customers and organizations may ask for a level, but it is not a law.

Which SLSA level should I aim for?

Start with Build L1 by building in CI and generating provenance, then move to L2 on a hosted platform, which many teams can reach quickly. L3 suits releases that many others depend on or that carry high risk.