How do you set provenance expectations for a sole-source vendor you cannot audit?

## The situation A hospital integration team is adopting a vendor's Python wheel that handles patient records. There is one vendor; switching is a multi-year procurement. The vendor publishes build provenance, which is more than most do. You have no ability to audit their build system, no leverage to change it, and you cannot walk away. This is a **principal-level question** because the technical part is easy and the organisational part decides whether any of it is worth anything. ## Failure one: expectations derived from the artifact The overwhelmingly common adoption path is: install the tooling, run a verification against the vendor's latest release, read what came back, and write those values into the expectation record. The gate is green immediately, which feels like success. Think about what such a gate can detect. It compares the vendor's artifacts against values taken from a vendor artifact. On the day of onboarding it cannot fail — the expectation was defined as "whatever we saw". If the vendor's build system was already compromised at that moment, you have enshrined the compromised builder as your trusted one, permanently, and every future release from the compromised builder verifies. What it *can* do is detect change over time, and that is genuinely useful: an attacker who takes over the vendor's release process later has to either reuse the exact original builder and repository or trip your gate. So derived expectations are not worthless — they are a **tripwire, not an attestation of trust**, and you should say that out loud rather than let the organisation believe otherwise. ## Doing it properly: independent sourcing The expected values must come down a different path from the artifact: - The vendor's published release documentation, which names the build system, the source repository and the release ref convention. - Written confirmation from a named engineering or security contact — a support ticket, a signed questionnaire response, an architecture review. - A onboarding review that records **the date, the channel and the person**, so the answer to "why do we trust this builder?" is a record and not folklore. Agree, when you have any purchasing leverage at all, that the vendor announces changes to the build system, source repository or release process ahead of time. Even without leverage, asking establishes that an unannounced change is anomalous. ## Failure two: the tautological gate The same defect appears inside your own walls. A pipeline that builds an artifact and then, in a later step of that same pipeline, verifies the artifact's provenance against the builder that just produced it has built a check that cannot fail. If the build system is compromised, the compromised system generated the statement, and the compromised system evaluated it. The check consumes evidence produced by the thing it is supposed to be checking. Verification earns its value at a **trust boundary**: a different party, a different stage with independently held expectations, a deployment gate whose expectations the build cannot edit. When you review a verification design, the first question is not "what does it check?" but "who holds the expectations, and could the thing being verified change them?" ## Deciding the failure path before it fires For a sole-source dependency in a safety-relevant setting, the response to a mismatch is a business decision that must be made while nobody is under pressure: - **Default: hold and confirm.** Stop the rollout, contact the vendor through the channel you already established, and confirm whether the change was intentional. Most mismatches are a vendor migrating build systems and forgetting to tell anyone — but you learn that by asking them, not by assuming it. - **Never auto-update.** A policy that rewrites the expectation on mismatch is not a gate. If the update is legitimate, it goes through the same review that set the original values. - **Name the decider.** For a clinical dependency, blocking a release has patient-facing consequences. Security cannot unilaterally hold it and clinical operations cannot unilaterally wave it through; the escalation path and the person who can accept the risk in writing are agreed in advance. - **Bound the exception.** If an acceptance is granted, it is time-boxed and tracked, not a permanent widening of the expectation. ## What to say in the interview Name the derived-expectation trap and the fact that it degrades the gate to change detection. Say where independent values come from and that the record has an owner. Name the tautology — a verifier fed by the thing it verifies. Then talk about the failure path and who decides, because a principal-level answer here is about **who owns the values and who can override the outcome**, not about which fields get compared.