The in-toto framework is one of those technologies that sits underneath a lot of more visible projects, sigstore, SLSA, the various SBOM signing flows, without itself being widely understood. Most engineers who touch it interact with a single predicate type and never see the rest of the design. That is fine for day-to-day use, but understanding the framework as a whole makes the design choices in the projects above it considerably less mysterious.
This walkthrough is aimed at engineers who have run cosign or slsa-verifier and want to understand the layer underneath. We cover the original in-toto layout model, the simpler attestation framework that has largely replaced it for cloud-native use cases, and the predicate ecosystem that has grown around it.
What problem was in-toto built to solve?
in-toto was designed to express the integrity of an entire software supply chain as a verifiable graph rather than as a single signature on a final artifact. The original model defines a layout, a signed policy document authored by a project owner, that lists the steps the supply chain must follow, who is allowed to perform each step, and what materials and products each step expects to consume and produce. Each step in the actual build emits a signed link, and a verifier reconstructs the chain by matching links against the layout.
This model is powerful but heavy. Authoring a layout requires the project owner to enumerate every step in the supply chain ahead of time and to manage signing keys for each functionary. For organizations with stable, well-understood build pipelines it is workable; for organizations whose pipelines change weekly it is not. The layout-based flow is still used in regulated and government-adjacent environments, but most of the cloud-native ecosystem has moved to a lighter pattern.
What is the attestation framework?
The in-toto Attestation Framework is the lighter pattern. Rather than requiring a full pre-declared layout, it defines a common envelope, a DSSE-signed statement, with three fields: a subject identifying what is being attested, a predicate type identifying the schema of the claim, and a predicate carrying the claim itself. The verifier no longer reconstructs a graph; instead, it collects all attestations relevant to a subject and applies policy.
This is the model that SLSA provenance, SBOM attestations, vulnerability scan results, and most modern supply chain evidence use. The framework is deliberately minimal so that the predicate ecosystem can evolve independently of the envelope format. A consumer that understands DSSE can fetch any attestation, verify its signature, and then route it to the right predicate-specific handler based on the type field.
How does DSSE fit in?
DSSE, the Dead Simple Signing Envelope, is the cryptographic substrate. It wraps an arbitrary payload with a payload type identifier and one or more signatures, and it canonicalizes the bytes that get signed using a pre-authentication encoding that prevents the kinds of ambiguity attacks that plagued earlier signature formats. The format is intentionally boring; that is its strength.
In practice, DSSE is what cosign uses under the hood when you run cosign attest. The predicate is in-toto attestation JSON, the envelope is DSSE, and the signing identity is whatever cosign was configured to use, typically a Fulcio short-lived certificate tied to OIDC. Rekor stores the signed envelope, and consumers verify by checking the signature against the certificate, validating the certificate against Fulcio's roots, and replaying the Rekor inclusion proof.
Which predicates matter in 2026?
The predicate ecosystem has consolidated around a small set of types that cover the bulk of supply chain claims. SLSA provenance v1 covers build integrity, with materials and byproducts captured by the build platform. CycloneDX and SPDX SBOMs ride as predicates inside in-toto attestations when they are signed for distribution. VEX statements use OpenVEX as the predicate type. Vulnerability scan results, captured at build time, use a scan-result predicate that is becoming standardized.
The predicate that has gained traction more recently is the policy-evaluation predicate, which captures the output of a policy gate, what policy was evaluated, what the inputs were, what the result was, and signs it. This lets downstream consumers see not just the raw evidence but also the policy decision that was made about it at build time, which is useful for incident review and for compliance audits.
How do you compose attestations into a verification flow?
A typical verification flow in 2026 looks like this. The deployment system fetches the artifact by digest. It then queries the attestation store, registry, TEA endpoint, or sigstore bundle store, for all attestations with that digest as subject. It iterates through them, verifying each DSSE signature against expected identities and validating each predicate against the corresponding schema. Finally, it runs a policy gate that asserts the required predicates are present and that their contents satisfy the policy: SLSA L3 provenance from the expected builder, an SBOM with no critical reachable CVEs, a clean policy-evaluation predicate from the build-time gate.
The thing that makes this flow tractable is that each attestation is independent and self-contained. You can add a new predicate type without redesigning the verifier; you just add a new handler. You can deprecate an old predicate by updating policy; the attestations already in the log remain valid. The framework gets out of the way once you have understood its shape.
How Safeguard Helps
Safeguard treats in-toto attestations as first-class citizens in the supply chain inventory. Every artifact ingested is checked for the full set of expected attestations, with the predicates parsed and indexed: SLSA provenance, SBOM, scan results, policy evaluations. Griffin AI uses attestation metadata to enrich reachability analysis, so a CVE finding can be tied back to the exact build that introduced it. Policy gates compose multiple attestation requirements into a single deployment decision, integrating with cosign and slsa-verifier so you do not have to rebuild verification logic. Our zero-CVE base images ship with the full attestation set, and TPRM scoring tracks supplier attestation coverage as a posture signal over time.