A firmware release built by hand on an engineer's laptop with no provenance is SLSA Build L0, meaning no guarantees. Adding generated provenance reaches L1. Moving the build to a hosted platform with signed provenance reaches L2. For a startup, L2 is a realistic first target.
What the levels say
The SLSA specification defines the Build track like this:
| Level | Meaning | What it takes |
|---|---|---|
| L0 | No guarantees, SLSA is absent | Nothing. Fine for dev builds on the same machine |
| L1 | Provenance exists | A consistent build process, plus provenance describing the platform, process and top-level inputs, given to consumers |
| L2 | Hosted build platform | Dedicated infrastructure, not a workstation, with provenance signed and tied to that infrastructure, and verified downstream |
| L3 | Hardened builds | L2 plus isolation between runs and signing secrets kept away from user-defined build steps |
The spec notes that at L1 the provenance helps prevent mistakes but is easy to bypass or forge. At L2, forging it takes an explicit attack, though one that may be easy to carry out. L3 requires exploiting a vulnerability most adversaries cannot achieve.
Why firmware teams start at L0
Firmware toolchains are fussy. Vendors ship installers that expect a specific OS and an IDE. Engineers get a build working on one machine and keep using it. Signing happens by hand. That is a normal starting point, and it means no one can answer "what exactly went into release 1.2.0" with confidence.
A three step climb
- Script the build (toward L1). One command that builds from a clean checkout. Pin toolchain versions. Write down the compiler, SDK drop and flags. Emit a provenance record with the commit, toolchain and input hashes.
- Move it to a hosted runner (toward L2). Put the toolchain in a container image you control. Run the build on CI infrastructure rather than a laptop. Have the platform sign the provenance, so the claim is tied to the platform, not to a person.
- Separate signing from building (toward L3 thinking). Keep release signing keys out of build steps a developer can edit, and stop one run from influencing another.
You do not need all three before launch. You do need to know which level you are at and say so honestly if a buyer asks.
What buyers can do with it
A customer's security team asks how you know a binary came from your source. L0 answers with trust in a person. L2 answers with a signed record from a platform. Neither is a certification, and you should never describe a level as one. SLSA describes the build, not the product.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate stops a risky change before it reaches the build.
Safeguard's policies and gates can block pull requests that fail dependency checks, one control that supports a hosted, repeatable pipeline. The build platform and provenance signing remain your own pipeline choices.
Quick check
Does a clean laptop count as a hosted platform?
No. L2 requires dedicated infrastructure rather than an individual's workstation, per the SLSA specification.
Is SLSA a certification?
No. It is a framework that describes build integrity levels. Describe it as the level you meet, not a certificate.
Sources
Last reviewed: 19 October 2026.
