Chapter 32. DevSecOps Is Evolving to Drive a Risk-Based Digital Transformation
Idan Plotnik
Digital transformation has become a board-level discussion. Executives realize that their businesses are being disrupted and they need to innovate faster than ever in order to gain a competitive advantage and drive consistent growth.
DevOps has become synonymous with delivering faster in an Agile manner but a secure software development life cycle (SDLC) has often been left behind in the constant struggle for speed because it contains manual processes and too many tools that lack the context of risk and business impact. In addition, they are handled by different practitioners in the organization (e.g., developers, security architects, and compliance officers).
DevSecOps is the methodology and practice of inserting security into the DevOps process. Many organizations have found some level of success by automating their existing security processes and calling it “DevSecOps,” but that approach has created other issues, including more alerts and false positives that the security and development teams don’t have the time to research and fully understand in order to effectively remediate risk. With a ratio of one security architect for every 100 developers, DevSecOps has struggled to effectively scale.
Code Security Is Becoming Simply “Security”
What modern DevSecOps practitioners understand is that now everything is code! Product managers and developers are no longer writing detailed design documents. The code is the design. Infrastructure is now code. Cloud security settings are now defined in code. Adding personally identifiable information (PII) to a data model, publishing a new API in a cloud API gateway, and configuring authorization controls are all now done in code. This is what is finally enabling DevSecOps to live up to its initial promise. Code can be scanned. Rules can be established and processes automated. Machine learning (ML) and natural language processing (NLP) can be applied to detect abnormalities and risky material changes. Workflows can ensure that the right people are focused on the right security issues.
Shifting from Vulnerabilities to Risky Code Changes
In its early stages, DevSecOps was focused on finding vulnerabilities but state-of-the-art practitioners are moving past that to focus on risky changes and their business impact. Static and dynamic code analysis, fuzzing, and software composition analysis tools have focused on vulnerabilities and are now only part of a broader analysis of real-world risk. Context matters. And as development gets even faster—it matters more and more. This is a significant shift.
Code Risk Is Multidimensional
Properly evaluating code risk requires more than surface scans. It involves a deep understanding of the code components, security controls, data, and developer expertise. But in addition to focusing on code, security architects and AppSec engineers are broadening their roles to encompass all data that can help drive better decision making. “Shifting left” requires analyzing data from the design all the way through the SDLC phases to production, including container security, cloud configurations, API gateway settings, and more.
Other security domains are bringing their unique capabilities into DevSecOps. User and entity behavior analytics (UEBA) concepts are being used to identify compromised developer accounts and insider threats. Reverse engineering is being used to identify code that was inserted during the CI/CD pipeline. NLP is used to evaluate risk in Jira tickets, commit messages, and pull requests.
DevSecOps Is Evolving to Keep Up with Business Needs
Like many new methodologies, DevSecOps has made its way through cycles of hype and disillusionment but has evolved to become an essential tool that brings together development, security, and compliance teams to meet risk management requirements while enabling teams to accelerate business transformation.