DevOps is designed to increase business value and responsiveness through rapid, high-quality service delivery, made possible through fast-paced, iterative IT service delivery. The term DevSecOps emerged as a way to remind us that security was always intended to be part of the software delivery process. However, with the barrage of attacks on the software supply chain showing no signs of abating, the question now is whether even the tightest DevOps pipelines can maintain the pace-protection balance.

It’s important to note that the term “software supply chain” has been used primarily to refer to the tools and processes used to build and deploy software applications. Now, however, with the rise of infrastructure-as-code (IaC), the term also refers to tools and processes used to build and deploy IT infrastructure.

Meet Mandates, Reduce Risk

Software supply chain attacks such as SUNBURST, HTTP/2 Rapid Reset or the breaches associated with the MOVEit vulnerability have fed news cycles for the last few years, and that likely won’t change anytime soon. Attacks on the software supply chain increased 742% since 2020. What we are seeing as a result are new concerns about supply chain security and DevOps requirements. This has led to confusion and often a mish-mash of tooling that may exacerbate rather than mitigate supply chain security issues.

Arguably the most impactful salvo over the software supply chain security line was president Biden’s 2021 Executive Order 14028, which established new mandates, including the delivery of SBOMs, as minimum requirements for software used by the U.S. federal government. More recently, the FDA has mandated that “all medical devices running software must create and maintain” SBOMs. I expect to see government and industry requirements increase over time.

These are just a couple of relatively recent examples. There are many more—and no doubt many more to come.

So, if you’re moving at the speed of DevOps, how do you address these current and future mandates for software supply chain security, as well as the continually emerging vulnerabilities and attacks? I would venture to say that only by moving at the speed of DevOps—and within the parameters of the DevOps model—can organizations not only meet mandates but also effectively reduce risk for the business.

Indeed, it’s not a matter of whether DevOps is viable within the current security climate but what requirements need to be added to support and enhance current DevOps work.

New Guidelines, New Processes, New Tools and New Data

In response to these new threats and regulations, the software community has been working on developing and updating guidelines to help organizations improve the security of their supply chains—for example, SLSA, NCSC UK supply chain security guidance and NIST cybersecurity supply chain risk management. However, these new guidelines can be complicated and require new processes and new tools.

Before adding any new tooling or changing any processes, it’s critical to examine existing tools to determine whether and to what extent they satisfy supply chain security mandates. Organizations must also evaluate how well existing processes work to protect the business, then strategically add/subtract from there as needed.

No matter what solutions are leveraged, more and different tools generate reams of more and different data. What’s important — and to whom? How do I manage the data? When can I trust it? Where do I store it? What problems does the new data help me solve? Organizations will need a way to effectively sift this information and deliver the right data to the right teams at the right time. To preserve the ability to quickly and continuously innovate, it will be important to focus on shifting security left as well as integrating automation whenever and wherever possible.

As new security metadata becomes available, such as from SBOMs, new solutions for managing that metadata will be key. An open source initiative sponsored by Google, GUAC is designed to integrate software security information, including SBOMs, attestations and vulnerability data. Users can query the resulting GUAC graph to help answer key security concerns, including proactive, preventive and reactive concerns.

Continue to Shift Security Left

Another way that organizations can maintain their DevOps momentum while protecting the software supply chain is to continue to invest in shifting security left in the software supply chain. The software community has been talking about this for some time, but many organizations struggle to implement impactful changes. Security teams must work to understand how software is built and collaborate with development and DevOps teams to ensure that improvements are made to both application and infrastructure-as-code supply chains.

We need to go beyond shift-left vulnerability analysis to ensure that we are evaluating the quality of configuration-as-code (for both applications and infrastructure), that we are taking advantage of new recommendations, and that we are leveraging new attestation solutions designed to work with pipelines such as sigstore and Tekton Chains. After all, the sooner an issue is discovered, the more quickly it can be addressed and the less disruptive and costly it is to fix it.

No One-Size-Fits-All Solution

While all of these solutions mentioned here are helpful, there is no single product or framework that will enable organizations to maintain the security-innovation balance. Success, rather, will require a focus on agility, flexibility and effective communication and collaboration—the very hallmarks of the DevOps model.

Rather than being obviated by the demands of software supply chain security, DevOps provides the opportunity to integrate the kinds of protections that can prevent or mitigate supply chain vulnerabilities and breaches. DevOps also enables organizations to quickly and effectively respond to new threats and new requirements.

With that said, there’s no doubt that organizations will need to think differently about how they manage software security, including the strategic evaluation and integration of tools that will meet current and future regulatory mandates and, more importantly, protect the business over time. Organizations may also need to think about weighing security over speed, at least until all of the pieces of the software supply chain protection puzzle are in place—but also when future circumstances warrant a fresh look at how to best balance the DevOps pace-protection balance.