Start at Build L1 if you have no provenance, aim for L2 when consumers need to check authenticity, and move to L3 when you must resist tampering from inside the build itself. The right level depends on who consumes your artifacts and which build platform you use.
What each level adds
SLSA Build levels are cumulative. From the specification:
| Level | What it means |
|---|---|
| L0 | No guarantees, suited to development or test builds |
| L1 | Provenance exists, though it may be incomplete or unsigned |
| L2 | A hosted build platform generates and signs the provenance |
| L3 | Hardened builds: isolation between runs and protected signing keys |
At L3 the platform keeps the provenance signing secret away from user defined build steps and prevents runs from affecting each other, even within one project.
A decision table
| Your situation | Sensible target |
|---|---|
| Internal tool, a handful of users | L1, then L2 if it is cheap on your platform |
| Library published to a public registry | L2, using the registry or platform attestation feature |
| Software sold to enterprise buyers who review supply chain controls | L2 now, plan L3 |
| Build system used by many tenants or teams | L3 on the platform itself |
| Artifacts that guard high value targets, such as signing or deployment tooling | L3 and verified by policy |
| Builds on a developer laptop | Not eligible above L1, because L2 requires a hosted platform |
How to decide
- Ask who verifies. Provenance nobody checks adds little. The spec says consumers are expected to validate authenticity at L2.
- Ask what you control. A level is a property of the build platform as much as your project. If your hosted platform already supports a level, adopt it.
- Ask what threat you worry about. Tampering after the build is handled early. Forged provenance values and stolen signing keys are L3 concerns, according to the threat model.
- Write the target into policy so verifiers can reject anything lower.
Common mistakes
- Chasing L3 before anyone verifies L1 provenance.
- Treating the level as a badge of security rather than a statement about the build process.
- Forgetting that SLSA Build says little about dependencies or source quality.
For the source side, the specification now includes a separate source track, and dependencies are expected to be handled by applying SLSA recursively.
A staged plan
- Generate provenance for one release artifact and publish it.
- Add signature verification in one consuming pipeline.
- Pick an approved builder list.
- Raise the producer side to L2, then L3 where the platform allows.
Where Safeguard fits
Safeguard's SBOM and dependency scanning plus policy gates address the dependency questions that Build levels leave open. You can try the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the gate in the demo to see how a rule can stop a change from moving on, similar to a policy that rejects artifacts below your target level.
Quick check
Is L3 always better than L2?
It is stronger, but only useful if your platform supports it and someone verifies it. For many teams L2 with real verification beats unverified L3 claims.
Can I reach L2 on a laptop?
No. L2 requires builds on a hosted platform.
Sources
Last reviewed: 19 October 2026.
