in-toto helps ensure product integrity by making transparent what steps were performed, by whom, and in what order.
April 17, 2025
This post is an excerpt from Securing the Software Supply Chain by Michael Lieberman and Brandon Lum. Download the full e-book for free from Kusari.
in-toto is a Cloud Native Computing Foundation project to define the steps and the expected outcomes in the supply chain. in-toto layouts effectively describe the workflow that must be followed to build, test, and deploy software. It specifies what actors — called “functionaries” in in-toto — are allowed to perform what actions against what inputs. This gives the hypothetical Secure Bank a powerful set of rules by which they enforce that the core steps of the SDLC — like writing code, building software, and publishing packages — happens only on approved systems.
There are multiple implementations of the in-toto specification with varying feature sets and compliance with different parts of the spec. Keep this in mind when choosing which one to use. As of this writing, the most popular are in-toto Python and in-toto Golang. Both can be used for generating the metadata that describes the workflow you want to secure — called “layouts” — as well as running the steps in those layouts.
The key elements of an in-toto layout are:
With in-toto, the Owner would generate the layout, sign it, and distribute it. The Functionaries would perform the actions using in-toto tooling that generates metadata about input files, what commands were run, and output files produced. This is called “link metadata.” At the end when a user is consuming the final artifact generated as part of a supply chain flow, they would run commands to both validate that the link metadata conforms to the layout as well as run any validation commands that can be used as well.
This trivial example should show how our hypothetical Secure Bank could then turn this into a much more realistic supply chain flow describing the process from source code, to build, to packaging, and finally to deployment. The bank could then set up functionaries for all the systems and actors involved: from the developers writing the source code, to the individual build steps pulling down the code, compiling it, testing it, scanning it, packaging it, and publishing it to the artifact repo. Finally, the deployment processes and systems could verify that the artifact has gone through all the right steps, in the right order, and performed by the right systems and actors.
Using an in-toto layout and verifying it mitigates various classes of attacks. Using in-toto and TUF (described in a previous post) helps secure the supply chain. Secure Bank might use in-toto but be worried about how it can distribute the layouts and changes to the layouts securely. What happens if the layout is compromised? This is where TUF can help. TUF sets up a system for securely providing updates to the layouts and ensuring downstream consumers only use TUF-validated layouts.
No older posts
No newer posts