When verifying build provenance, what does a consumer compare it against?
answer
- two steps, not one
- authentic first, expected second
- builder, source, ref, entry point
- digest ties it to your bytes
- expectations written before the check
basics
~20 sVerification compares the statement against expectations written down in advance: the builder identity that produced the artifact, the source repository and revision it was built from, the build entry point, and the subject digest matching the artifact you actually hold.
solid answer
~50 sVerification is two steps, and the second is the one people skip. First you establish that the statement is authentic — the signature checks out and the identity that issued it is one you already trust. Then you compare what the statement says against expectations you fixed in advance: the expected builder identity, the expected source repository URI, the expected revision or ref, the expected build entry point, and the subject digest, which must equal the hash of the bytes you are about to install. The digest is what binds the statement to your artifact; without it you have verified a perfectly true statement about some other file. Expectations have to exist before the check — a policy that accepts "whatever the attestation claims" cannot fail. A pass tells you this artifact came from that source through that builder, and nothing about whether the code inside is safe.
go deeper
Be ready to name the four things compared — builder, source repository, revision, entry point — plus the digest match, and to say that a signature check alone is not verification.
Explain where those values live in the statement and why the build type matters for reading them, and why a policy derived from the artifact under test cannot fail.
Show how you would introduce this on a real service: who writes the expectations, how they are stored and changed, and what happens on a mismatch during a release.
Own the framing that verification is an act performed at a trust boundary. Be able to argue what the organisation gains from a gate whose expectations it controls versus one it inherited.
## What "verifying provenance" actually means Build provenance is a signed statement that says *how an artifact came to be*: which build system ran, from which source, at which revision, through which entry point, and what the resulting bytes hash to. Generating it is the producer's job. **Verifying it is a separate act performed by the consumer**, and it is where all the security value lives — a statement nobody checks changes nothing. Verification decomposes into two independent steps that are often collapsed into one in candidates' answers: 1. **Authenticity.** Is this statement really from who it claims? The statement travels inside a signed envelope, and the signature is computed over the payload separately from the payload's own contents — so a valid signature says "someone I can name produced this document", not "this document says what I want". 2. **Expectation matching.** Does the document say the things I decided, in advance, that it must say? This is the step that turns an authentic document into an authorization decision. ## The four expectations A consumer fixes these before the first verification run, not after: | Expectation | What it stops | |---|---| | **Builder identity** | An artifact built anywhere else — a developer laptop, a second CI account, an attacker's runner — presenting a truthful statement about a build you never authorized. | | **Source repository URI** | A build of the *right* build system from the *wrong* code: a fork, a mirror, a similarly named repository. | | **Revision / ref** | A build from a branch or tag inside the correct repository that nobody reviewed or protected. | | **Build entry point** | A different build definition in the same repository and ref producing an equally authentic statement. | Plus the one that is not really an expectation but a binding: - **Subject digest.** The statement carries a `subject` list of `{name, digest}` entries. The consumer hashes the artifact it actually has and requires that hash to appear as the digest of a subject. Skip this and you can verify a genuine statement about an entirely different build. ## Where these live in the document The standard container is an in-toto **Statement**: a `_type` identifying the statement format, a `subject` array carrying names and digest maps, a `predicateType` URI naming the kind of claim, and a `predicate` holding the claim itself. A SLSA provenance predicate splits into a `buildDefinition` — the build type URI, the external parameters that were fed in (typically where the source repository, ref and entry point appear), and resolved dependencies including the source at a specific revision — and `runDetails`, which carries the builder's identity and run metadata. The exact field a repository URI lands in depends on the build type, which is precisely why the build type itself is part of what you verify: it tells the verifier how to read everything else. ## Expectations must be fixed first The most common failure in real adoptions is *derived* expectations: run the verify, see what came back, paste those values into the policy. The check now passes by construction and can only ever detect a later change — never the state of things on the day you onboarded. Expectations should come from somewhere other than the artifact under test: the supplier's documented release process, an internal decision recorded and owned by a person, a value confirmed through a channel the artifact did not travel down. ## What a pass does and does not mean A pass means: *these exact bytes were produced by that builder, from that source at that revision, through that entry point.* It is a statement about **origin**, and the guarantee it gives you is that a tamper anywhere along the delivery path shows up as a mismatch. It is not a statement about **contents** — a signed and verified provenance for a library riddled with vulnerable dependencies verifies exactly as cleanly as one for a clean release. Origin, inventory and endorsement are three different claims answering three different questions: how it was built, what is inside, and who vouches for it. Provenance answers only the first. ## The shape of a good answer in an interview Say the two steps. Name the four expected values. Say that the subject digest is compared against the bytes in hand. Say expectations are fixed before the check. If you can add that a pass proves origin rather than safety, you have covered everything a screening question on this is looking for.
- What is the difference between the signature check and the expectation check?The signature check answers "is this document authentic and from an identity I recognise?" It is cryptographic and binary. The expectation check answers "does this authentic document describe the build I authorized?" It is a comparison against values I chose. A valid signature over a statement describing an unauthorized build should fail verification — and it only does if someone wrote the expectations down.
- Verification passes. What has the consumer actually learned?That these specific bytes were produced by the expected builder from the expected source and revision through the expected entry point, and that nothing altered them in transit. Nothing about whether the code is well written, free of vulnerable dependencies, or licensed the way you need. Origin is not quality.
- Where should the expected values come from the first time you adopt a dependency?From somewhere other than the artifact you are verifying: the supplier's published release process, a decision your team records and owns, a value confirmed out of band. If you learn the expected builder by reading the attestation you just received, your check can only detect later drift, never the situation on day one.
Checking a parcel's courier signature proves the label is genuine. It does not prove the parcel is the one you ordered until you compare the contents against the order you placed before it arrived.
saying these in an interview costs you the question
- Says a valid signature alone is enough to accept the artifact
- Treats whatever the attestation claims as the expectation
- Never hashes the installed artifact to match the subject digest
- Thinks a passing verification means the code has no vulnerabilities
- Confuses provenance with an inventory of what is inside