Home / Knowledge hub / SLSA
Knowledge hub
SLSA
A framework of levels for how trustworthy a software build and its output are.
What it means
SLSA stands for Supply-chain Levels for Software Artifacts, and is pronounced salsa. It is a framework, started by Google and now run as an open-source project, that describes how much you can trust the way a piece of software was built.
Version 1.0 defines a build track with levels from 1 to 3. Level 1 asks for provenance to exist. Level 2 asks for a hosted build service that signs it. Level 3 asks for a hardened build that keeps builds from influencing each other.
Why it matters
Many supply-chain incidents work by tampering with the build rather than the source. SLSA gives you a way to say how well your pipeline resists that, and a way for customers to ask the same question in the same words.
It turns a vague statement, our builds are secure, into a checkable one: the artifact has provenance showing which source and which builder produced it, and a consumer can verify it.
How it shows up
In practice you start by moving builds to a hosted pipeline, generating provenance for each artifact, and signing it. Consumers then verify the provenance before they deploy or install. Tooling exists for GitHub Actions and other CI systems.
Common mistakes are claiming a level without checking, generating provenance but never verifying it, and building on laptops. Treat levels as a ladder, not a pass or fail. A move from nothing to level 1 already shows where an artifact came from. It sits beside secure development practices, not instead of them.
Questions people ask
SLSA, answered
How do you say SLSA?
Salsa. It stands for Supply-chain Levels for Software Artifacts.
Does SLSA mean our software has no vulnerabilities?
No. It is about the integrity of the build and where an artifact came from, not whether the code is free of flaws.
What are the levels?
In version 1.0 of the build track there are levels 1 to 3, rising from basic provenance to a hardened, isolated build.
Do we need level 3?
Not necessarily. Start with provenance, then raise the level where the risk and your customers' asks justify the work.
Is SLSA a certification?
No. It is a specification and a way to describe your build. Claims can be checked by anyone with the provenance.
Sources
Where this comes from
Related
Terms that sit next to this one
Build provenance
A signed record of where, when and how a piece of software was built.
Software supply chain security
Protecting the code, tools and people that go into building your software.
Reproducible builds
Builds that produce identical output every time, so tampering shows up.
Build pipeline compromise
An attacker altering your build system so every release carries their code.
Code signing
Signing software so users and systems can check who released it and that it is intact.
Can you prove how it was built?
SLSA covers the build. We cover the application you ship, and report only the flaws we exploited. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.