in-toto

The layout is a signed policy document that defines the required steps, functionaries, and artifact rules for a supply chain. It specifies:

• Steps: Individual actions like cloning a repo, running tests, or building a binary
• Inspections: Independent verification steps run by the verifier
• Thresholds: Minimum number of functionaries required to authorize a step

The layout acts as a blueprint, and the final verification checks that all recorded link metadata conforms to this policy.

A link is a cryptographically signed statement that records the materials, products, and environment of a single supply chain step. Each link captures:

• Materials: The artifacts consumed (e.g., source files, dependencies)
• Products: The artifacts produced (e.g., compiled binaries, container images)
• Byproducts: Stdout, stderr, and return values
• Environment: Hostname, command, and other contextual data

Links are generated by functionaries—the entities authorized to perform steps—and are verified against the layout during final product verification.

The in-toto verification workflow cryptographically validates the entire supply chain:

1. The verifier fetches the signed layout and all link metadata
2. Each link's signature is validated against the functionary's public key
3. Artifact hashes in materials and products are cross-checked across steps
4. The verifier confirms the chain matches the layout's rules

This ensures that if any step is compromised or skipped, the final verification fails. The process provides non-repudiation—a functionary cannot deny performing a step.

in-toto has evolved beyond its original link format to support in-toto attestations, standardized in ITE-6. These attestations use a JSON-based schema with:

• A subject identifying the artifact being described
• A predicate containing the claim (e.g., SLSA provenance, vulnerability scan results)
• A predicate type URI for schema discovery

This aligns in-toto with the broader Sigstore and SLSA ecosystems, enabling keyless signing via Fulcio and transparency logging via Rekor.

A typical in-toto layout for a container build pipeline might define:

• Step: clone — Functionary: CI system, Expected product: source code hash
• Step: build — Functionary: Build server, Expected materials: source code hash, Expected product: binary hash
• Step: package — Functionary: Packaging tool, Expected materials: binary hash, Expected product: container image digest
• Inspection: lint — Run by verifier, checks code quality independently

Each step produces a signed link, and the final verification confirms the artifact digests chain correctly from clone to container.

in-toto defends against specific threat vectors:

• Compromised build server: An attacker modifying binaries is detected because the product hash won't match the expected value in the layout
• Insider threat: A malicious functionary cannot repudiate their actions; their signature is cryptographically bound to the link
• Dependency confusion: Materials hashes capture exact dependency versions, preventing substitution attacks
• Skipped steps: The layout enforces that all required steps exist and are signed by authorized functionaries