3 reasons DevSecOps is getting so much attention

Interest in DevSecOps is on the rise. What’s driving this interest? And how can teams use this knowledge to modernize their application security programs?

By Daniel Kennedy, Research Director, Information Security, 451 Research

Taking application security tests and “shifting them left” into a systems development life cycle is not a new idea. Yet “DevSecOps” was an especially hot topic of discussion in 2019. A brief review of Google Trends shows the term being searched more in 2019 than ever before.

It’s largely well accepted that fixing defects as code is being created is much more efficient and cost-effective than allowing a defect to propagate through builds, testing, and production. In fact, the cost of a defect increases as it moves forward through development phases. Security vulnerabilities introduced into code are no different, and the discovery of a security vulnerability in production by bad actors is a worst-case scenario playing out in prominent data breaches affecting customers. Some 62% of hacking incidents analyzed in Verizon’s 2019 Data Breach Investigations Report were against web applications.

Shifts in enterprise IT

Part of this new level of attention around DevSecOps is due to underlying shifts in enterprise IT. Infrastructure as a key concern continues to abstract away from enterprise technology teams as virtualized and cloud-based architectures become more common, and with that, application development is becoming even more of a key differentiator for IT.

Growth in DevOps tools

Part of this new attention to application security specifically is facilitated by the growth of DevOps methodologies and, more notably, tools. This organic standardization of toolchains across enterprises is allowing information security teams to work with developers to implement and call application security testing (AST) tools directly from both developers’ IDEs and build tools. Developers are also able to receive feedback from that testing in their own ticketing or notification systems, reducing context switching in their processes.

Increase in highly iterative development

And finally, part of this new attention is by necessity. Current development methodologies are highly iterative, meaning many small changes are quickly being integrated into builds. Combine that with the fact that most enterprises that do serious development have more developers than security folks, and the idea that security teams can run these tools themselves in production or hold up releases until they can conduct tests is impractical. A small percentage of the code changes being released will be tested in such scenarios. Only through federating certain security responsibilities to developers and integrating AST tools into existing processes can security hope to keep up with the pace of application change while maintaining an acceptable risk posture for the enterprise.

What does this mean for your application security program?

Shifting activities doesn’t necessarily shift responsibilities or motivations. Developers are still judged by how quickly they can release defect-free code, and security is still evaluated by risk reduction, especially around possible data breaches. Considering how these teams are measured, careful consideration must be given to the design for integrating AST activities into developers’ processes. Integrations must be low friction for developers, and report metrics need to allow the security team to both monitor the efficacy of the overall process itself and be aware of potential vulnerabilities escaping the development life cycle into production.

The recently released paper Designing a Modern Application Security Program from Synopsys and 451 Research dives further into the factors driving DevSecOps, and how teams should approach an application security program.