Adoption has been driven by the expansion of tools, business operations, and software delivery automation.
I wrote The Future of DevSecOps in June 2019 after gathering insights from professionals who foresaw: 1) greater adoption, 2) security ingrained in development, and, 3) AI/ML-driven automation.
For this article, I wanted to go back and see how the adoption of DevSecOps has proceeded over the past two years. In a subsequent article, I‘ll share what these IT professionals now see as the future for DevSecOps.
I received input from more than 40 IT professionals. Based on their feedback, the most significant evolution of DevSecOps over the past couple of years has been: 1) the expansion and adoption of tools, 2) businesses realizing the necessity of DevSecOps, and, 3) software delivery automation.
Tools Drive DevSecOps Adoption
A critical step toward DevSecOps has been taken by DevOps itself, which started offering its own application security technologies. Application security vendors, as well as open-source security communities, have started addressing this emerged opportunity as well. They have begun integrating their existing technologies in the unified DevOps, thus serving it with intermediate solutions (intermediate – because those solutions have not been designed for new paradigms). At the same time, those security vendors/communities have been/will be rapidly developing native solutions for the emerged DevOps.
Those combined efforts will assure that, through 2022, the DevSecOps community grows bigger than in the previous ten years combined.
The past two years have also not only seen a rapid acceleration of cloud adoption, but also abrupt moves to remote work, zero trust, and SASE deployments. These new strategies are leading to a broad range of security and monitoring tools being adopted. In an environment with so many diverse technologies in use, DevSecOps engineers have become even more important to help gather, normalize, and process telemetry from all of the available sources and detect and take action on anomalies quickly.
Wider variety of tools available to be integrated into CI/CD ranging from vulnerability scanners to checking for exposed credentials and malware
Cloud service provider tooling getting more comprehensive to provide security for CI/CD out of the box. For example, GCP container scanning, AWS Inspector, etc.
Fortunately, new technologies for development, automation, testing, and monitoring have emerged and existing tools have become more refined over the past several years.. Many are prioritizing integrations with other developer-focused platforms so that everything works together to make DevSecOps processes more seamless.
DevSecOps has evolved in many of the ways we anticipated: wider adoption, developer-first, and cloud-native tooling, and more “kumbaya” between development and security teams. Security - traditionally viewed as an impediment to innovation by developers - has seen mindsets change and automation improve.
In fact, the 2020 Software Supply Chain Report found that high-performing development teams could be simultaneously more productive and more secure than both their velocity-first and security-first peers. Security information is embedded into developer tools very early in the SDLC, and security teams are helping define secure coding guardrails that eliminate the need for traditional review gates. Developers are spending no more time on security, but they are definitely producing more secure code as a result of DevSecOps practices.
Over the past year, there has been a multitude of incidents that highlight the importance of deploying secure code and infrastructure. As the SolarWinds and the recent PHP attack show, security is not just about protecting a running system, it is about enabling developers to be part of a comprehensive security story.
Existing toolsets have started to adapt to the expanding role and audience of security data, meeting developers where they are to enable the important role they play in the overall DevSecOps effort.
The first phase of DevSecOps was marked by getting more cybersecurity tools into the hands of developers.
Business Adoption of DevSecOps
DevSecOps is still crystallizing, but it’s definitely becoming more mainstream. Most development organizations have recognized the need for bringing security and development together. Many organizations have started efforts to “shift left” with champions, better automation, and sharing security responsibilities with development teams. Threat modeling is increasingly a piece of DevSecOps where developers and security teams can collaborate.
With organizations speeding up the delivery of code to provide the best user experience possible, security needs a seat at the table. This causes the “Sec” piece of DevSecOps to grow considerably. Teams are better aligned to collaborate and focus on a common outcome, allowing security to be an enabler versus a detractor.
DevSecOps, once considered the realm of internal technical communities, has evolved into a business operation. The change is significant, and we see its effects in the form of business-led rapid delivery cycles to balance both revenue and risk concerns.
In today's DevSecOps tool ecosystem, we are witnessing the emergence of balanced development automation tools that bring compliance into DevSecOps and provide real-time risk assessment capabilities that help provide a much-needed balance between security and speed.
Threat modeling is one of the biggest things we've seen at making sure things don't fall between the cracks. Any good threat model is going to contain the security requirements for both the software and network architecture. Everyone along the software development life cycle can follow this to ensure all the requirements are met.
With the evolution of DevSecOps, companies are doing a complete restructure in order to open up collaboration between development, operations, and security teams so that all of them can contribute from the beginning steps of the creation of new applications.
As more organizations began to migrate to various cloud services, the security problems became more complex and more integrated into the software, i.e., we went from physical networks to software-defined networks (SDNs). This drove the actual real shift of where security is now truly starting to be integrated at the very beginning of the software development lifecycle (SDLC). The DevSecOps evolution over the last few years has made that a possible thing and not just a nice-sounding theory that we put in mission documents and software design documentation.
In the past two years, DevOps adoption has picked up considerably. Before the pandemic, organizations were starting to recognize the value of DevOps-oriented software delivery methods, but with the massive shift to the cloud, businesses suddenly prioritized overnight. One year later, there is a unanimous truth among businesses building software that DevOps and CI/CD is foundational to your organization’s long-term health and efforts to innovate in a remote world.
Automation and DevSecOps
The use of software delivery automation to improve product security has seen increased adoption in recent years. Product security is treated less as an out-of-band activity that happens towards the end of the product life cycle and more as a core part of the product life cycle itself. The realization here is that there's no such thing as "adding security" to a product on the way out the door, but that it has to be a fundamental part of the process itself.
DevSecOps engineers are adding automated quality gates to their security tooling, while also integrating application security test tools, such as SAST and SCA, into their software development workflows.
This trend is driven by the reality that traditional vulnerability assessment tools, such as vulnerability scanners, simply aren’t effective in today’s highly dynamic production environments. We know attacks happen all the time in these environments, but vulnerability scanners aren’t capable of catching them. This is why it’s so important to establish a process that supports quick detection and remediation of problems in production. As a result, we’re seeing not just this push to “shift left” security, but also a new emphasis on “shift right” security, which is fueling a need for different kinds of security tools that are equipped to scan vulnerabilities in highly dynamic production environments.
Growth in both cultural awareness on the people and training side and technology automation from industry, standards, and vendors. It is also more and more of a concern in cloud-native modernization projects where older monolithic applications are refactoring to microservices and new DevSecOps methodologies are required to secure and manage the service interactions and APIs.
Thanks to the other contributors who shared their thoughts for this article:
Deepak Kumar, CEO and founder of Adaptiva