Your build script writes builder.id into its own SLSA provenance — why is that value worthless?

## Who is speaking Every field in a provenance predicate is an assertion, and the only question that matters is **who made it**. The predicate itself is a payload; it becomes evidence only when something signs it. So the useful frame is: is this statement about the build, produced by a party outside the build, or is it a statement the build made about itself? `builder.id` is where that distinction bites hardest, because it is the field a verifier keys its trust on. It is a URI standing for the transitive closure of the trusted build platform — shorthand for "everything I am relying on when I accept this artifact". If a build script emits its own statement containing `"builder.id": "https://trusted-platform.example/hosted"`, that string is precisely as trustworthy as the script. A compromised step — a malicious dependency's install hook, an injected command, a rogue plugin — writes whatever it likes, and produces JSON byte-identical in shape to the real thing. ## The two properties that rescue the field **Generation outside the job.** The provenance must be assembled by the platform's control plane, observing the run, rather than by code running inside the run. When the platform stamps `builder.id`, `metadata.invocationId` and the timestamps, those fields describe the run from outside; when the job writes them, they describe what the job wished to claim. The JSON shape is identical, which is why reading a provenance document tells you nothing about this on its own — you have to know how it was produced. **Binding the signer to the identifier.** Even platform-generated provenance is worthless if any key can sign a statement naming any builder. The verifier must check that the identity that signed is authorized to assert that particular `builder.id`. Skipping this is a classic hole: the signature verifies, the `builder.id` matches the expectation, and yet the statement was signed by an unrelated key that simply typed the right string. ## Where the SLSA build track puts the line The build track is graded precisely on this question. | Level | What it requires | What it stops | | --- | --- | --- | | L0 | nothing | nothing | | L1 | provenance exists and is distributed; the build may generate it itself | mistakes and accidents, not adversaries | | L2 | provenance is generated and signed by a hosted build platform | undetected tampering after the build; forging now requires compromising the platform | | L3 | the platform hardens runs so one cannot influence another or forge provenance; signing material is unreachable from user-defined steps | a compromised build step minting its own provenance | The self-written `builder.id` is therefore not a violation of L1 — it is the *definition* of L1's ceiling. What it cannot do is support a claim of L2 or L3, and it cannot survive an adversary who controls any part of the build. ## The same argument applies to metadata `metadata.invocationId`, `startedOn` and `finishedOn` inherit the property. A job-written `finishedOn` proves nothing and cannot be used to argue "this artifact predates the compromise". A platform-stamped `invocationId` is genuinely useful: during an incident it is the handle that takes you from an artifact in a registry back to the specific run, its logs and its triggering event. The value of the field is entirely a function of who wrote it. ## What the field still does not tell you A hardened builder and a perfect `builder.id` say the build platform did what it was asked, faithfully. They say nothing about whether what it was asked to do was safe. The inputs may include a compromised dependency; the source may contain a backdoor a reviewer missed; the recorded ref may be a branch nobody approved. Build integrity and input quality are different axes, and a candidate who answers "we are L3, so we are covered" has collapsed them. Raising the builder's level closes forgery of the record; it does not clean what the record describes.