Do a Google News search on “cybersecurity” and you’ll get tens of millions of results. Of course, that doesn’t mean there were that many cybersecurity incidents in the last week or so, but it sure does feel that way. The application supply chain is a prime target for this onslaught of cyberattacks, which is what makes DevSecOps—building app security into development from end to end—so critical. In fact, the Pentagon’s new IT modernization strategy will be based in part on the new DevSecOps 2.0 guidance.
There is DevOps plus security, and then there’s DevSecOps. What’s the difference? In the first case, security is a third wheel. In the second, it’s the third leg of the stool—an integral part of the system that’s almost unnoticeable unless or until it disappears. Indeed, to be effective, security must be everywhere—throughout the pipeline used to build and deploy as well as the runtime environment.
In the DevSecOps model, security is a shared responsibility for development, security and operations teams and throughout the entire IT lifecycle. However, many organizations are challenged to integrate, rather than just tack on, security measures. This is a huge issue when a company’s own security is at stake, but an increasing number of attacks on the software supply chain is leaving tens, hundreds, even thousands of organizations vulnerable.
1. Zero trust
The term zero trust succinctly communicates what many of us have understood for a long time: There is no such thing as 100% security when it comes to software. Zero trust—an umbrella for everything I discuss in this article—isn’t about locking everyone and everything down, but rather about never assuming trust and always verifying.
Through the implementation of adaptive and continuous protections, as well as systems for recognizing and responding to threats, organizations gain insights that can be applied to tune protections over time and as contexts change—key to true security integration.
Both to avoid human error and to ensure that security and performance are balanced, it’s important to automate anything that can effectively be automated. Indeed, without automation there can be no DevSecOps. Automation also improves auditability, and auditability is a key source of insight.
Organizations should assess the entire development and operations lifecycle, including source control repositories, container registries, the CI/CD pipeline, API management systems, orchestration platforms, and operational management and monitoring systems. They should focus on working iteratively, using metrics and lessons learned from each automation project to continue to expand automation along the pipeline.
The ultimate goal is everything as code, which may also be the ultimate defense against ransomware: Organizations that can “simply” redeploy code, and reduce reliance on backup, are resilient because attackers will have little or nothing to hold over their heads.
3. Attestation and digital signing
Today’s software supply chain is actually more like a web: Developers write their own code, but they also pull from numerous third-party sources, open-source projects, registries, and so on. In a DevSecOps environment, how do they know that what they are pulling into the codebase is safe?
Attestation is critical, with digital signature technology playing a key role in ensuring that a software artifact is verified as being what it says it is. Perhaps even more important, digital signatures provide proof that an artifact has not been altered in any way.
Red Hat’s Luke Hinds, security engineering lead for the CTO’s office, wrote in a recent blog that digital signatures are “the answer to securing software supply chains,” but he is concerned that the open-source environment is not conducive to the digital signature process (due to expense and performance).
So he created a new open-source project, sigstore, which now has more than 465 members and over 20 organizations. It promises to more effectively align the open-source innovation engine with digital signature protections, including a signature transparency log. Sigstore is now under the auspices of the Linux Foundation, with backing from Google and Red Hat.
4. Vulnerability/risk assessment
We know far more about code than we used to, but simply knowing that vulnerabilities exist in the code you’re using isn’t enough to keep your organization safe. Neither, for that matter, is fixing every vulnerability. Why?
For one thing, it’s impossible. As soon as you fix one vulnerability, someone will discover another. Furthermore, not all vulnerabilities create equal risk. The current state of vulnerability scanning requires that organizations deal with huge, uncontextualized volumes of data generated by vulnerability scanners and other monitoring systems. Effective vulnerability management requires additional context to help organizations address these findings strategically. Machine learning will play a role here, but there will never be a substitute for key players across the organization collaborating on risk management categorization that is specific to their requirements and business needs.
5. Corporate culture
For many organizations, corporate culture is the biggest hurdle to true DevSecOps. No technology or combination of technologies can be effective unless your organization has developed a culture that supports the DevSecOps model.
Adoption of true DevSecOps requires breaking down silos, getting executive buy-in, finding champions across the organization, fostering a willingness to collaborate, and developing a collective understanding of the organization’s security “why.” It is often most effective to charter a single team to be the pioneers for the organization, incentivizing them to lead the way and allowing them to experiment. Once you’ve established a successful pattern, it can be celebrated and broadly shared.
Look for a best-fit solution
With the rise in malicious activity alongside the increase in remote work and vulnerabilities in the supply chain, your organization needs to look beyond what’s always worked to what will work best now.
Best is the operative word, because what works best is different from what works perfectly. So build your DevSevOps platform with the understanding that nothing and no one is completely safe (zero trust), that many parts of the software supply chain are now outside of your control (attestation and digital signing), and that it’s almost certain that your business will get hit with some form of malicious attack (vulnerability/risk assessment). If you can wrap automation and a security-minded company culture around solutions based on these realities, you will be well positioned to move from DevOps plus security to true DevSecOps.