DevSecOps: Moving from Implicit Trust to Explicit Proof
Author: Cole Kennedy
In recent years the shift from DevOps to DevSecOps has taken hold across the industry. DevOps was created to address the deeping problems that manifested when developers simply threw software over the fence to Operations staff for deployment into production. The depth and complexity of problems that were manifesting when Development and Operations were independent activities, especially in SaaS environments, were unsustainable. The problems were so damaging that the very ability of SaaS companies to meet service level agreements (SLAs) and remain financially viable were in question. As developers and operations staff became more welded at the hip through DevOps best practices, site reliability stabilized and SaaS growth in the market accelerated.
Today, all software, including firmware, middleware, and even SaaS face another existential crisis that is so profound that it affects families, businesses, and governments at all levels around the globe: cybersecurity. DevSecOps is the recognition that cybersecurity and InfoSec professionals must also be welded to the hip of the DevOps team. This is necessary to address the current brittleness of software, the exponential growth of vulnerabilities, the complexities of the software supply chain, and the challenges in verifying compliance with software controls that deliver more resilient software.
Organizations aren’t just looking for a verbal “trust us, we got this!” from suppliers when it comes to demonstrating secure software development practices
In fact, there is a growing demand from governments and businesses that their suppliers attest to following a secure software development process. Organizations aren’t just looking for a verbal “trust us, we got this!” from their suppliers when it comes to secure software development. Instead, they are demanding their suppliers rapidly mature and rigorously define how their software is built to be resilient in the face of evolving cybersecurity threats. They also want to better understand the controls and processes used to enforce positive control across the entire software supply chain, and they want irrefutable proof that the software is fully compliant with development policies that span from initial developer commit through a production deployment.
This ‘shift-left’ approach in DevSecOps aims to build it safer right from inception, not just build it better. The real challenge lies in operationalizing this strategy. How does an organization ascertain that security practices, policies, and procedures were consistently followed and effectively implemented? And, how can organizations verify that a software artifact adheres to the organization’s specific risk appetite?
As APIs from Kubernetes and Terraform are the bedrock of DevOps, there’s an emerging tool chain shaping the API landscape of DevSecOps, and it’s called in-toto.
in-toto: The Guardian of Every Software Supply Chain
In the NIST SP 800-240D initial public draft, the software supply chain (SSC) is defined as a collection of steps that create, transform, and assess the quality of software artifacts. The SSC covers the traditional procurement of third-party and open-source software artifacts, and it also covers all the actions required to place a software application into a production environment. These include actions such as writing code, packaging an application inside of a container, security scans for vulnerabilities, and performing quality assurance.
When an organization wants to understand how the software supply chain was secured, they want to understand all of the steps that created, transferred, and assessed the quality of the software.
The Cloud Native Computing Foundation’s (CNCF) in-toto project was established with a clear objective: instill an evidence-based approach to securing software systems by providing comprehensive, end-to-end guarantees about the integrity of a specific SSC. It espouses a seismic shift from that of implicit trust to one of explicit proof. The in-toto project and its supporting sub-projects of Witness and Archivista exemplify how “Sec” can be welded at the hip to DevOps. Employing all three of these open-source projects in a secure software development lifecycle is a route to both achieving Supply Chain Levels for Software Artifacts (SLSA) Level 3 and meeting NIST SP 800-218, Secure Software Development Framework (SSDF), compliance requirements.
Every DevSecOps continuous integration/continuous delivery (CI/CD) pipeline needs a way to report on the compliance of tools, processes, and data moving through it. This is the value proposition of the in-toto reference specification, providing DevSecOps teams a common language that developers, InfoSec, and operations personnel all understand. More succinctly, in-toto allows security professionals to define policies that include mandatory steps, acceptable thresholds for everything from code coverage to vulnerability scans, and even establish clear expectations that rigidly define where an artifact must be built if the artifact is to be trusted. When combined with digital signatures and cryptographic hashes, compliance with software development policies can be proven and adopt nonrepudiation characteristics.
Exploring in-toto's Expansive Ecosystem
The in-toto ecosystem continues to expand and diversify, expanding in both breadth and depth. Its ability to seamlessly integrate with established platforms like Jenkins and GitLab, and even newer initiatives such as SolarWinds’ Next Generation Build System, amplifies its reach and functionality.
Witness and Archivista are two key components of the in-toto ecosystem. Witness integrates with software build pipeline orchestrators to capture build process telemetry, actively enforce development policies, and generate evidence-based supply chain attestations for software consumers. Once all that metadata is gathered, it needs to be retained somewhere as proof of policy compliance. Archivista manages storage, retrieval, and retention of software build pipeline attestations and trusted telemetry observed by Witness and facilitates either ad hoc or deploy-time compliance verification.
The incredible adaptability of in-toto is further demonstrated by its implementation in a wide range of additional initiatives. For example, Lockheed Martin staff is building an open-source software bill-of-materials and secure S3C utility kit. The in-toto ecosystem is alive and vibrant, continuously evolving to support additional techniques that secure every software supply chain, cementing its position as the cornerstone in the evolution of the Sec in DevSecOps.
Realizing the Sec in DevSecOps
DevSecOps teams can actively move from an implicit trust compliance posture to one of explicit proof by embracing the CNCF in-toto project community efforts. InfoSec personnel must be integrated into the software development team, and these cybersecurity experts must actively work alongside the DevOps teams to define CI/CD pipeline compliance policies that result in a more resilient software supply chain. Enforcing policy within a CI/CD pipeline in an automated fashion is one of the most compelling ways to realize the Sec in DevSecOps. It compliments every software bill of materials (SBOM) and it gives software manufacturers the opportunity to showcase a market differentiating security experience to prospects and customers.