Provenance is a record of how an artifact was built. An attestation is a signed statement about an artifact. The subject is the artifact the statement covers, identified by its digest. The predicate is the claim itself, such as "this was built from that source by that builder."
These four words show up together in pipeline documentation, and they are easy to mix up. This post gives each one a plain definition, shows how they nest, and ends with a short table you can paste into an internal wiki.
The shortest useful definitions
Provenance. The SLSA specification describes a provenance format that records how software artifacts were produced, so that consumers can check that a build matched expectations and others can rebuild the artifact if they want. Think of it as the build's receipt.
Attestation. A signed claim. The signature is what turns a loose JSON file into something a verifier can check against a known identity. Provenance is one kind of attestation. An SBOM can be another.
Subject. The in-toto attestation Statement spec says each subject is a software artifact, and each one must carry a digest. Artifacts are matched by digest, not by name, because a digest names exact bytes.
Predicate. The claim-specific content. For provenance the predicate type is https://slsa.dev/provenance/v1. A different claim, such as an SBOM, uses a different predicate type.
How the pieces nest
The in-toto Statement is the middle layer. It binds an attestation to specific artifacts and says what kind of predicate follows. Its required fields are the schema type, the subject list, and the predicate type, with the predicate itself optional.
{
"_type": "https://in-toto.io/Statement/v1",
"subject": [{ "name": "app", "digest": { "sha256": "..." } }],
"predicateType": "https://slsa.dev/provenance/v1",
"predicate": { }
}
Read it top down. The statement says: about these bytes (subject), here is a claim of this kind (predicateType), and here is the claim (predicate). A signature wrapped around the whole thing makes it an attestation a verifier can trust to the extent it trusts the signer.
Quick reference table
| Term | One line | Where you see it |
|---|---|---|
| Provenance | How the artifact was built | A file attached to a release or image |
| Attestation | A signed claim about an artifact | Stored beside the artifact |
| Subject | The artifact, named by digest | The subject array |
| Predicate | The claim being made | The predicate object |
| Builder | The platform that ran the build | A builder identity in provenance |
Common confusions
A signature on an artifact says someone with a key signed it. An attestation says something specific about how it came to be. They answer different questions, and a buyer who asks for "signing" may actually want provenance.
Provenance is also not a vulnerability report. It tells you where bytes came from, not whether the code is safe.
Where to go next
If you are new to this, read one real provenance file with these four words in mind. Find the subject digest, confirm it matches the artifact in front of you, then read the predicate for the builder and the source. Safeguard builds SBOMs and runs dependency scanning that you can pair with provenance records, and the free scan at https://gold.safeguard.sh/scan is a quick way to see what a component inventory looks like.
Quick check
Is provenance the same as an SBOM?
No. Provenance records how an artifact was built. An SBOM lists what is inside it. Both can be carried as attestations.
Why are subjects matched by digest and not by name?
A digest identifies exact bytes. A name or tag can point at different content over time.
Sources
- in-toto attestation Statement spec
- SLSA v1.1 provenance (page marked retired, v1.2 is current)
Last reviewed: 19 October 2026.
