in-toto is an open framework for securing the integrity of a software supply chain end to end — it lets a project define exactly which steps must happen, who is allowed to perform each one, and which artifacts should flow between them, then cryptographically verify that the shipped product was produced by following that plan. Rather than trusting any single build tool or signature, in-toto verifies the whole chain of custody from source to release. Created at NYU's Secure Systems Lab and now a graduated project of the Cloud Native Computing Foundation (CNCF), in-toto also provides the attestation format that underpins SLSA and modern signing tooling.
Why It Matters
Signing a final artifact proves who released it, but it says nothing about everything that happened before release — cloning source, running tests, building, packaging. Attackers exploit exactly those intermediate steps: insert a step that was never supposed to run, skip a security check, or have an unauthorized party perform a step. A single signature at the end cannot detect any of that.
in-toto raises the bar from "the last step was signed" to "every step was performed as planned, by the right party, with the expected inputs and outputs." That holistic view is what catches an injected build stage or a tampered artifact passed between steps. As supply chains grow more automated and more distributed across CI systems and third parties, being able to define and enforce the shape of the entire pipeline — not just its endpoints — becomes essential, which is why in-toto's attestation format has become an industry building block.
How It Works
in-toto revolves around a small set of concepts that together turn a pipeline into something verifiable:
- The layout is the root of trust. Signed by the project owner, it declares the ordered steps of the supply chain, which artifacts (materials consumed and products created) each step expects, and which keys are authorized to perform each step.
- Functionaries are the actors — humans or automation — authorized to carry out a given step. Each functionary holds a key the layout recognizes.
- Link metadata is the evidence. As each step runs, its functionary produces a signed link record capturing the materials it consumed and the products it created.
- Verification happens at the end: an inspector checks that every step defined in the layout actually ran, was performed by an authorized functionary, and that the products of one step match the materials of the next — so nothing was skipped, inserted, or swapped between steps.
Separately, the in-toto Attestation Framework standardizes how a signed statement about an artifact is structured (a subject naming the artifact and a predicate holding the claim). This is the format SLSA provenance uses and that Sigstore-based tooling produces, which is why in-toto shows up throughout the supply chain toolchain even in pipelines that do not use full layout-based verification.
Key Parts of in-toto
| Concept | Role | Analogy |
|---|---|---|
| Layout | Signed definition of the whole pipeline and its rules | The blueprint and permit |
| Functionary | An authorized actor performing a step | A named, badged worker |
| Link metadata | Signed record of what a step consumed and produced | A signed delivery receipt |
| Verification | Checks the actual chain against the layout | The final inspection |
| Attestation | Standardized signed claim about an artifact | A notarized statement |
Best Practices
- Keep the layout key tightly controlled. The layout is the root of trust, so its signing key deserves the strongest protection — ideally hardware-backed and held by a small set of owners.
- Automate link generation in CI. Have each pipeline step emit its link metadata automatically, so the evidence reflects what really ran rather than what someone remembered to record.
- Verify products match materials across steps. The strongest guarantee in-toto offers is that an artifact leaving one step is the same one entering the next; enforce that chaining, not just per-step signatures.
- Scope functionary keys narrowly. Give each step its own authorized key rather than one shared credential, so a compromise is contained to a single step.
- Adopt the attestation format even if you skip full layouts. Emitting in-toto attestations for provenance and SBOMs gives you interoperability with SLSA and Sigstore tooling with far less setup than a complete layout.
How Safeguard Helps
Safeguard speaks in-toto natively because it is the lingua franca of supply chain metadata. The Safeguard CLI produces and verifies in-toto attestations in your pipeline — the provenance and SBOM predicates that SLSA and Sigstore build on — so generating standards-compliant, signed step evidence is a build-time option rather than a research project. Those attestations are aggregated and correlated in SBOM Studio, where the claims about an artifact live next to its component inventory.
When step evidence is missing, unsigned, or inconsistent — a product that does not match the materials it should have been built from, for instance — Griffin AI flags it and ranks it against your vulnerability and reachability data, so chain-of-custody gaps on critical artifacts get surfaced and prioritized. For related concepts, see the concepts library.
Create a free account to start producing and verifying in-toto attestations, or read the documentation to see how it fits your pipeline.
Frequently Asked Questions
What is the difference between in-toto and SLSA? in-toto is a framework and a data format for verifying supply chain steps and expressing attestations, while SLSA is a set of graded requirements for build integrity. SLSA is built on top of in-toto: SLSA provenance is expressed as an in-toto attestation. Think of in-toto as the mechanism and SLSA as the policy that uses it.
Do I have to define a full layout to benefit from in-toto? No. Many teams adopt the in-toto Attestation Framework — emitting signed provenance and SBOM attestations — without authoring a complete layout with functionaries and inspections. That lighter adoption still gives interoperability with SLSA and Sigstore tooling. Full layout-based verification is a stronger, more involved guarantee you can add later.
How does in-toto relate to Sigstore? They are complementary. in-toto defines the structure of an attestation, and Sigstore provides a convenient way to sign it using keyless, identity-based signing. In modern pipelines you commonly produce an in-toto attestation and sign it through Sigstore, then record the signing event in a transparency log.
Is in-toto only for open-source projects? No. in-toto was created in academia and is widely used in open source, but its guarantees apply equally to private, enterprise pipelines. Any organization that wants to verify no build step was skipped, added, or performed by an unauthorized party can use it, and the attestation format is common in commercial supply chain tooling.