A vendor's SLSA provenance carries a buildType URI you have never seen — do you accept it?

## Why buildType is the load-bearing field A provenance predicate is mostly a bag of names and values. `buildType` is the URI that tells you what those names mean. It is a contract, and it is supposed to specify at least: the complete set of `externalParameters` this kind of build accepts, the semantics of each one, which of them are under an external caller's control, and what the platform guarantees about the process. Without it you are reading JSON by intuition. A field called `configPath` might reference a file inside the repository you already pinned by ref — harmless. Or it might accept an absolute URL to a config fetched at build time — in which case pinning `repository` and `ref` pins nothing, and someone who can trigger a build with a different `configPath` controls the artifact. The two possibilities look identical in the document. This is the gap: not a forged field, not a failed signature, simply a contract nobody published. ## What you actually still have Be precise about what survives. The signature still verifies, so you know an identity you recognise vouched for this artifact. That is **authenticity**, and it is not nothing — it gives you non-repudiation and a party to go back to. What you have lost is the part that made provenance worth collecting: the ability to say *this artifact came from the source and process I expected*, because you cannot map recorded inputs onto expectations you can defend. Grading yourself honestly here matters more than the outcome. Teams that record "provenance verified" in a compliance system when they only checked a signature have created a fiction that someone will later rely on. ## The three real options **Block.** Defensible when the artifact sits somewhere consequential — in a build of your own product, in a base image, anywhere it inherits privilege. The cost is a stopped shipment and a conversation with a vendor who will point out that their artifact is signed and their competitors do less. **Accept, downgraded and compensated.** Record the artifact as builder-trust-only rather than provenance-verified, and buy back assurance elsewhere: a staged rollout, tighter runtime restrictions, closer monitoring of the first deployments, a narrower blast radius. This is usually the right answer under a real deadline, and it is only honest if the downgrade is recorded somewhere a future auditor sees, not just in someone's head. **Ask, time-boxed.** Vendors frequently have the document and have simply not linked it. A dated request with a decision date attached converts an open question into a scheduled one. Without the date it becomes a permanent exception. ## The allowlist as the durable answer The scaling answer is a small list of `buildType` URIs your organisation has actually read and written expectations for. An unknown one then has a defined consequence instead of prompting a fresh argument each time. This also reframes the vendor conversation usefully: you are not asking them to change their build, only to publish what it already does. The cost is honest to state: someone has to read each new build type, and that person is a bottleneck. In practice you accept a short list and treat everything else as builder-trust-only, rather than pretending you will document the world. ## The obligation when you are the emitter The symmetry is worth owning, because a lead is usually on both sides. If your platform defines a `buildType`, that URI is a promise to strangers. Publish the parameter list and say which values a caller controls. And when the meaning of a parameter changes — not just its default, but what it selects or who can set it — mint a **new** URI rather than editing the document behind the old one. Consumers pinned their expectations to the old semantics; silently changing what those names mean invalidates their verification without anything visibly failing, which is the worst way for a control to break. ## What a weak answer looks like "The signature checks out and the repository matches, so it is fine." That answer assumes the two fields it looked at determine the build — which is exactly the thing the missing document would have told it. The senior version names the assumption; the principal version decides what the organisation does with artifacts where the assumption cannot be checked, and writes that decision down.