builder.id is a URI in SLSA provenance that identifies the trusted build platform that ran the build. The specification says it is intended to be the sole determiner of the SLSA Build level. A verifier decides what level a builder is trusted for, so the field is only as good as that decision.
Many readers expect the level to be written inside the provenance. It is not. The level comes from your trust in the builder named there.
What the field is and where it sits
In the v1.1 provenance format, builder.id lives under runDetails. It identifies the platform, not the person who started the build and not the repository. The provenance page also says consumers must accept only specific signer and builder pairs. That wording matters: you pin both who signed and which builder they claim.
How a verifier turns an ID into a level
The verification page describes a lookup. You keep a list of roots of trust, which records recognized builder identities and the maximum Build level each is trusted to. When provenance arrives, you verify the signature, then look up the level using the recognized keys and the builder ID. If you do not recognize the pair, the level defaults to L1.
The page gives a useful example. One builder is trusted to L3. Another builder claims L3 but is trusted only to L2, so the verifier treats it as L2. The claim in the document does not override your own assessment.
What to pin in practice
| Item | What to record | Why |
|---|---|---|
| Builder ID | The exact URI | Prevents a lookalike builder |
| Signer | The key or identity that signs provenance | Ties the document to the platform |
| Maximum level | The level you trust that builder for | Keeps your policy explicit |
| Review date | When you last assessed it | Platforms change |
Keep this table in version control, so changes get reviewed like code.
Questions to ask about a builder
Before you raise the trusted level of a platform, ask a few things.
- Who operates it, and who can change its configuration?
- Does it run each build in a fresh environment? At L3, that is required.
- Can the steps a build runs reach the signing secrets? At L3, they must not.
- Does it generate provenance itself, rather than letting the build steps write it?
Documentation from the platform operator is a starting point. If it is thin, trust the builder at a lower level until you know more.
Where this can go wrong
A common slip is to accept any builder ID that appears in a valid signature. Another is to compare only the name prefix. Both make it easy for a different platform to pass.
A second slip is forgetting that the level applies to the builder, not to every artifact it ever made. Old provenance produced before a platform change may deserve a lower trust level than new provenance.
Safeguard can add dependency scanning and policy gates to the pipeline you are assessing, and the free scan at https://gold.safeguard.sh/scan is a quick way to inspect what a build pulled in.
Quick check
Does a builder get to declare its own SLSA level?
It can claim one, but the verifier decides, using its list of recognized builders and their maximum trusted levels.
What level applies if I do not recognize the builder?
The verification page says the lookup defaults to L1.
Sources
- SLSA v1.1 provenance (page marked retired, v1.2 is current)
- SLSA v1.1 verifying artifacts
- SLSA v1.1 build requirements
Last reviewed: 19 October 2026.
