Pick the predicate type by the question you need answered. Use SLSA Provenance for how an artifact was built, SPDX or CycloneDX for what is inside it, a vulnerability scan predicate for known issues, a test result predicate for what was tested, and a verification summary for a policy decision.
What a predicate type is
An in-toto Statement binds a claim to a subject artifact and names the claim type with a predicate type URI. The in-toto spec says the predicate carries arbitrary metadata about the subject with a type specific schema. Consumers must ignore unrecognised fields unless the predicate spec says otherwise.
Because the type tells a verifier how to read the predicate, always check the type string before trusting what is inside.
The vetted predicates
The in-toto repository lists these vetted predicates:
| Predicate | Purpose |
|---|---|
| SLSA Provenance | How artifacts were produced |
| SLSA Verification Summary (VSA) | A SLSA verification decision about an artifact |
| SPDX2 and SPDX3 | SPDX bill of materials |
| CycloneDX | Bill of materials |
| VULNS | Sharing vulnerability scan results |
| Test Result | Results of any test type |
| Simple Verification Result | Evidence the artifact was checked against policies |
| SCAI Report | Evidence based claims about artifact attributes or behaviour |
| Release | An artifact included in a release version |
| Runtime Traces | Runtime traces of supply chain operations |
| Link | Supports migration from in-toto 0.9 |
| Reference | Documents relevant to a resource |
Matching question to type
| Question from a buyer or auditor | Predicate to attach |
|---|---|
| Where and how was this built? | SLSA Provenance |
| What components are inside? | SPDX or CycloneDX |
| Were known vulnerabilities checked before release? | VULNS |
| Did the release pass its tests? | Test Result |
| Did this meet our policy? | VSA or Simple Verification Result |
| Which version is this artifact part of? | Release |
Practical advice
- Start with provenance and an SBOM. Those two answer the most common buyer requests.
- Add scan or test attestations only if a consumer will act on them.
- Make sure each attestation names the same subject digest, otherwise they describe different things.
- Keep the type URIs in a short allow list on the verifier side.
- Sign everything the same way so verification stays uniform.
A word of caution
A scan attestation is a snapshot. New advisories appear after release, so a clean scan at build time does not mean a clean result next month. Pair a point in time attestation with ongoing monitoring.
Where Safeguard fits
Safeguard produces and works with SBOMs and does dependency scanning, and its continuous scanning keeps results fresh after release. See the demo below for an inventory view.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the dependency inventory and note how components are listed, the same content an SBOM predicate would carry.
Quick check
Can one artifact have several attestations?
Yes. A Bundle groups multiple attestations, and each one has its own predicate type, all pointing at the same subject digest.
Is a vulnerability scan attestation proof of safety?
No. It records results at one moment. New advisories can change the answer later.
Sources
Last reviewed: 19 October 2026.
