Rethinking DevSecOps: Moving to a risk-based SDLC

How security and compliance are integrated into the development lifecycle needs a fundamental re-examination. Organizations are stuck with a “check the box” and vulnerability-driven mentality tied to maintaining security and compliance at the expense of actual risk reduction. CISOs and CIOs often have conflicting interests, with security looked at as a roadblock to accelerating delivery through Digital Transformation. What’s needed is a new approach that analyzes data from throughout the entire development and DevOps processes to identify, prioritize, and remediate the risks that matter. We call these Material Changes.

In many ways, the lack of risk-based decision making is understandable because existing application and cloud security tools don’t provide CISOs, Security Architects, and Developers with an accurate picture of their risk.

Current approaches to DevSecOps fail to fully automate existing application and cloud security processes, which are periodic, resource intensive, and do not scale. To release changes to production, you still need to go through threat models, security and compliance reviews, pen-tests and risk assessments, which are manual and inaccurate because they’re based on self-attestation. Many platforms claim to simplify the addition of security into the DevOps process by aggregating data from different tools but in reality, they bolt themselves onto the existing process, remain siloed, and generate more alerts (many of them false-positives!) than ever before.

“Integrating security into DevOps to deliver DevSecOps demands changed mindsets, processes and technologies.”* – Neil MacDonald, Gartner

Today, there is too much of a focus on vulnerabilities detected by scanning tools. Organizations often have policies that all vulnerabilities with a certain score – or vulnerabilities of a certain type – need to be fixed before code is deployed to production. It doesn’t matter if a vulnerability is in an unimportant section of the code and completely unexploitable or if it can expose sensitive information to the Internet.

A better approach is to understand the entire context of a new code commit, from design to production, and handle it in a way that reflects its true risk instead of running all code through the same CI/CD pipeline. Imagine a developer working on a feature that adds PII to an existing API – now this API becomes sensitive. Understanding the authentication, authorization, encryption, and input validation controls of that API is critical to making risk-based decisions!

Fixing the current approach to the SDLC is hard to do. People naturally focus on the risk in front of them and don’t consider the personal consequences of missing a vulnerability. We need to have an organization-wide framework for deciding when and where to accept risk and then automate the decision-making. The way to enable this is with the proper information and context. Security, development, and legal teams need to better understand their code, from the history of the code base to the context provided by Jira tickets to conversations about the new feature on Slack. The developers themselves are also incredibly important to understand, from their experience with certain technologies to their security knowledge. When you have a more complete understanding of your risk, you can intelligently differentiate between changes and handle each in a way that’s appropriate.

Differentiating between changes – before CI/CD!

When you fully understand the history and context, you’ll come to understand this piece of advice from Gartner:

“Stop trying to remove all unknown vulnerabilities in custom code, which increases false positives. Instead, focus developers on those with the highest severity and confidence.”*

Doing this will change your entire approach to security in software development. It’s a mindset shift that enables you to stop thinking about security as a checkbox function and more of a context-aware process that is better aligned with your business strategy and tolerance for risk.

You’ll be able to improve security, make the most of your resources, and deliver faster. As Charles Blauner, the former CISO of Citigroup has said: “You can finally go talk to your CIO and say: ‘I have a way to make your life better.’”

* Gartner. “12 Things to Get Right for Successful DevSecOps” By Analysts Neil MacDonald, Dale Gardner. 19 December 2019