Guest post by Aditya Sirish, in-toto maintainer and Cole Kennedy, member of the in-toto steering committee
The Integration Revolution
Being part of the DevOps world, you’re likely no stranger to the DevSecOps buzz — the strategy of embedding security within your development process core. This ‘shift-left’ approach aims to ‘build it safer’ right from inception, not just ‘build it better’. But the real challenge lies in operationalizing this strategy. How do we ascertain that our security practices, policies, and procedures are consistently and effectively implemented throughout the entire software supply chain? And how do we ensure software artifacts adhere to our risk policies?
Much like how APIs such as Kubernetes and Terraform have become the bedrock of DevOps, there’s a tool emerging to shape the API landscape of DevSecOps — in-toto. This tool might well be the defining API of DevSecOps, paving the way for an integrated and secure development proce
in-toto: The Guardian of Your Software Supply Chain
Let’s delve into the capabilities of in-toto. Originating from the Secure Systems Lab at New York University Tandon School of Engineering and later adopted by the Cloud Native Computing Foundation, in-toto was established with a clear, robust objective: to instill an evidence-based approach to securing software systems by providing comprehensive, end-to-end guarantees about the integrity of your software supply chain. It brings a significant shift from implicit trust to explicit proof, marking an evolution in DevSecOps. This method is a route to both achieving SLSA Level 3 and meeting SSDF compliance requirements, thus boosting your systems’ security and reliability.
It works by defining a series of steps that map out your software supply chain — everything from coding and testing to packaging and deployment. Each step includes details about the responsible party (human or tool), the necessary inputs, the expected outputs, as well as environment details about where the step is being executed. These steps are captured in a ‘layout’, essentially a blueprint for the entire process, aligned with your organization’s security and compliance mandates. The layout encompasses the specifications for the anticipated execution environment of the software. Importantly, organizations can employ multiple layouts, each corresponding to the distinct risk levels in different execution environments. High assurance environments will necessitate more stringent requirements within the layout compared to low assurance environments, ensuring adaptability and security across various operational contexts.
Then, as each step is completed, in-toto generates metadata also known as an attestation capturing details about the execution of the step, including the environment, materials, and products, which are backed by a cryptographic signature. This provides a robust and reliable record of who did what, where, and how.
You may already be familiar with some popular attestation types, such as OpenVEX and SLSA attestations, but these represent just a portion of the possible attestations due to the varying steps in the software supply chain. Each attestation type has a specific role to play in ensuring the security of the chain. It’s essential to remember that these attestations can span a wide range of tools and stages, including vendor risk, coding, and deployment, as well as custom steps tailored uniquely for a particular organization or process.
Furthermore, additional layers of data, such as SARIF and SBOM documents can be wrapped around these attestations, adding further depth and detail to the security analysis. Projects such as Syft already support generating a SBOM wrapped in an in-toto attestation. By employing in-toto alongside these tools and attestations, organizations can maintain a rigorous, end-to-end view of their software supply chains. This holistic view, backed by cryptographic proofs, establishes provenance and ensures the integrity of the chain at every stage and facilitates traceability, accountability, and most importantly, trust in the resulting software product.
The Case for in-toto as the API of DevSecOps
Now, you might be thinking, “That’s great, but how does this make in-toto the API for DevSecOps?” Well, it all lies in the power of integration. You see, when you’re creating a DevSecOps pipeline, you need a way to bring together all of your tools, processes, and data. You need a ‘common language’ that everyone — or rather, every tool — can understand and use to cooperate effectively. And that’s where in-toto comes in.
Think about it. Each step in your in-toto layout could correspond to a different tool or process in your DevSecOps pipeline. The attestation in-toto creates serves as a record of that tool’s operation and output. These steps might involve static code analysis tools like SonarQube, container security platforms like Aqua Security, identity and access management tools like Okta, or even automated compliance tools like Chef Inspec. Each tool would output its own attestation, which would then be fed back into in-toto.
As a result, in-toto acts as a kind of ‘meta-API’, serving as a bridge between all these different tools and their respective APIs. It allows them to ‘speak the same language’ and work together seamlessly, all while ensuring the integrity and security of your software supply chain.
Instantiating Trust with in-toto
Trust is a crucial but often overlooked element of security. Guaranteeing the trustworthiness of an artifact is not simply about detecting and mitigating threats; it involves intentionally designing and managing the system to ensure resilience against those threats.
in-toto cultivates trust by offering cryptographically robust, end-to-end assurance of integrity within your software supply chain. The aforementioned in-toto layout empowers users to define the inputs and outputs for each stage in the supply chain. To verify the integrity of the materials and products, it employs cryptographic hashing on these defined inputs and outputs at each stage.
During layout evaluation, in-toto verifies that the inputs and outputs of each attestation align with the rules set out in the layout. By fully integrating in-toto into your DevSecOps strategy, you can ensure that every step in the development process is accurately documented and securely executed, confirming that no aspect of the process has been tampered with.
Implementations such as Witness, the SLSA Generator, and Cosign, provide Sigstore integrations to make generating and signing in-toto metadata easy.
Exploring in-toto’s Expansive Ecosystem
The in-toto ecosystem’s continuous expansion and diversification are testament to its growing influence and applicability in the DevSecOps realm. Its ability to seamlessly integrate with established platforms like Jenkins and GitLab, as well as with newer initiatives such as SolarWinds’ Next Generation Build System, amplifies its reach and functionality.
Emerging tools like Archivista and the Graph for Understanding Artifact Composition (GUAC) are leveraging in-toto’s attestations to enhance visibility and deepen understanding of software supply chains.
Furthermore, the adaptability of in-toto is well-demonstrated by its implementation in a wide range of initiatives. From Lockheed Martin’s open-source software bill-of-materials and secure S3C utility kit, Hoppr, to SolarWinds’ post-SUNBURST infrastructure overhaul, in-toto’s abilities are being recognized and utilized across diverse platforms.
The versatility and scalability of in-toto are further embodied by tools like Witness, a pluggable framework. TestifySec’s implementation of in-toto, allowing for use and verification of both custom and standardized predicate types, offers a high level of customization. It supports a library of attestation predicates that can be tailored to meet specific needs, underlining the adaptable nature of the in-toto ecosystem. This ecosystem is not static, but constantly evolving to support new predicate types, effectively adapting to changing software supply chain security needs.
Moreover, the confluence of in-toto and The Update Framework (TUF), a security-centric system for software updates, enhances the effect of in-toto attestations. By marrying TUF’s distribution model with in-toto’s trusted integrity, Datadog is securing the publication of their Agent Integrations. The maintainers of Archivista, a specialized service dedicated to storing in-toto attestations, are undertaking efforts to incorporate TUF repository support. This will empower organizations to stipulate a continuously updated, authoritative policy for software artifacts.
Each integration reinforces in-toto’s adaptive capabilities and its potential to facilitate communication across multiple platforms and tools. The growing universe of in-toto cements its position as a cornerstone in the future evolution of DevSecOps, underscoring its critical role in enhancing software supply chain security.
The Future of DevSecOps
With in-toto acting as the API of DevSecOps, you can streamline your entire software development lifecycle, reducing the risk of security missteps and enabling more effective communication and collaboration across your team. It’s not just about building secure software — it’s about building software securely, with in-toto serving as the glue that holds your DevSecOps strategy together.
However, it’s important to note that this doesn’t happen at the snap of a finger. Right now, implementing in-toto effectively will require careful planning, testing, and potentially some custom tooling to translate between your tools’ APIs and in-toto’s metadata.
But with these challenges comes the opportunity for a new level of software security — one that spans the entire lifecycle, from the earliest stages of development to the final stages of deployment. It’s a future where security isn’t just a box to be checked, but a fundamental part of the software we create.
Community Engagement
There are a number of ways to get involved with in-toto. The in-toto community is actively working on exciting developments such as enhancements to layout capabilities. Simultaneously, the maintainers and the broader community are defining new attestation types to fit a variety of use cases, implementing them in in-toto tooling, and working with maintainers of relevant tools to integrate and deploy these changes. All of these are ways to directly contribute to the project. Another way to get involved is through ongoing adoptions. For example, NPM recently started supporting generating in-toto attestations for package provenance with work underway on recording the publishing of new package versions. Similarly, the OpenSSF’s Securing Software Repositories working group has proposed generating in-toto attestations for provenance in Homebrew, the widely used package manager for MacOS.
To get started in the in-toto community, swing by the next community meeting. The in-toto community meets on the first Friday of every month. You can reach the community on the CNCF Slack Workspace, GitHub, and by email via the mailing list.