in-toto attestations

Subject, predicate, and composing evidence.

in-toto is the open framework beneath modern supply-chain evidence — the standard way to make signed, machine-checkable claims about artifacts. SLSA provenance, SBOMs, and test results are all expressed as in-toto attestations, so understanding its shape lets you compose and verify any of them.

Subject and predicate

An in-toto attestation is a signed statement with two parts: a subject, which identifies the artifact by cryptographic digest, and a predicate, which is the actual claim about it. The predicate type says what kind of claim it is — SLSA provenance, a CycloneDX/SPDX SBOM, a test-result attestation, a VSA — and its body carries the details. Because the subject is a digest, the claim is welded to exactly those bytes; because the whole statement is signed, it is tamper-evident and attributable. This uniform shape is what lets one verifier reason about many kinds of evidence.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "api", "digest": { "sha256": "9f2c..." } }   // WHICH artifact
  ],
  "predicateType": "https://slsa.dev/provenance/v1",        // WHAT kind of claim
  "predicate": { /* builder, source, materials ... */ }     // the claim itself
}
# Swap predicateType to https://cyclonedx.org/... for an SBOM attestation.
# The signed envelope (DSSE) around this makes it tamper-evident.

Composing evidence into policy

Because every claim shares the same structure, an artifact can carry several attestations — provenance, an SBOM, a scan result, a VSA — and a verifier can require a combination before trusting it: "built by our pipeline AND has an SBOM AND passed scanning". A Verification Summary Attestation lets one authority record that it checked an artifact against policy, so downstream consumers can trust that decision without re-running every check. This composability is what turns scattered evidence into an enforceable, layered trust decision at the gate.