Despite it being considered an essential practice, most organizations still find it difficult implementing security into their DevOps efforts. It’s not that they don’t want to, they say they do, it’s that they just haven’t provided their developers the tools, processes, or even training to get it done. These are the findings of a report recently released by application security vendor Checkmarx.
The report , conducted by FreeForm Dynamics along with The Register, includes responses from 183 respondents from around the world, with majority holding software development, IT and security professional titles, and they detail their biggest barriers to securing software today within the DevOps cycle.
While this report doesn’t include input from many organizations, especially considering that the responses are geographically disperse, the findings do match what I’ve been hearing from CIOs, CISOs, DevOps leaders, and IT executives in my reporting.
The report found a number of gaps between security as it should be and security as it is within their DevOps organizations. For instance, 96 percent of respondents believe the proper training of secure code development is “highly desirable” to “desirable” yet only 11 percent of responds said that they train their developers “generally very well” and 33 percent said they were mixed and could improve. Likewise, 94 percent of respondents find “shifting left” of security testing as desirable so that testing is an embedded part of development, yet only 11 percent say they are doing this well and 36 percent say they could do better.
There were similar results when it came to the integration of security into the entire DevOps process, operations security, and likewise security specialists knowing how to deal with rapid, iterative delivery.
When it came to DevOps toolsets, such as code scanning tools to identify potential security flaws early in the process, 89 percent agreed it was important, but only 12 percent are doing it well. More than half are doing it mixed to poorly. Similar results were found when it came to API security, open source security, and tools that help align security risks with business impact.
All of this is true despite 57 percent of respondents saying software security is a boardroom level discussion.
While that is an accurate reflection of the importance of software security risks posed to the organization, it seems executive leadership and the boardroom doesn’t see it that way. Discouragingly, 79 percent of respondents said that getting senior management to approach funding for security training is a challenge, and 76 percent said that their executives don’t really care about how software is delivered quickly, frequently and safely, they just want it done.
Hints at the breakdown in DevOps culture also surfaced in this report. Surprisingly, 83 percent said that the ability to define clear ownership and responsibility in relation to software security is a big challenge and 72 percent agreed that different teams and disciplines within UT remain reluctant to trust each other.
These types of leadership, trust, and issues around software responsibility were some of the challenges DevOps was designed to fix within organizations. But it appears, in many, DevOps driven with security best practices itself remains an elusive unicorn.
It’s not really acceptable today, as software has become central to every aspect of nearly every enterprise. As software use increases, and the speed of development increases, it’s imperative that software quality and security controls keep pace.