Trusted Builder Identity
also called Builder Allow-List, Verified Builder
The specific set of builder identities a verification policy will accept, which is the real root of trust behind any provenance check - and the assertion most policies never make.
A deployment gate blocks every image lacking a signed provenance attestation. A developer builds an image on a laptop, attests it with a key the pipeline can read, and it deploys. The gate did its job as written, because the policy checked that an attestation existed and never asked who produced it.
Trusted builder identity is the missing assertion. Provenance says "builder B produced artifact D from source S at commit C", and the statement is worth exactly what B is worth. A verification policy has to name the builders it accepts, bind them to the repositories and pipeline definitions allowed to produce a given workload, and reject everything else.
Why it matters
SLSA's build track is a ladder of this property. Build L1 requires only that provenance exists and permits it unsigned. Build L2 requires a hosted platform that generates and signs it. Build L3 requires a hardened platform where a build cannot forge its own provenance. A policy checking for a signature without checking the builder gives L1 behaviour behind an L3 claim.
The consequence arrives with self-hosted runners. If any team can register one, any attestation can come from a machine that team controls, so it reads "built by a computer belonging to the person who wants this deployed". Such runners are not disqualified by nature, but by anyone being able to add one while the verifier cannot tell the difference.
Implementation patterns
- An allow-list of builder identities in the policy, never a wildcard, each entry owned and reviewed.
- Bind the identity to the source. Assert the repository and pipeline definition in the predicate, so one job cannot build another team's image and have it accepted.
- Keyless verification against a workload identity issued by the build platform, so what is checked is the platform rather than a key someone may have copied.
- Keep private keys out of the deployment environment, so the cluster holds public verification material and the policy. A signing key readable from inside the cluster makes the trust root a member of the blast radius it protects.
- A negative test, quarterly: an artifact built outside the allowed builders must fail the gate, because a control that has never rejected anything has never been tested.
Industry example
SLSA v1.0's build levels are the documented reference, worth quoting in reviews because the ladder separates "provenance exists" from "a platform you trust produced it". The L2 requirement — the hosted platform generates and signs the provenance rather than the build doing so for itself — is the distinction a presence-only policy erases.
Most organisations sit between L1 and L2 while believing they are higher, with a hosted builder for the main pipeline, a self-service runner pool beside it, and a verifier that cannot distinguish them. The gap closes in 2 to 6 weeks with an allow-list and keyless verification. The telling number is rejections on builder identity — zero in 180 days means nothing running in production is being asserted against.
Failure scenarios
- The wildcard allow-list. A policy accepting any builder in the organisation accepts the weakest one, whichever team needed a GPU runner last quarter.
- The trust root inside the blast radius. Any workload able to read the signing secret can mint acceptable attestations, so cluster access becomes build authority.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Narrow allow-list plus repository binding | the gate asserts a property rather than a format | operational toil as teams legitimately need new builders |
| Keyless verification | no key to copy or rotate | a dependency on the platform's identity provider during deploys |
When not to use it
With one team, one repository and one registry, restricting who may push to the registry achieves more than verifying who built the image, with no new trust root and no new failure mode. Where the artifact is built and deployed by the same hosted pipeline with no second path into the registry, the property is already structural, so a verifier buys audit evidence rather than detection. Where you do adopt it, set the failure mode per policy class: block unverified images on the serving path, and let a cluster add-on through with an alert, because the alternative is a cluster you cannot repair.
Interview question
Q: Our admission policy rejects any image without a signed provenance attestation and has rejected nothing in two quarters. Tell me what it currently proves, what you would change, and how you would demonstrate the change worked.
What a strong answer covers: that a signature's presence proves only that something in the organisation made a claim; that the load-bearing assertions are builder identity, source repository and a commit reachable from a protected branch; why a key inside the verifying environment is not a trust root; the SLSA ladder as shared vocabulary; and the demonstration, a deliberate negative test rather than a dashboard.
Quick check
Quiz: A gate verifies an attestation signed by a key your pipeline holds. What has it proved? Answer: that something with access to that key made a statement, not where the artifact was built.
Flashcard: Which field turns a provenance check from ceremony into a control? — The builder identity, bound to the repository and pipeline allowed to produce that workload; a signature alone proves only that a claim was made.