6 Signs DevSecOps Maturity Has a Long Way to Go

• Only 20% of organizations believe they’ve reached full DevSecOps maturity
• Nine in 10 DevOps organizations have experienced a security incident in their Kubernetes and cloud environments
• Approximately 60% of developers say they get little to no secure coding training

Enterprises seeking to up their cybersecurity game to meet the challenges and risks of digital transformation have driven DevSecOps into mainstream IT consciousness. But DevSecOps awareness and aspirations have still not yet translated to widescale security transformation. Not by a long shot. Some of the most recent studies show that most organizations have a long way to go before they even reach middling levels of DevSecOps maturity.

First, Some Good News

Before we discuss the stats that point to the symptoms of DevSecOps immaturity, it’s important to note that there are definitely some positive signs that incremental progress is being made.

Sponsorships Available

Sponsorships Available

Sponsorships Available

For example, the State of Container and Kubernetes Security report released by StackRox showed that some 83% of organizations are working on building up at least some level of cooperation between security and DevOps teams. That study showed that approximately 40% of organizations are starting to get DevOps and security teams to collaborate jointly on policies and workflow. An additional 27% said that they’re in the process of integrating and automating security across the SDLC. Another 16% say they are implementing security as code.

Granted, those results are from a survey focused on cloud-native technology, so the likelihood of sample bias is high here. But it nevertheless serves as a bellwether for which way the wind is blowing when it comes to weaving security throughout the software development lifecycle (SDLC). Another indication of that came by way of a recent report by Dimensional Research on behalf of Acunetix, which shows that regardless of DevSecOps program status, the AppSec world has reached a tipping point for moving security checks earlier in the lifecycle. That study shows that half of organizations today now include web application security scans with every code build or during unit testing. And at very least, 80% of organizations report that they do some kind of code scanning at some point during the SDLC, even if it isn’t necessarily early on.

The Reality Check

Nevertheless, AppSec teams still struggle on many fronts to bake security into the process of delivering software, and the vast majority of organizations are early on in their DevSecOps journey. According to another recent study conducted WhiteSource, only 20% of organizations believe they’ve reached full DevSecOps maturity. And 73% of respondents say they feel forced to compromise on security to meet short development lifecycles.

Which is fine in a lot of situations, because what is risk management but a constant exercise in compromise? It’s all about weighing the risks against the benefits of a certain activity, and coming up with a balance in action and controls that minimize the risk while maximizing the benefits. The problem for DevSecOps today is that the indicators show there’s still little rigor or due diligence to come up with a disciplined method for determining that balance, let alone executing on it.

The following signs show that at most organizations today, trading off security for DevOps benefits is less of a compromise and more of a complete capitulation.

The Cultural Divide Continues

A recent study conducted by Ponemon Institute on behalf of ZeroNorth shows that a significant cultural divide still exists between AppSec teams and developers that significantly hinders the seamlessness of a DevSecOps approach. At the heart of it is a lack of understanding and harmonization of team missions across both stakeholder groups.

For example, the study showed that 65% of developers reported the AppSec team doesn’t understand the pressure that DevOps teams are under to meet their deadlines to deliver new features. Additionally, 41% report that the AppSec team doesn’t understand that at the end of the day developers are judged not on their risk management but on their ability to innovate and meet deadlines. Meantime, on the other side of the divide, 71% AppSec folks say that developers who don’t care about the need to secure applications early in the SDLC are undermining the state of security. Approximately 59% of these security pros believe developers don’t take security of applications as seriously as they should.

Orgs Lack Prioritization Process for Fixing Vulns

Even when organizations do a better job of automating security testing and moving it earlier into the SDLC, many DevOps teams still struggle to actually fix the flaws that are discovered. The Dimensional Research study found that half of dev teams say they find vulnerabilities faster than they can fix them. This means that prioritizing the most impactful flaws for mitigation should stand as a crucial tool for incrementally reducing risk in an organization’s code base.

Unfortunately, fewer than one in three organizations organization have a defined and agreed-upon vulnerability prioritization process, according to the WhiteSource report.

Security Lacks Business-Level Champions

The disconnect on what DevOps pros prioritize over time—security work versus innovation and feature delivery—ultimately comes down to how they’re measured and incentivized by their bosses. Many executive teams may pay lip service to the need of better cooperation between security , 44% according to security pros interviewed in the Ponemon study. But that study showed that only 19% of organizations put their money where their mouth is in that regard by making collaboration between AppSec and developers an important part of the performance review.

This illustrates the often hidden fourth party to the DevSecOps collaboration—business stakeholders. Many times security and DevOps fail to collaborate well because security hasn’t closed the collaboration gap with the business people who actually own the applications in question.

“You really have to have some buy-in and at least some level of understanding and education at the business side, because they own these apps. If I’m in a big bank, for example, the mortgage department owns the online mortgage application,” Brad Cause, CEO of application security consultancy Zero Day Consulting, recently told me for a Dark Reading piece I wrote recently on this common disconnect. “So they’re responsible not only for producing the application, but understanding and directing risk management work associated with it.”

Devs Aren’t Getting Enough Security Training

DevOps teams still commit code full of common vulnerabilities because in spite of growing levels of awareness for AppSec, most developers still don’t get nearly enough security training to help them consistently engage in secure coding practices on a day-to-day basis.

The WhiteSource study found that six in ten developers report they either get absolutely no secure code training or they’re only required to go through a cursory annual event. Fewer than 20% say that their employers provide any kind of training tools to allow them to train themselves independently on secure coding best practices—a key learning modality for many devs.

Security as Code is Still Mostly a Pipe Dream

A big factor for DevSecOps success is developer empowerment—when developers can implement security checks and features with as little handholding or manual intervention from security teams as possible. Automation of security checks a crucial part of this, but many DevSecOps visionaries also believe that security as code should play a vital role as well. When security engineering teams can translate policies into code, can provide ready-made security features through templates, can curate code libraries, and otherwise offer technical guard rails for DevOps teams, that’s when the DevSecOps machinery truly hums.

The recent Building Security in Maturity Model (BSIMM) report, BSIMM11, offers some clues on the current state of AppSec maturity across large organizations. The study showed that while 90% of organizations have implemented some form of lifecycle governance to provide security conditions for release—such as gates, checkpoints, and milestones—almost none are doing this primarily through code. Just one in 130 studied organizations reported that they integrate software-defined lifecycle governance into their SDLC. The StackRox study was a little more optimistic, but even that showed that just 16% say they are implementing security policy as code. Even at a less sweeping scale, security implementation of coding guardrails is inconsistently leveraged. The Ponemon study reported that just 51% of developers say their security counterparts provide code libraries or templates that address key security issues.

Cloud-Native Security Remains a Reach Goal

Meantime, when it comes to the operational side of delivering software, security struggles to keep up with the pace of innovation in cloud-native technology. The StackRox study found that an overwhelming nine in ten DevOps organizations have experienced a security incident in their Kubernetes and container environments during the last year. The biggest one by far is an exposure or incident caused by detected misconfigurations.

Poorly run container security is also holding up the pace of innovation at many organizations Approximately 44% report that they’ve had to delay or slow down application deployment to production due to container or Kubernetes security concerns.

Taken together these six signs indicate that while progress is being made, most enterprise organizations still need to dedicate considerable effort and investment in order to achieve higher levels of DevSecOps collaboration.