in-toto

Definition

in-toto is an open-source framework for verifying the integrity of a software supply chain by cryptographically recording and attesting to each step in a project's build and release process, from source code checkout through compilation to packaging. It lets a consumer of a software artifact verify that every step defined in a project's supply chain layout was actually performed, in order, by an authorized party, rather than trusting that the process was followed without evidence.

Overview

Software supply chain attacks frequently succeed not by breaking cryptography but by inserting a malicious step somewhere in the build pipeline, such as a compromised build server injecting code between source checkout and the final compiled artifact. in-toto was designed specifically to close that gap by making the entire chain of steps in producing software verifiable, rather than only verifying the final artifact's signature. Mechanically, a project defines a layout describing the expected steps in its supply chain, such as source retrieval, dependency resolution, compilation, and packaging, along with which party is authorized to perform each step and what artifacts each step should produce and consume. As the pipeline runs, each authorized functionary generates a signed link metadata file recording exactly what it did: which command ran, and the cryptographic hashes of the materials it received and the products it output. A verifier can then replay this chain of link metadata against the layout to confirm every step happened, in the correct order, by the correct party, and that the artifact handed from one step to the next was not tampered with in between. in-toto operates at a different layer than artifact-signing tools like Sigstore's Cosign, which attest to a final built artifact's identity, and standards like SLSA, which define levels of supply chain rigor an organization can aim for; in practice in-toto is often used as one of the mechanisms that helps a project meet SLSA provenance requirements, since in-toto attestations can serve as the machine-readable provenance record SLSA calls for. It is complementary to, not a replacement for, source-level static analysis or vulnerability scanning, since it verifies process integrity rather than code correctness. In practice, projects with multi-step, multi-party build pipelines, such as Linux distributions or large open-source foundations, adopt in-toto to give downstream consumers verifiable evidence that a package was built the way the project intended, without requiring blind trust in any single build server. CI/CD systems can be instrumented to automatically generate in-toto link metadata at each pipeline stage, and package managers or deployment tooling can verify that metadata before installing or running an artifact. Adoption requires defining a layout and instrumenting each step of an existing pipeline to produce signed metadata, which is nontrivial engineering work compared to simply signing a final artifact, and the security guarantee is only as strong as the key management protecting each functionary's signing key. For smaller projects with a single trusted build environment, the operational overhead of a full in-toto layout may outweigh the benefit compared to simpler artifact signing alone.

Key Features

• Defines a supply chain layout describing expected steps and authorized parties
• Generates signed link metadata recording materials and products of each step
• Verifies that pipeline steps ran in order by the correct authorized functionary
• Detects tampering introduced between build steps, not just in the final artifact
• Complements SLSA by supplying machine-readable provenance attestations
• Works across heterogeneous, multi-party build pipelines
• Open governance under the Cloud Native Computing Foundation
• Language- and tool-agnostic design usable with existing CI/CD systems

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps