The subject of an in-toto Statement names the artifacts the claim is about, identified by digest. If your file's digest matches a subject, the attestation is talking about those exact bytes. It does not prove the artifact is safe or that it was published anywhere.
What the Statement looks like
The in-toto Statement v1 has four fields: a type, a subject, a predicate type and a predicate. The subject is a list of entries, each with a name and a digest mapping an algorithm to a hex value. The spec says each subject MUST have a digest set.
| Field | Role |
|---|---|
| subject | Set of software artifacts the attestation applies to |
| subject name | Optional identifier to tell artifacts apart within the subject |
| subject digest | The binding that verifiers match |
| predicateType | URI naming the kind of claim |
| predicate | The claim itself |
Matching is by digest
The spec says subject artifacts are matched purely by digest, regardless of content type. It also says subjects are assumed immutable, so the artifacts identified by the subject should not change. If the name is not meaningful you can leave it unset or use an underscore.
That makes the name a convenience, not a security control. Never rely on a file name to decide whether an attestation applies.
The check you must do
- Compute the digest of the file or image you actually hold.
- Confirm it appears among the subject digests.
- Only then read the predicate.
Skip step 2 and a valid attestation for one artifact can be attached to another. The SLSA verification steps list exactly this comparison. Its threat model also covers the case of a tampered artifact after the build: the verifier checks the subject matches the artifact hash.
What a matching subject proves
- The attestation was written about these bytes.
- Combined with a valid signature and a trusted signer, the signer made that claim about these bytes.
What it does not prove
- That the artifact is free of vulnerabilities.
- That it was published to a particular registry. SLSA says provenance is a claim of building, not publishing.
- That the claim is true. The attestation is the signer's statement. Trust depends on the signer and your expectations.
Multi artifact attestations
A subject can list several artifacts, such as a release with multiple platform binaries. Match the one you hold. Do not assume the others in the list are also valid for you.
Where Safeguard fits
Safeguard's SBOM and dependency scanning works on the artifact itself, giving you content findings that any subject match leaves open. Try the free scan.
Quick check
Can I rely on the subject name?
No. The spec treats the digest as the match. The name only distinguishes entries within the subject.
What if I rebuild the same source?
A rebuild may give a different digest unless the build is reproducible, so it needs its own attestation.
Sources
Last reviewed: 19 October 2026.
