Your pipeline generates a provenance attestation for every build — what still has to happen for that to protect anything?
answer
- who is reading these statements?
- two halves, only one is a control
- a gate that has never failed anything
- signed after the fact by a non-builder
- the value is the deny, not the document
basics
~20 sA provenance statement proves nothing until something checks it. The control is a consumer verifying the statement against expectations fixed in advance and refusing the artifact when the check fails. Unverified attestations are metadata, not protection.
solid answer
~50 sGenerating and verifying are two separate halves, and only the second is a control. Provenance describes how an artifact came to be — which builder produced it, from which source repository and revision, through which entry point — but a statement sitting next to an artifact changes nothing unless something fetches it, checks the signature against a key or identity you already trust, checks that the statement's subject digest matches the exact bytes you are about to run, and compares its claims against expectations you wrote down beforehand. The failure I look for is an org that stands up an internal attestation service, emits statements for thousands of artifacts, and has never once failed a deploy — often because the service attests artifacts it did not build, hours after the fact, from whatever metadata it could scrape. That produces audit paperwork, not integrity. Pick one enforcement point, make it deny on failure, and then count the denials.
go deeper
Be ready to say plainly that a signed statement only helps if something checks it before the artifact runs, and to name what that check compares: signature, subject digest, and expected builder and source.
Explain the mechanics of the check — trusted signing identity, subject digest matched against the artifact in hand, claims compared to expectations fixed in advance — and why the signature alone settles none of that.
Show you would find the enforcement point, put it in deny mode, and prove it works by feeding it a mismatched artifact. Be able to spot statements signed by something that never observed the build.
Own the asymmetry: generation is easy to mandate and verification breaks someone's deploy. Be ready to describe the rollout that gets an estate to enforcement without turning the gate into a rubber stamp.
## The two halves Build provenance is a signed statement that says: *this builder, running this build definition, from this source repository at this revision, produced an artifact with this exact digest*. It is a claim about **how an artifact came to be** — distinct from an SBOM, which claims **what is inside** an artifact, and from a plain signature, which claims only **who vouches for** it. Producing that statement is the cheap half. A build platform that already knows the source, the revision and the output bytes can emit one automatically, and many now do with a single opt-in. Nothing about that emission stops a bad artifact from running. The security property only appears when some consumer, at some specific point, **refuses to proceed** because a statement was missing, unsigned by an identity it trusts, or inconsistent with what it expected. Generation is bookkeeping; verification is the control. ## What verification actually consists of At minimum, four checks, all of them before use: 1. **Signature.** The statement arrives inside a signed envelope; the payload and the signature are separate, so a statement that has been read out of its envelope and passed around as JSON carries no assurance at all. You check the signature against a key or identity you decided to trust *in advance*. 2. **Subject binding.** The statement names its subject by cryptographic digest. You compute the digest of the artifact actually in your hand and require it to match. Without this step, a perfectly valid statement about some *other* artifact will happily verify. 3. **Expectations.** The claims inside — the builder's identity, the source repository, the revision, the entry point — are compared against values you fixed beforehand. "Whatever the statement says" is not an expectation. 4. **A deny path.** The check must be able to stop something. A verification whose only failure mode is a log line is a monitor, not a gate. ## The asymmetry, and why organisations land in it Generation is easy to mandate top-down: turn on a platform feature, watch the count of statements climb, report the number. Verification is hard, because it means someone's deploy will break, and the first breakage lands on a team that did nothing wrong. So the natural equilibrium is thousands of statements produced and zero verified — the shape of the problem is *asymmetry*, not absence. A sharper version of the same failure is an internal "attestation service" that generates provenance for artifacts it **did not build**. Some job notices a new artifact, looks up whatever build it thinks produced it, assembles a statement and signs it. The signature is cryptographically fine. The *claim* is hearsay: the signer did not observe the build, so the statement records what it was told rather than what happened, and the real trust root has quietly become the scraper's inference. Worse, a downstream verifier cannot tell the two apart — both look like a valid statement from a trusted key. That is how an organisation ends up with unassailable-looking audit evidence and no integrity property whatsoever. If an insider or a broken automation can cause a statement to exist for an artifact nobody built from the claimed source, the whole exercise has produced negative value: it is now easier to argue that something was fine. ## How to tell in practice whether yours is real - Ask where verification runs and what it does on failure. If nobody can name a single point, there is no control. - Ask for the count of denials over the last quarter. Zero is a finding, not a success metric, unless someone can show a deliberate test. - Take a build artifact, corrupt a byte or hand the gate an artifact whose statement belongs to a different build, and confirm it is refused. - Ask who signs, and whether the signer *observed* the build or was *told about* it. ## What generation alone still buys you It is not worthless. Statements you never verify are still forensic material: after an incident you can ask which artifacts claim to come from a repository nobody recognises, or find running artifacts with no statement at all. That is a **detective** use, available only after the fact, and it depends on the statements being honest — which is exactly what the non-builder anti-pattern destroys. Treat it as the starting inventory, and treat the first enforcing gate as the moment the programme actually begins.
- How would you check in five minutes whether your verification is real?Ask where the check runs and what it does on failure, then ask for the number of artifacts it has denied. If nobody can name an enforcement point, or the denial count is zero with no deliberate test behind it, you are running in report-only mode. Confirm by handing the gate an artifact whose statement belongs to a different build and watching whether it proceeds.
- What is wrong with a service that signs provenance for artifacts it did not build?The signature is valid but the claim is hearsay. The signer did not observe the build, so the statement records what some inference told it rather than what happened, and the trust root becomes that inference. A verifier cannot distinguish it from a genuine builder-issued statement, so the whole population of statements is devalued at once.
- Is generating provenance you never verify completely worthless?Not completely — it is forensic material. After an incident you can query which running artifacts have no statement, or which claim a source repository nobody owns. But that is detective and only after the fact, and it holds only if the statements are honest. It is an inventory, not a control, and should never be reported as one.
Issuing every visitor a badge is not access control. The control is the door that refuses to open when the badge does not match the expected name and photo.
saying these in an interview costs you the question
- Says producing signed statements makes the pipeline secure
- Cannot name a single point where verification happens
- Treats a gate that has never denied anything as evidence of health
- Skips the subject digest check and verifies the signature only
- Confuses provenance with a vulnerability scan verdict