Verify what an artifact attestation actually proves

A build artifact can be identified by a cryptographic digest. Provenance can describe how a builder produced that artifact, including relevant inputs and build context. A signature or attestation can bind those claims to an identity. These mechanisms help answer where the artifact came from. They do not prove that the code is free of vulnerabilities or malicious behavior.

Verification needs a trust policy. Check the artifact digest, the attestation's subject, the expected builder identity and the claims required by the deployment policy. A valid signature from an unapproved builder is not enough. An approved builder producing an artifact from an unexpected source revision may also fail the intended contract.

Avoid mutable labels as the sole deployment identity. A tag such as latest can point to different bytes over time. Record the digest selected for deployment and ensure the verified attestation refers to those exact bytes. Verifying one artifact and deploying another defeats the chain.

Keep source review and dependency assessment separate. Provenance can show that a reviewed revision entered a particular build, but the revision can still contain a defect and the build may fetch dependencies. Policy should state which inputs and build properties matter. Do not imply that a provenance field automatically validates every dependency.

In an interview, draw the chain from source revision to builder to artifact digest to deployment. Then identify each place where substitution or an overbroad trust decision can occur. The answer should say which claims are verified and what remains a separate security review.

Teaching release R7 is built from source commit C7 by builder B1. It produces artifact digest D7. The deployment pipeline verifies an attestation whose subject is D7 and whose builder is B1. The pipeline then deploys the mutable tag production without resolving and binding it to D7. Another process changes production to D8 before deployment.

The verification succeeded for D7, but the deployed bytes are D8. This is a time-of-check/time-of-use gap at artifact selection. The correction is to deploy the verified digest or otherwise ensure the final pull resolves to the verified subject under a tested mechanism. A second signature check on the old attestation cannot prove D8 is acceptable.

Consider three attestations. A1 describes D7 from approved B1 and expected C7. A2 describes D7 from unknown B2. A3 describes D8 from B1 and C7. Under a policy requiring D7, B1 and C7, only A1 satisfies all conditions. A2 may be cryptographically valid but lacks the trusted builder. A3 may reflect another legitimate build, yet it is not the selected artifact. The policy should not silently treat all valid signatures as equivalent.

Now suppose B1 itself is compromised. Provenance signed by B1 can still match the configured identity. This is why builder hardening, isolation and limited credentials matter. Attestation gives evidence about a claimed process under a trust model. It cannot make a compromised trusted authority truthful by definition.

A software bill of materials answers a related but different question about components. It can help inventory dependencies and assess exposure to known issues. It does not replace provenance, and neither artifact proves the application cannot be exploited. State which document supports which decision. A list of packages with no binding to the deployed digest can also become stale or describe the wrong build.

Use invented digests and claim records in a local exercise. The learner can evaluate policy without downloading or running an untrusted artifact. Include one wrong subject, one wrong builder, one unexpected revision and one fully matching record. Add a valid provenance record for intentionally vulnerable teaching code to show that origin and safety are separate dimensions.

A deployment gate should report a precise reason. 'Attestation subject does not match selected digest' supports a different response from 'no attestation found.' Do not respond to every failure by bypassing verification. A temporary exception needs a named owner, bounded scope and a record of what evidence is missing.

Keep the trust configuration reviewed. If the approved-builder list accepts any workflow in any repository, the verification machinery may work while the policy is too broad. This parallels OIDC trust from the previous lesson: cryptographic validity and authorization scope are separate. The stronger answer identifies both.

Finally, record what actually ran. A release record should link source revision, artifact digest, verified evidence and environment. That lets an incident investigator answer whether a vulnerable component or suspicious build reached a particular service. A successful deployment timestamp alone is not enough to reconstruct the artifact identity.

Teaching records:

These are invented identifiers. The exercise checks trust logic rather than cryptographic implementation. Real verification must validate the attestation format, signature and identity chain with the chosen tooling.

An attestation correctly describes digest X, but deployment uses tag stable, now resolving to Y. The signer is approved. State the failure and the smallest evidence needed before deployment can proceed.

The deployed artifact is not bound to the verified subject. Resolve the final artifact identity and require a valid accepted attestation for that exact digest, then deploy that verified digest. If Y is intended, review Y's evidence rather than reuse X's. Also verify required source and builder claims. An approved signer does not make an attestation about X a statement about Y.

Score out of four: one point for the correct result, one for showing the intermediate reasoning, one for identifying the stated failure case, and one for a verification that could disprove the answer. Do not award the reasoning point for a tool name alone.

Misconception 1: signed means safe. A valid signature can authenticate provenance for vulnerable or malicious code. Misconception 2: verifying a tag once binds future pulls. Mutable tags can change, so the deployed digest must match the verified artifact.

Evidence class: recommended. Original practice.

What does a valid provenance attestation let you claim?

Strong answer: Under the verified trust model, it binds stated build information to a specific artifact subject and builder identity. I would still review source, dependencies and runtime behavior separately, and confirm the deployed digest is the verified one.

Follow-up: What remains at risk if the approved builder is compromised?

Weak answer indicators: Accepting any signer; treating SBOM and provenance as interchangeable; verifying one digest and deploying a mutable tag; claiming vulnerability freedom.

Technical references: SLSA provenance; GitHub Actions OIDC. Sources support the documented mechanisms. The numbers, decisions, rubrics and interview prompts in this lesson are original teaching examples, not measurements or employer question claims.