Release provenance and attestations
Verify who made a scoped statement about which artifact, then evaluate its claims under a target policy without confusing authenticity with code correctness.
On this page
The question for today
What you’ll understand
- Bind an attestation subject digest to the exact artifact under evaluation.
- Separate signature or identity verification from policy acceptance of claims.
- Explain the limits of provenance and budget verification work without bypassing checks.
An attestation is a statement with a subject and a defined claim format. For a release, it can provide evidence about how an artifact was built or which checks ran. Its value depends on trustworthy identity, correct subject binding, and a policy that understands the claim. A signed statement about a different artifact or an untrusted builder does not become useful simply because cryptographic verification succeeded.
Verify the envelope, identity, subject, and claim type
Start by identifying the artifact digest that the target actually intends to run. Check that the attestation subject refers to that digest under the expected algorithm and object scope. An in-toto statement distinguishes subject information and predicate type so a verifier can interpret the claim rather than accepting an arbitrary signed JSON object. Verify the supported signature or identity mechanism against the intended trust policy, including relevant identity and validity constraints. A trusted builder for one repository is not automatically authorized for every other project or deployment environment.
Authenticity and meaning are separate checks. A valid signature can establish that an accepted signer endorsed particular bytes, subject to the verification mechanism's assumptions. The predicate still needs a supported schema and an interpretation matching the decision. A test-result statement does not necessarily claim a hermetic build, and a build-provenance statement does not necessarily claim that all tests passed. Treat unknown or missing required evidence according to an explicit policy rather than silently translating it into success. Preserve the verified statement and policy revision with the promotion record.
Provenance narrows a build claim
SLSA provenance describes build-related evidence such as builder identity, build definition, resolved dependencies, and run details under a defined specification. A consumer verifies the fields required by its own expected build and trust model. Merely finding a source commit string is not enough if an untrusted process could invent the surrounding statement. Conversely, an authenticated trusted builder can faithfully build defective source. Stronger build isolation and tamper resistance address certain supply-chain threats, while functional tests, dependency assessment, and runtime compatibility address different risks.
Verification should bind the artifact that is promoted, not a convenient neighboring tag or a stale build output. If a multi-platform index is accepted, understand how its child manifests are selected and which claims cover that object relationship. Evidence retention and revocation or policy changes also matter over the rollback horizon. A historically approved artifact may need a new decision if the trust policy or vulnerability context changes. That does not change its digest; it changes whether the current target accepts the same object under current requirements.
Make failure reasons observable without weakening the rule
Distinguish unavailable evidence, malformed statements, failed identity checks, subject mismatch, unsupported predicates, and policy rejection. Those failures require different remediation, and a generic retry loop can hide a permanent mismatch. Verification caches need keys that include the relevant artifact, evidence, trust material, and policy version, with deliberate freshness behavior. A cache hit under an obsolete policy is not current authorization. Keep a controlled exception process tied to a specific artifact and scope if the organization permits one, rather than a global skip-verification switch with no expiry.
Use the queue lab only to inspect verification-service capacity. Reset, set both λ=2 and μ=3, predict the initial four jobs drain at t=4, then Play or Step. Separately Reset, set both λ=4 and μ=3, predict one-job-per-second growth from four, then Play or Step. The equal jobs do not perform hashing, signatures, identity checks, or policy evaluation. Its M/M/1 mean needs separate assumptions. Explain why overload should lead to a specified wait or rejection response rather than silently treating missing verification as an accepted release.
Work it through
Price verification, then evaluate the independent policy result
A teaching verifier hashes a forty-MiB artifact at a sustained 200 MiB/s, verifies eight required evidence objects at two milliseconds each, and evaluates policy in ten milliseconds. Assume sequential work and no fetching. One required evidence object has a mismatched subject digest.
Hashing takes 40/200=0.2 seconds, or 200 ms. The eight verification operations contribute 8×2=16 ms under the fixed-cost assumption.
Add ten milliseconds of policy work to obtain a modeled 226 ms total. That timing does not measure the strength of the claims or make the evidence applicable to another digest.
The required subject binding fails, so the illustrative all-required rule rejects the release even if every signature is valid. Completing eight cryptographic checks is not eight votes that can outnumber the missing binding.
Resource budgeting and evidence acceptance are different decisions. Authentic statements must still be about the right subject and satisfy the required claim scope.
The living notebook
Explore the model
Interactive lab · queue
Verification capacity does not change acceptance meaning
Reset, set both λ=2 and μ=3, predict drainage of the initial four jobs at t=4, then Play or Step. Separately Reset, set both λ=4 and μ=3, predict growth from four, then Play or Step. This fluid work queue performs no cryptographic, subject-binding, or policy verification; stochastic mean assumptions are separate.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA busy verifier needs explicit admission behavior, not a reinterpretation of missing evidence as success.
Pause & reason
Check your understanding
Your turn
Try it yourself
A cached verification decision was made for digest D under policy version 7. Policy version 8 now requires an additional builder claim. Can the old cache entry alone establish acceptance under version 8?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Distinguish unchanged artifact bytes from changed acceptance requirements.
Compare with the solution
No. The old decision proves only what the version-7 verification recorded. Reevaluate the required evidence under version 8, or use a cache whose key and validity rules explicitly bind the current policy and trust inputs. Artifact immutability does not make every historical acceptance decision valid under a later rule.
Keep the idea
Take it with you
- Verify identity, subject binding, claim type, and policy as separate requirements.
- Provenance describes scoped build evidence rather than defect-free code.
- Bind cached decisions and retained evidence to the target policy revision.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.