← Back to research
•·5 min read·company

in-toto

in-toto — CNCF graduated (April 2025) framework for supply chain attestation. Its attestation format underpins SLSA provenance and GitHub Artifact Attestations. Born at NYU under Justin Cappos. Witness and Archivista reduce adoption friction; gittuf extends it to Git.

https://in-toto.io ↗
securityopen-sourcesupply-chaincncfattestation

Key takeaways

  • CNCF graduated project (April 23, 2025) for supply chain attestation — cryptographically verifies each step in the supply chain was performed as intended, by authorized parties
  • Two layers: the classic layout/link model (define expected steps and functionaries, capture link metadata, verify the match) and the in-toto Attestation Framework (statement + predicate), which is the format beneath SLSA provenance and GitHub Artifact Attestations
  • Python reference implementation plus in-toto-golang; attestation bindings in Go, Python, Rust, and Java. Witness (attestation collector) and Archivista (attestation store) are the friction-reducing tooling
  • Production use at Datadog (since 2019), SolarWinds (post-SUNBURST pipeline redesign), and Autodesk; integrated into the SLSA and OpenVEX standards. gittuf (OpenSSF incubating) applies in-toto attestations to Git itself

FAQ

What is in-toto?

A CNCF graduated framework for supply chain attestation, developed at NYU Tandon under Justin Cappos. It defines expected build steps and authorized parties, captures cryptographic evidence of what actually happened, and verifies the two match. Its attestation format is the foundation for SLSA provenance.

How does in-toto relate to SLSA and GitHub attestations?

SLSA provenance is defined as an in-toto attestation predicate, and GitHub Artifact Attestations emit signed statements in the in-toto attestation format. Most ecosystem adoption uses this lightweight statement/predicate layer rather than in-toto's full layout-based end-to-end verification.

Overview

in-toto is a CNCF graduated framework for supply chain attestation. It cryptographically verifies that each step in a software supply chain was performed as intended, by authorized parties, producing expected outputs.

The classic model uses layouts (what should happen and who is authorized to do it) and link metadata (signed evidence of what actually happened); verification checks that execution matched the layout. Layered on top is the in-toto Attestation Framework — a generic signed statement + predicate format — which is what the broader ecosystem actually standardized on: SLSA provenance is an in-toto predicate type, and GitHub Artifact Attestations emit in-toto-format statements.

The project grew out of NYU Tandon's Secure Systems Lab, created by then-student Santiago Torres-Arias under Justin Cappos with NJIT collaborators, and funded in part by NSF, DARPA, and the Air Force Research Laboratory. It entered the CNCF Sandbox in 2019, incubation in March 2022, shipped its 1.0 specification in June 2023, and graduated on April 23, 2025.

Implementations: the Python reference implementation (~1,000 GitHub stars as of June 2026, last pushed June 2026), in-toto-golang, and attestation-framework bindings in Go, Python, Rust, and Java. Witness (attestation collector for CI steps) and Archivista (attestation store) are the in-toto sub-projects that make it deployable without hand-writing layouts.

What's New (as of June 2026)

  • CNCF graduation (April 23, 2025) — in-toto reached the CNCF's highest maturity tier, citing production adoption at SolarWinds (which redesigned its build pipelines around in-toto after SUNBURST), Datadog (in production since 2019), and Autodesk, plus integration into the SLSA and OpenVEX standards.
  • Reference implementation v3.1.0 (May 2026) — the Python implementation cut its first release since v3.0.0 (May 2024); the repo remains actively maintained with pushes in June 2026.
  • GitHub Artifact Attestations going default — GitHub's attestations, which use the in-toto statement format with SLSA provenance predicates, achieve SLSA Build L2 out of the box and have been moving from opt-in toward default for public repositories through 2025–2026, with org-level policies and a Kubernetes admission controller added.
  • gittuf momentum — gittuf, an OpenSSF incubating project from the same research lineage, records signed Git reference-state logs and uses in-toto attestations for repository policy, with planned SLSA source-track integration. It extends in-toto thinking from build pipelines to the source layer.

Pricing

Free, open source (Apache 2.0 libraries and tools) under CNCF/Linux Foundation governance. There is no paid tier from the project itself; commercial supply-chain products (e.g. from TestifySec, which originated Witness and Archivista before donating them to in-toto) build on the same primitives, and GitHub Artifact Attestations is a hosted application of the format bundled into GitHub plans.

AI and Agent Angle

The attestation framework is predicate-agnostic: any claim about any artifact can be expressed as a signed in-toto statement, which makes it the natural envelope for attesting agent-produced code and AI build artifacts — the same SLSA provenance machinery applies whether a human or an agent triggered the build. gittuf's signed reference-state log points at the source-side complement: verifiable policy over who (or what) may advance a branch. There is no agent-specific in-toto product; the positioning is that supply chain attestation covers machine actors by construction.

Cautions

  • Adoption is mostly the format, not the framework — SLSA, GitHub, and Sigstore adopted the lightweight statement/predicate layer. Full layout-based end-to-end verification — in-toto's original promise — requires defining supply chain layouts and functionaries upfront and remains comparatively rare in the wild.
  • Setup complexity — even graduation-announcement adopters frame Witness and Archivista as what "reduced developer friction so significantly," an implicit acknowledgment that raw in-toto is hard to roll out.
  • Modest tool-level community — the reference implementation sits near 1,000 stars with a two-year gap between minor releases (v3.0.0 May 2024 → v3.1.0 May 2026); the project's influence runs through specs and integrations more than through its own tooling.

Competitive Position

Strengths: CNCF graduated (highest maturity). The attestation format is the lingua franca of supply chain metadata — beneath SLSA provenance, GitHub Artifact Attestations, and OpenVEX. Multi-language implementations. Production-proven at Datadog, SolarWinds, and Autodesk. Strong academic grounding (NYU, Cappos — same lab as TUF).

Weaknesses: Complex to deploy end-to-end; layouts and functionaries must be defined upfront. Framework, not a turnkey product — Witness/Archivista or a vendor are effectively required. The widely adopted piece is the metadata format, not full pipeline verification.

Bottom Line

in-toto won as a standard more than as a tool. Its attestation format quietly underpins how the industry expresses build provenance — SLSA and GitHub attestations are in-toto statements — while full layout-based verification remains a niche practiced by sophisticated adopters like SolarWinds and Datadog.

Recommended for: Teams that need verifiable end-to-end pipeline integrity (especially post-incident hardening); anyone producing or consuming SLSA provenance; platform teams standardizing attestation storage with Witness/Archivista.

Not recommended for: Teams wanting a turnkey supply-chain product — adopt GitHub Artifact Attestations or a commercial wrapper instead and you'll still be using in-toto underneath.

Outlook: Graduation settled the governance question; the open one is whether full layout verification ever goes mainstream or whether in-toto's destiny is to be the invisible format layer, with gittuf carrying the model into source control.

Research by Ry Walker Research • methodology

Sources

Share on XShare on LinkedIn