The CNCF Technical Monitoring Committee (CTO) has accepted the in-toto project as a CNCF incubator project. The in-toto project aims to cryptographically protect the entire process of building and delivering software – the “supply chain” – from malicious actors.
the in-toto project is “a framework that cryptographically assures the integrity of the software supply chain”. The core architecture of the framework is based on 3 design principles: resistance to compromise, ensuring end-to-end presence in the chain, and being expressive enough to be adopted anywhere. Since join the CNCF sandbox in 2019, in-toto released version 1.0 in 2020 and focused on stability, SPIFFE support, more expressive evidence collection and implementations in different languages. It has also been adopted in production in various organizations.
There are several stages (known as the supply chain) in the process of building and releasing any software artifact. If an attacker accesses one of the stages, he can control the exit from the stage. Instead of securing chain steps, in-toto’s goal is to cryptographically verify the chain itself. This is notable because each step may involve different infrastructure or software with different attack surfaces. According to a recent report, software supply chain attacks triple in 2021 compared to 2020.
The CNCF Safety Technical Advisory Group (TAG) has defined the 4 principles to create a secure software supply chain in an article last year. It is about establishing and verifying trust at every step, automation, clarity of scope at every step of the chain and the role of each actor, and mutual authentication. Like the TAG Remark in their article, “in-toto includes a verification workflow that analyzes the links to ensure that they respect the constraints defined in the layout”.
Santiago Torres Arias – one of the original authors of in-toto – in his USENIX Security 2019 conference developed on the principles of design behind the in-toto project. The first principle – resistance to compromise – is achieved by separating the roles and keeping key revocation and rotation as first-class primitives. The second design principle of in-toto is to be a global tool that covers the entire pipeline from the moment the first line of code is validated until the moment the end user installs or uses the software. This is achieved by being as tool-independent as possible and thus aiming for seamless integration with the pipeline. The third design principle is to be expressive enough to be adopted everywhere.
in-toto’s architecture is based on the ability to verifiably define both the stages of the software supply chain and the authorized actors who can get there. It provides tight binding of artifacts as they flow through the chain. in-toto uses a DSL that has “layouts” that define actors, public keys, and “artifact rules” that describe how artifacts relate to stages in the supply chain. The entire workflow is usually signed off by a project owner – which can be a security team or an individual, depending on the governance of the project. in-toto assumes that an attacker can compromise core infra like source code repositories, CI/CD systems, container orchestrators, inter-server communication channels and developer keys. It provides for a progressive degradation of security in such circumstances.
The in-toto project has been adopted by many production organizations including Datadog, kubesec, SolarWinds and restarterd. The project is hosted on GitHub.