Some text here

Codifying the SDLC with in-toto

in-toto helps ensure product integrity by making transparent what steps were performed, by whom, and in what order.

Michael Lieberman

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:

  • Owner – This is the identity associated with a key that signs the in-toto layout and who end users would validate against to ensure that the layout is valid and comes from an approved party.
  • Functionaries – Functionaries are the name of the approved identities that are allowed to perform commands to satisfy an in-toto layout. These functionaries are identified by their public keys.
  • Expected Commands – These are the commands the layout expects an approved functionary to run for a step in the layout.
  • Expected Materials – These are the rules around inputs used by an expected command in a step in the layout.
  • Expected Products – These are the rules around outputs that are generated by an expected command in a step in the layout.
  • Inspection – These are additional steps the end user consuming the in-toto output can take to verify elements of the supply chain.

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.

Like what you read? Share it with others.

Other blog posts 

The latest industry news, interviews, technologies, and resources.

View all posts

Previous

No older posts

Next

No newer posts

Want to learn more about Kusari?

Schedule a Demo
By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.