Handed a signature, an SBOM and a provenance statement for one JAR, which proves it was built from the reviewed branch?
answer
- Only one document describes the build
- Source repository, revision, builder, entry point
- Check the subject digest first
- Unverified statement is just JSON
- Revision recorded is not revision reviewed
basics
~20 sOnly the provenance statement. It names the source repository and revision, the builder and the build entry point for that artifact. The signature covers bytes and a signer; the SBOM covers components. Neither records where the build came from.
solid answer
~50 sProvenance is the only one of the three that speaks about the build. It states that a particular builder produced this artifact from a named source repository at a named revision, via a named entry point. To use it as proof I do three things: compute the digest of the JAR I actually hold and check it equals the subject digest the provenance statement is bound to; verify the signature on the provenance itself, so I know the builder issued it rather than someone hand-writing a file; then check that the recorded revision is one that was on the reviewed branch and passed review. The artifact's own signature answers only who vouched for the bytes. The SBOM answers only which components are inside. A procurement reviewer who tries to answer the origin question from either of those is reading the wrong document.
go deeper
Learn the one-line mapping: signature equals who, inventory equals what, provenance equals how and from where. Being able to pick the right document out of three is the level-appropriate answer here.
Explain the mechanics: provenance names repository, revision, builder and entry point, it is bound to a subject digest, and it arrives inside a signed envelope. Walk the interviewer through checking the digest and the envelope before believing anything the statement says.
Demonstrate the operational judgment: what you do when the digest does not match, when provenance is unsigned, or when the recorded revision is not an ancestor of the protected branch. Show that you treat provenance as evidence of origin rather than as a review verdict.
Own the intake standard. Decide which supplier artifacts must arrive with verifiable provenance, what your organisation does when a strategic vendor cannot produce it, and how much compensating review you are willing to fund instead.
## The situation A payments platform is onboarding a third-party Java SDK that will handle card transactions. Procurement receives three documents for one JAR: a signature, a component inventory, and a build provenance statement. The reviewer's question is narrow and important: **were these bytes built from the branch that passed code review?** Only one of the three can answer it. ## Why provenance is the only candidate Provenance is a statement about the *production* of an artifact. Its content is the build's identifying facts: - the **source repository and revision** the build consumed; - the **builder** that executed the build - which build system, running as which identity; - the **entry point** - which build definition or invocation was run. That is exactly the shape of the reviewer's question. Compare the other two: - The **signature** on the JAR asserts that a digest of those bytes was signed by some identity. Signing happens after the JAR exists and is indifferent to how it was produced. A release engineer can sign a JAR built on a laptop from an unreviewed local branch, and the signature verifies perfectly. - The **SBOM** asserts composition: which components and versions the JAR is made of. Some inventory formats have fields where a producer can *declare* a source location or a version-control reference, but that is self-asserted metadata describing a component, not an attested record of the build that produced this artifact. Treating it as build evidence is a category error. ## Turning "I have a provenance statement" into proof A provenance file lying next to a download proves nothing by itself. Three checks turn it into evidence: **1. Bind it to the bytes you hold.** Provenance is issued about a *subject*, identified by a digest. Compute the digest of the JAR you downloaded and confirm it matches the subject digest in the statement. Without this step you may be reading a truthful statement about a completely different build. This is the step candidates most often skip. **2. Verify who issued it.** Provenance is distributed inside a signed envelope. Verify that signature and confirm the signer is the builder you expect. Unverified provenance is just a text file; anyone can write JSON claiming a build came from a reviewed branch. Note the shape here: the *signature* claim is what makes the *provenance* claim trustworthy - the three documents reinforce each other rather than competing. **3. Map the revision to the review.** Provenance tells you commit `abc123` was built. It does not tell you that commit was reviewed. You still have to establish that the revision was reached through your review process - that it is an ancestor of the protected branch, that it carries the approvals your policy requires. Provenance is *evidence of origin*; branch protection and code review are the *controls* that make that origin meaningful. Under SLSA v1.0 this split is explicit: source-side expectations sit outside the build track, which is about how faithfully the build records and protects its own execution. ## Reading the mapping the other way If a reviewer's question changes, the document changes with it: | Question asked | Document that answers it | |---|---| | Were these the bytes the supplier released? | Signature over the artifact | | Which components and versions ship inside? | Component inventory (SBOM) | | Which repository, revision and builder produced it? | Build provenance | | Is a listed component's flaw relevant here? | An exploitability statement, not any of the three | ## The common wrong answers - *"The signature proves it came from their build system."* It proves an identity signed the bytes. If the signing identity happens to be the build system, that is a weaker inference about origin, not a record of source and revision - and it still names no commit. - *"The SBOM lists the repository, so that settles it."* A self-declared field in an inventory is not attested by the build, and it usually describes a component's upstream, not this artifact's build. - *"Provenance verified, therefore trusted."* Verification tells you the build happened as recorded. Whether the recorded repository is the one you meant, and whether that revision passed review, are separate checks you must actually perform. ## What good sounds like Name provenance immediately, then volunteer the three checks - digest binding, envelope signature, revision-to-review mapping - and finish by saying explicitly what the other two documents do answer. Interviewers are listening for whether you can keep who / what / how apart under pressure, because a procurement reviewer who mixes them up signs off on the wrong evidence.
- The provenance names the right repository and commit. What could still make it irrelevant to the JAR in your hands?The subject digest. Provenance is issued about a specific set of bytes; if the digest of the JAR I downloaded does not equal the subject digest in the statement, the statement is about some other build and tells me nothing about mine. I compute the digest myself rather than trusting a file name, a version string or the fact that both files sat on the same release page.
- Why isn't the artifact's own signature good enough evidence of origin here?Because signing is applied to finished bytes and records only an identity. Someone with the release key can sign a JAR built anywhere, from any branch, and verification still succeeds. Even when the signer is the build system, the signature names no repository, revision or entry point, so it cannot distinguish a build from the reviewed branch from a build from a developer's local branch.
- The reviewer wants one sentence for the audit file. What do you write?Something like: the artifact's provenance, signed by the named builder and bound to the JAR's digest, records that it was built from repository R at revision C, and revision C is an ancestor of the protected branch with the required approvals. That sentence names the evidence, the binding and the control, which is what an auditor is actually looking for.
saying these in an interview costs you the question
- Names the signature as proof of source origin
- Reads a repository URL out of the SBOM as build evidence
- Never checks the statement's subject digest
- Accepts an unsigned provenance file as evidence
- Assumes a recorded revision was necessarily reviewed