An in-toto statement lists three deploy bundles — how does a deploy job confirm it covers the one it holds?

## The scenario One build job produces three deploy bundles — say three functions of a serverless application — and publishes a single attestation whose statement enumerates all three in its `subject` array. A later deploy job handles one bundle at a time. It has the statement, and it has one zip file. Does the statement apply? ## The mechanical answer The subject array binds by **content**, not by identity, name, or provenance-by-association: 1. Verify the signing envelope first, so the statement's fields are trusted at all. 2. Compute the digest of the exact bytes about to be deployed — the file on disk in this job, not the one in the build log and not the one in the registry that you assume is the same. 3. Scan `subject` for an entry whose `digest` map holds that value under an algorithm your policy accepts. Hex comparison should be case-insensitive; algorithm choice should be explicit, because a statement may offer both a strong and a weaker hash and accepting whichever appears first hands the choice to the producer. 4. If exactly one entry matches, the claim in the predicate applies to these bytes. If none matches, the artifact is **unattested**. That is the whole binding. Everything else in the statement — including the friendly `name` on the matching entry — is commentary. ## The two failure modes worth naming **Matching by name.** The `name` field exists so humans reading a statement can tell which artifact is which. It is inside the signed payload, so a third party cannot edit it after the fact, but that is not the same as it identifying bytes: the *producer* chooses it, and it is stable across every run of the pipeline. A verifier that finds `name == "orders-fn.zip"` and stops has verified that a build once produced something called that. **Set-level reasoning.** "This build ran on a hardened builder and emitted an attestation, therefore what I am deploying is fine" collapses three artifacts into one trust decision. A build system compromise — an injected step, a poisoned cache, a tampered publish stage — does not need to defeat the signature to defeat that reasoning; it only needs to substitute one of the three files somewhere between attestation and deployment. Per-artifact digest matching is precisely what closes that gap, and it is the reason the subject is an array of digests rather than a build identifier. ## The mismatch that is subtler than a tampered file A related and very common defect: the statement's subject binds bytes **nobody actually consumes**. A packaged archive is attested, but the deploy step verifies against, or runs, something derived from it — an extracted tree, a rendered set of manifests, a repacked layer. The digests will never match, and the reflex fix is to relax the check "because the contents are the same". They may be; the point is that no attestation covers the derived bytes, so the derivation step sits outside the verified chain. There are two honest resolutions: verify the packaged artifact at the moment it is fetched and treat the derivation as inside your trust boundary (with the derivation code itself under change control), or have the deriving step emit and attest its own output so the thing you run is the thing that was signed. Loosening the comparison is not a third option. ## What to do when nothing matches Fail closed, and make the failure legible. A useful error names the digest computed, the algorithm used, and the digests the statement did offer, because the overwhelmingly common cause is not an attack but a pipeline that re-compresses, re-tags or normalises the artifact between attestation and deployment. Diagnosing that from a bare "verification failed" wastes hours, and teams that cannot diagnose it quickly are the teams that end up adding a bypass flag. ## What the check does *not* establish Matching a subject digest proves the predicate is about these bytes. It says nothing about whether the predicate's contents are true, whether the signer was authorised to make that claim, or whether the artifact is free of vulnerabilities. Those are separate questions answered by separate controls. The subject match is the join — it is what lets every other claim about this artifact be correlated — and it is worthless if performed on the wrong bytes.