in-toto
What is in-toto?
in-totoAn open framework that cryptographically attests to every step of a software supply chain so that consumers can verify the artifact was built and handled exactly as the project owner intended.
in-toto, hosted by CNCF, models a software supply chain as a sequence of steps (e.g. clone, test, build, sign, publish) with declared inputs, outputs, and authorized actors. Each step produces a signed link metadata file recording materials and products; an overall layout authored by the project owner defines who must perform each step and how the artifacts flow between them. A verifier can take a final artifact and the corresponding attestations and check that the chain matches the policy. in-toto attestations are used to express SLSA provenance, vulnerability scan results, test pass evidence, and other signed predicates, often distributed via OCI registries and signed with Sigstore. It is a foundational technology for SLSA-aligned, verifiable supply chains.
● Examples
- 01
Build pipeline producing SLSA provenance as an in-toto attestation signed with Cosign.
- 02
Verifier checking that container images include in-toto vulnerability scan attestations before deploy.
● Frequently asked questions
What is in-toto?
An open framework that cryptographically attests to every step of a software supply chain so that consumers can verify the artifact was built and handled exactly as the project owner intended. It belongs to the Application Security category of cybersecurity.
What does in-toto mean?
An open framework that cryptographically attests to every step of a software supply chain so that consumers can verify the artifact was built and handled exactly as the project owner intended.
How does in-toto work?
in-toto, hosted by CNCF, models a software supply chain as a sequence of steps (e.g. clone, test, build, sign, publish) with declared inputs, outputs, and authorized actors. Each step produces a signed link metadata file recording materials and products; an overall layout authored by the project owner defines who must perform each step and how the artifacts flow between them. A verifier can take a final artifact and the corresponding attestations and check that the chain matches the policy. in-toto attestations are used to express SLSA provenance, vulnerability scan results, test pass evidence, and other signed predicates, often distributed via OCI registries and signed with Sigstore. It is a foundational technology for SLSA-aligned, verifiable supply chains.
How do you defend against in-toto?
Defences for in-toto typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for in-toto?
Common alternative names include: in-toto, in-toto attestation.
● Related terms
- appsec№ 1053
SLSA Framework
Supply-chain Levels for Software Artifacts: a tiered set of requirements published by OpenSSF that progressively hardens how software is built, signed, and verified against supply-chain tampering.
- appsec№ 870
Provenance Attestation
A signed, machine-verifiable statement that describes how a software artifact was produced - including source, build system, parameters, and dependencies - so consumers can trust its origin.
- appsec№ 1044
Sigstore
An open-source Linux Foundation project that makes signing, verifying, and protecting software artifacts easy by combining short-lived keys, OIDC identities, and a transparency log.
- appsec№ 226
Cosign
An open-source CLI from the Sigstore project for signing, verifying, and attesting to OCI artifacts and other software using either keyed or keyless workflows.
- appsec№ 1069
Software Supply Chain Security
The discipline of protecting every link of the software production chain - source, dependencies, build, signing, distribution, and deployment - against tampering, malicious code, and integrity loss.
- appsec№ 1068
Software Bill of Materials (SBOM)
A formal, machine-readable inventory of the components, libraries, and dependencies that make up a piece of software, along with their versions and relationships.