Securing the Software Supply Chain with the in-toto & SPIRE projects

Introduction

Welcome to our discussion on securing the software supply chain with a focus on the in-toto and SPIRE projects. As a solutions architect at BoxBoat Technology, I, Cole Kennedy, lead our technical initiatives pertaining to federal and high-compliance industries. I also contribute to the CNCF SIG Security Supply Chain working group, where we're currently drafting a supply chain security white paper that should be released soon.

Our aim is to help organizations, particularly in defense, banking, and utilities, transition toward a DevSecOps model despite the complexities introduced by strict regulations. Joining me is Mikhail Swift, a talented DevOps engineer at BoxBoat, who has played a pivotal role in enhancing our understanding and implementation of supply chain security.

The Challenge

Recent events have amplified the urgency for organizations to assess the risk levels associated with software running on their systems. Many organizations operate on a trust-based system—a paradigm that is becoming increasingly problematic. A significant number of organizations do not sign their artifacts or maintain proper metadata, which hinders the ability to validate the integrity of the software being implemented.

Especially in high-compliance environments like defense and banking, the pressure to rapidly deliver software often comes at the cost of security, leaving organizations vulnerable. We cannot afford to introduce vulnerabilities into our systems. Hence, moving towards a Zero Trust architecture becomes essential.

Understanding Zero Trust Architecture

Zero Trust is not merely a product to be purchased; it's a strategic approach that organizations must adopt. It involves three core components:

Identity: Every workload—whether an application or a user—must have a unique, immutable identity. This could be derived from attributes like container hashes or process binary hashes.
Policy: In traditional architectures, policies are managed through cumbersome change control processes. In Zero Trust, we promote policy as code, allowing automated enforcement of rules through tools like Open Policy Agent.
Control: This pertains to how identities and associated policies are managed and used to make decisions within the system.

When these three facets work collectively, organizations can create a robust Zero Trust architecture to secure their CI/CD pipelines.

Implementing Evidence-Based Trust

Historically, trust in software delivery has been established on the basis of signatures—this is inadequate. Instead, we must embrace evidence-based trust. This new approach requires us to capture metadata at every stage of the build process, asserting that software was built in a controlled environment by verified processes.

This shift can be greatly facilitated by the in-toto project, which allows for the generation of signed metadata enabling organizations to verify the integrity of their software components without relying solely on vendor trust.

The Role of in-toto and SPIRE

The in-toto project allows us to define a pipeline where each step's outputs and dependencies are strictly monitored. By implementing in-toto within a CI/CD pipeline, we achieve strong guarantees about the integrity and authenticity of our builds.

SPIRE complements this by providing identities based on immutable workload attributes, such as the public hash of a machine's TPM (Trusted Platform Module). By combining in-toto and SPIRE, we're able to create a self-contained, automated architecture that proves workload identities and the integrity of built software.

Demonstration

Mikhail will now demonstrate how we've applied in-toto and SPIRE in a practical example involving a sample Hello World project. This project utilizes a simple build pipeline that assembles a binary and a Docker image, verifies them using in-toto, and scans for vulnerabilities.

Utilizing in-toto’s commands aids in capturing materials produced in each build stage and validates against a defined layout. The demonstration will showcase how even minor deviations in code can be detected in the build process, confirming the efficacy of our approach.

Conclusion

In conclusion, the integration of in-toto and SPIRE provides a robust foundation for securing the software supply chain. By ensuring that each artifact in the pipeline is verified and trusted, we can mitigate risks associated with software vulnerabilities. We remain committed to refining these practices and contributing to the rich landscape of security and compliance.

Keywords

Supply Chain Security
Zero Trust Architecture
in-toto
SPIRE
DevSecOps
Evidence-Based Trust
CI/CD Pipeline
High Compliance
Artifact Verification
Workload Identity

FAQ

Q1: What is Zero Trust architecture?
A1: Zero Trust architecture is a security model that requires strict verification for every person and device attempting to access resources within a network, regardless of whether they are inside or outside the organization's perimeter.

Q2: How does in-toto enhance software supply chain security?
A2: in-toto allows organizations to create a secure pipeline by capturing and verifying metadata at every stage of the build process, providing a comprehensive audit trail for software integrity.

Q3: What role does SPIRE play in this ecosystem?
A3: SPIRE provides workload identities based on immutable attributes, allowing organizations to cryptographically confirm that the software was built in a controlled and trusted environment.

Q4: Why is evidence-based trust important?
A4: Evidence-based trust shifts the paradigm from relying solely on signatures to using core metadata verification, ensuring that organizations can validate the integrity and authenticity of their software products throughout the delivery pipeline.

Q5: Can these processes be automated?
A5: Yes, both in-toto and SPIRE can be integrated to automate the proving of workload identities and artifact integrity, facilitating a streamlined and secure software development lifecycle.