A critical Java data connector ships with no provenance attestation — what are your realistic options?

## Why this is a judgment question Every enforcement programme meets this within weeks. You stand up verification, it works for everything your own builds produce, and then you hit a supplier — often a small, specialised one — whose artifact your business depends on and who publishes no build provenance and shows no sign of starting. The question is never "how do I make them publish"; as an engineering lead you cannot, and waiting is a decision with a default answer of *no control forever*. The question is which of three options you take, and how you keep the answer visible. ## Option 1 — rebuild from source and attest it yourself If source is published and the build is tractable, build the component on your own hardened build system and issue provenance for the artifact you produced. This is the strongest outcome available: you get a real statement, generated by something that observed the build, and it slots into your existing verification unchanged. Be honest about what you bought. The claim is about **your** bytes, not the vendor's — you have not verified the vendor's release, you have replaced it. And you have taken on real cost: tracking upstream releases, reproducing their build environment, patching on their cadence, and owning the support conversation when behaviour differs from the shipped artifact. For a component with wide reach and a stable, buildable source tree, that trade is usually worth it. For a large opaque product it is not on the table. ## Option 2 — accept, with an honest and clearly weaker claim Most of the estate lands here. You ingest the vendor artifact once, deliberately: record the exact digest you received, who approved it, what evidence you gathered, and when. You attach a statement of your own that says **exactly that** — an ingest or review record — and you keep it in a predicate that no verifier will confuse with build provenance. That last constraint is the whole discipline. The tempting shortcut is to have an internal service emit build-provenance-shaped statements for vendor artifacts so the gate goes green and the dashboard shows full coverage. That is the worst available outcome: it launders an unverified artifact into a verified-looking one, destroys the meaning of every genuine statement in the estate, and the person who later reads that statement has no way to tell hearsay from observation. Say what you know. "We received these exact bytes on this date, this person approved them, this evidence exists" is a real, useful, weaker claim — and downstream policy can treat it as weaker precisely because it is labelled honestly. ## Option 3 — refuse, replace, or contain Refusal is a legitimate answer when a component's reach is large enough. So is the middle path that gets used more often: accept the artifact, but bound what an unverifiable component can do. A data connector is a useful case because its reach is the whole point of it — it holds database credentials, it reaches inside the estate, it opens network paths. If you cannot verify how it was built, you can still ensure it runs with narrowly scoped credentials, restricted egress, and no ambient access to anything it does not need, so that the blast radius of a compromised upstream build is a bounded set of data rather than the estate. ## Tier by reach, not by supplier size Across hundreds of suppliers, a uniform bar is either so low it means nothing or so high it stalls the business. The variable worth tiering on is **what the component can reach**: credentials it holds, data it can read, network it can open, whether it runs in the build system itself. A build-time plugin with an unverifiable origin is a far sharper problem than a leaf library in a reporting service, regardless of vendor size. Spend rebuild-and-self-attest effort at the top tier; use ingest records and containment below it. ## Make the gap data, not vibes Whatever you choose, the decision must exist as a machine-readable fact attached to the artifact, so the gate's answer for it is explicit rather than a hole. The test of the programme is whether you can answer, on demand and without a survey: which artifacts currently running have no build provenance, who accepted each, on what evidence, and what each can reach. An organisation that can answer that has managed the risk. One that cannot has an enforcement gate with a quietly widening set of things it does not look at. ## Answers that signal weakness "We would require it in the contract and wait" is not an engineering answer to a running system. "We would generate the attestation for them" is the laundering failure. "We would block it" with no consideration of what the component does is refusing to make a trade-off, which is the skill the question is testing.