In-Toto Attestation

A cryptographically signed statement representing a single, atomic step in the supply chain. Each link records:

• Materials: The cryptographic hashes of all input artifacts (source code, dependencies) before the step executes.
• Products: The cryptographic hashes of all output artifacts (binaries, container images) after the step executes.
• Byproducts: Contextual metadata like stdout, stderr, and command return codes.
• Environment: The OS, compiler version, and other platform details. Links are the immutable evidence that proves what happened, how it happened, and where it happened.

The core cryptographic operation that validates the entire supply chain. The in-toto verifier:

1. Loads the Layout: Parses the root policy to understand the expected chain.
2. Collects Links: Gathers all signed link metadata for the artifact in question.
3. Validates Signatures: Checks that each link was signed by an authorized functionary key.
4. Walks the Chain: For each step, cryptographically verifies that the recorded materials match the products of the preceding step, ensuring no artifact was tampered with or replaced between stages. This process produces a single, binary pass/fail result, guaranteeing a continuous, unbroken chain of custody.

An evolution of the original link format, ITE adopts a more flexible, predicate-based attestation model aligned with the SLSA specification. Instead of a single link type, ITE defines:

• Envelope: A standard wrapper (DSSE) containing the payload, payload type, and signatures.
• Subject: The artifact the attestation is about (e.g., a container image digest).
• Predicate: A structured, typed statement about the subject (e.g., slsa.dev/provenance/v1, spdx.dev/Document). This separation allows the same artifact to carry multiple, independent attestations—one for its build provenance, another for its SBOM, and another for a vulnerability scan—all in a unified, verifiable format.

The most common implementation of in-toto attestations is generating SLSA Provenance for build pipelines. A build service (like GitHub Actions or Google Cloud Build) generates a signed attestation that declares:

• Builder ID: The trusted, isolated platform that performed the build.
• Source Repository: The exact git commit and origin.
• Build Recipe: The hermetic instructions used to compile the artifact.
• Output Artifacts: The hashes of the resulting software packages. A policy engine can then verify this attestation before deployment, ensuring that only artifacts built from trusted source code on a trusted platform are allowed into production.

A cryptographic data structure using a tree of hashes that enables efficient, secure verification of data block integrity within large datasets. In-toto uses Merkle trees in its link metadata chaining: each step's hash is combined with the previous step's hash, forming a tamper-evident chain. This allows verifiers to check a single root hash rather than every intermediate artifact, providing O(log n) verification efficiency while guaranteeing that no link in the supply chain has been retroactively altered.

The process of cryptographically binding a document's hash to a specific point in time via a Time Stamping Authority (TSA) per RFC 3161. In-toto link metadata includes timestamps, but without trusted timestamping, a malicious actor could backdate attestations. Integrating a TSA ensures that each step's attestation is provably created before the next step began, closing a critical temporal gap in the provenance chain and preventing post-compromise retroactive forgery of the entire supply chain history.