in-toto, explained: supply chain layouts, links and attestations

in-toto is a framework for securing the integrity of a software supply chain, now run as a CNCF graduated project. Its own site states the goal is "to ensure the integrity of a software product from initiation to end-user installation," by making transparent "what steps were performed, by whom and in what order" — rather than asking a consumer to trust a final binary or package on faith, in-toto gives them a way to check the recorded history of how it was built. The project traces back to academic research: it "is led by Prof. Santiago Torres-Arias at Purdue University," with contributors from "the Secure Systems Lab at NYU and the NJIT Cybersecurity Research Center," and was formally published as "in-toto: Providing farm-to-table guarantees for bits and bytes" by Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola and Justin Cappos at the 28th USENIX Security Symposium (USENIX Security '19), August 2019. Development was supported by the US National Science Foundation, DARPA, and the Air Force Research Laboratory.

Layout and link metadata — the original model

in-toto's original specification (documented in the in-toto/docs repository, version 1.0.0) is built on two metadata types:

Metadata type	Produced by	What it records
Layout	The project owner, signed in advance	Expiration date; authorized public keys per functionary (a person or automated script allowed to perform a step); the ordered list of steps, each with expected materials/products and a threshold of required signoffs; client-side inspections to run at verification time
Link	Each functionary, signed after performing their step	The step name and command executed; materials (input artifacts) and products (output artifacts) as cryptographic hashes; byproducts (stdout, stderr, return value); environment details (variables, working directory)

Verification checks the chain as a whole: the layout's own signature and expiration are checked first, then each required step must have a corresponding, correctly signed link from an authorized functionary, and the artifact-rule chain must hold — a step's recorded products must match the next step's recorded materials, so nothing was substituted in between. The specification is explicit that superficial fields like the suggested command in a layout step should only raise a warning on mismatch, since "this field can easily be forged" and cannot itself be trusted as a security control; the cryptographic material/product chain is what carries the actual guarantee.

The in-toto Attestation Framework — the newer, more general model

Alongside the original layout/link model, the project also maintains the in-toto Attestation Framework, a more general specification for "generating verifiable claims about any aspect of how a piece of software is produced." It is organized in two layers:

• Statement — the core layer, which "defines the format for in-toto attestations and the metadata they contain," binding a claim to a specific artifact (the subject).
• Predicate — a set of "metadata formats vetted by [the project's] maintainers to cover a number of common use cases," layered on top of the Statement to describe a specific kind of claim (for example, build provenance).

This framework is what most supply-chain tooling built after roughly 2021 actually produces and consumes, rather than raw layout/link files, and its specification currently sits at spec/v1 in the in-toto/attestation repository — the project describes it as "still under development," with ongoing work on tooling for better integration and adoption.

Where SLSA fits on top

SLSA (see our SLSA supply chain levels guide) defines what a provenance claim about a build should contain and how strong the guarantees behind it are. It does not reinvent how that claim is packaged: SLSA's own attestation-model documentation recommends in-toto attestations for the Statement layer of a software attestation, explicitly citing the in-toto/attestation specification. In practice this means a build pipeline producing SLSA provenance is, at the wire-format level, producing an in-toto Statement with a SLSA-defined Predicate — the two specifications are complementary layers of the same stack rather than competing standards.

A workable starting point

1. Decide which in-toto model fits your pipeline. A fixed, auditable build process with distinct human/automated actors can use the original layout/link model directly; most modern CI-driven pipelines instead produce in-toto attestations (Statement + a chosen Predicate, such as SLSA provenance) as part of the build.
2. Start by generating, then move to signing and verifying. An unsigned or self-signed attestation still establishes the schema and habit; the integrity guarantee only becomes real once a verifier outside the build job checks the signature and artifact chain.
3. Treat in-toto as the envelope, SLSA as the content. If the goal is build provenance specifically, implement SLSA's requirements (see our SLSA guide) and let the in-toto Attestation Framework define how that provenance is packaged and verified.
4. Publish and keep attestations alongside the artifact, not in a separate system that can drift out of sync — an attestation only protects a consumer who can actually fetch and check it against the artifact they received.

SoftWSP can help a firmware or device build pipeline produce and verify in-toto/SLSA-style provenance as part of a secure-development-lifecycle assessment: see device firmware security.

This guide summarises public in-toto, USENIX and SLSA documentation as fetched in October 2026; it does not constitute legal or compliance advice.