Cite the current SLSA version, which the project site lists as v1.2, and name the track and level, for example "Build L2". The v1.0 pages are marked retired. Version 1.2 added a Source track, so a bare claim of "SLSA compliant" is ambiguous. Always say which version, track and level you mean.
What SLSA is, in one line
SLSA, short for Supply chain Levels for Software Artifacts, is a specification for how trustworthy a software artifact's build and source history are. Each track has levels. Each level builds on the one below it.
What changed between versions
The v1.2 landing page says it is "Version 1.2" of the specification and that it includes a Build track, a Source track and cross track information on threats and verified properties. The "what is new" page for v1.2 says the main change from v1.1 is the addition of the Source track, an updated threat model that covers what the Source track mitigates, and a reorganized structure that accommodates multiple tracks.
I could not confirm from the pages I fetched what changed between v1.0 and v1.1, so check the project's own release notes before you describe that difference.
| Version | Tracks | Status per the pages I read |
|---|---|---|
| v1.0 | Build | Pages are marked retired |
| v1.1 | Build | Not confirmed here |
| v1.2 | Build and Source | Listed as current |
Why the version matters in a claim
The Build track in the v1.0 text defines L0 through L3. L1 means provenance exists, L2 adds a hosted build platform and signed provenance, and L3 adds a hardened platform that isolates runs and protects signing secrets. A buyer reading "we meet SLSA Level 3" cannot tell whether you mean a Build level, a Source level, or something older.
The Source track levels in v1.2 are separate: L1 is version controlled source, L2 is history and provenance, L3 is continuous technical controls, and L4 is two party review. A claim of "Level 3" could mean two quite different things.
How to word it
Use a sentence that carries all four facts:
- The specification version.
- The track.
- The level.
- The scope, meaning which artifact or pipeline.
For example: "The release pipeline for the CLI produces provenance at SLSA v1.2 Build L2." Then be ready to show the provenance file. If you have not verified a level, say "working toward".
Avoid these phrases:
- "SLSA certified". SLSA is a framework of levels and requirements. Do not describe it as a certification.
- "SLSA compliant" with no level.
- A level number with no track name.
Check your old documents
If you wrote policies, questionnaires or trust pages in the v1.0 era, search for "SLSA". Where the text names a level, add the track and version. Where it says "compliant", replace it with the specific claim you can prove. This takes an hour and removes a common source of awkward follow up questions.
For a practical view of choosing a target, see which SLSA build level should you target. For what the levels do and do not prove, read what SLSA proves and what it leaves open.
Safeguard's policies and compliance evidence automation can help you keep the records behind a claim like this. The free scan at gold.safeguard.sh/scan is a quick first look at your dependencies.
Quick check
Is SLSA a certification?
No. It is a specification with tracks and levels. Describe what you meet, not a certificate.
Does Build L2 under v1.0 mean the same as Build L2 under v1.2?
I could not confirm from the pages I read that the Build track text is unchanged, so state the version you assessed against.
Sources
- SLSA v1.2 specification overview
- SLSA v1.2: what is new
- SLSA v1.2 source requirements
- SLSA v1.0 build levels
Last reviewed: 19 October 2026.
