The CNCF Technical Oversight Committee (TOC) has accepted the in-toto project as a CNCF incubating project. The in-toto project aims to cryptographically protect the entire software build and delivery process - the "supply chain" - from malicious actors.
The in-toto project is "a framework that cryptographically ensures the integrity of the software supply chain". The framework's core architecture is based on three design principles - resilience to being compromised, ensuring end-to-end presence in the chain, and being expressive enough to be adopted anywhere. Since joining the CNCF sandbox in 2019, in-toto has released version 1.0 in 2020 and focused on achieving stability, support for SPIFFE, more expressive evidence collection, and implementations in different languages. It has also seen adoption in production in various organizations.
There are multiple steps (which in-toto refers to as the supply chain) in the build and release process for any software artifact. If an attacker gains access to any of the steps they can control the output of the step. Instead of securing the steps in the chain, in-toto's goal is to cryptographically verify the chain itself. This is noteworthy as each step can involve a different piece of infrastructure or software with different attack surfaces. According to a recent report, software supply chain attacks tripled in 2021 compared to 2020.
The CNCF's Security Technical Advisory Group (TAG) laid out the four principles to create a secure software supply chain in a paper last year. These are establishing and verifying trust at every step, automation, clarity of scope in each step in the chain and of the role of each actor, and mutual authentication. As the TAG notes in their paper, "in-toto includes a verification workflow that analyzes the links to ensure that they meet the constraints set in the layout".
Santiago Torres-Arias - one of the original authors of in-toto - in his USENIX Security 2019 talk elaborated on the design principles behind the in-toto project. The first principle - resilience to being compromised - is achieved by separation of roles and keeping revocation and key rotation as first class primitives. The second design principle of in-toto is to be an all-encompassing tool that covers the entire pipeline from the moment the first line of code is committed, to the time that the end user installs or uses the software. This is achieved by being as tool-agnostic as possible, and thus aiming for seamless integration with the pipeline. The third design principle is to be expressive enough to be adopted everywhere.
The architecture of in-toto is based on being able to verifiably define both the software supply chain steps and the authorized actors who can make it happen. It provides a tight binding of the artifacts as they flow through the chain. in-toto uses a DSL that has "layouts" which defines the actors, the public keys, and "artifact rules" which describe how the artifacts relate to the steps in the supply chain. The entire workflow is usually signed by a project owner - who can be a security team or an individual, depending on the project’s governance. in-toto assumes that an attacker can compromise core infra like source code repos, CI/CD systems, container orchestrators, inter-server communication channels and developer keys. It provides for graceful degradation of security in such circumstances.
The in-toto project has been adopted by many organizations in production including Datadog, kubesec, SolarWinds and rebuilderd. The project is hosted on GitHub.