Get fresh insights, pro tips, and thought starters–only the best of posts for you.
The in-toto framework, commonly written as in-toto, is an open framework for securing software supply chains by recording and verifying what happened at each stage of software delivery.
It helps answer critical questions: Who built this software? Which steps were performed? Were the expected files used? Was anything changed outside the approved process?
in-toto treats a software supply chain as a series of defined steps, such as coding, reviewing, building, testing, packaging and deployment. A project owner defines the expected workflow in a layout. Each authorized person or system that performs a step creates signed metadata, often called link metadata or an attestation.
During verification, in-toto checks whether the final artifact matches the approved process. If a required step is missing, performed by the wrong identity or produces unexpected materials, verification can fail before the software is trusted.
| Element | Purpose |
|---|---|
| Layout | Defines the expected supply chain steps and authorized identities. |
| Link metadata | Records evidence about a completed step, including inputs, outputs and commands. |
| Attestation | Provides a signed claim about how an artifact was produced or handled. |
| Verification | Confirms that the delivered software follows the declared process. |
Modern applications depend on CI/CD pipelines, APIs, open-source packages, containers and third-party build tools. A compromise in any of these stages can introduce malicious code without changing the visible source repository.
The in toto framework reduces this risk by making the build and release process evidence-based. Instead of assuming that software is trustworthy because it came from a known pipeline, teams can verify signed proof of each important action.
This is especially relevant for organizations adopting SBOMs, SLSA provenance and stronger software artifact controls. in-toto does not replace secure development practices, but it gives security and platform teams a common way to validate supply chain integrity.
Enterprises use in-toto to strengthen release governance, secure CI/CD pipelines and prove that software artifacts came from approved build processes. It can support compliance conversations because it creates verifiable records rather than informal process claims.
For endpoint and device security teams, this matters because trusted software deployment starts before installation. Platforms such as Hexnode help organizations manage and secure apps on devices, while supply chain frameworks like in-toto help improve confidence in the software before it reaches those endpoints.
Code signing proves that an artifact was signed by a trusted key. in-toto goes further by describing how that artifact was created. In practice, the two controls work well together: code signing protects distribution trust, while in-toto protects process trust.
No. in-toto can be used for open-source, internal and commercial software wherever teams need verifiable supply chain metadata.
Usually no. in-toto works around the software delivery process by recording metadata from build, test and release steps rather than modifying application logic.
SLSA can use in-toto attestations to express provenance, making in-toto a practical format for sharing verifiable build information.