5,558 IT professionals from more than 150 countries involved in DevOps self-identified their level of maturity. What emerged from a subsequent survey was a close correlation between elite DevOps and DevSecOps — there is a marked shift left for security in elite DevOps teams.
The survey results (PDF), published by Sonatype, confirm DevSecOps as a key and growing approach to effective software development. This is despite the widespread acceptance that including security into DevOps hinders the pure development of software: 48% of developers believe that while security is important, they don’t have enough time to spend on it.
This is confirmed by the low opinion of ‘competitive advantage’ as a reason for including security. While it has always been a fundamental argument for DevOps, and perhaps the main reason for adopting DevOps, competitive advantage is not considered a motivation to move on to DevSecOps. Less than 6% of the elite developers consider competitive advantage as the primary motivation for using DevSecOps. Other factors are at play. More than one-third of the developers cite risk management as the prime motivation, with almost one-quarter simply believing that building in security is synonymous with building in ‘quality’. More than 23% are motivated by compliance requirements; and almost 10% are responding to customer requirements.
With the inclusion of security having a negative impact on development efficiency, the elite teams have turned to automation to make things smoother. DevSecOps practices are 700% more likely to have fully integrated and automated security practices across the DevOps pipeline. They also have increased feedback loops that enable security issues to be identified directly from tools.
Fifty-one percent of respondents from the elite teams say they leverage automated security products to identify vulnerabilities in containers, while only 16% of those without DevSecOps said the same thing.
There is little in this survey that actually proves a bottom-line advantage in using DevSecOps. It does support the increasing compliance requirement for ‘security by design’ — but apart from that, the shift to DevSecOps is almost an instinctive belief that this is how software development should be done. “The DevSecOps community,” says Derek Weeks, VP and DevOps advocate at Sonatype, “has shown us that elite organizations are performing significantly less manual work, seamlessly blending security into their developer’s world, and are better prepared for remediating security incidents as they arise, when compared to their counterparts without DevOps practices.”
Hasan Yasar, technical manager and adjunct faculty member for Carnegie Mellon’s Software Engineering Institute, adds, “We must all recognize security is a living thing and organizations should be prepared to prevent and respond to breaches at any moment within their application lifecycle. It is difficult to imagine proper cybersecurity hygiene and sufficient preparations for a breach without DevSecOps in place.”
But there is no direct correlation between DevSecOps and fewer or less-costly breaches. In fact, the elite group — more likely using DevSecOps — reported a higher percentage of breaches than those with less mature practices. This is difficult to understand by DevSecOps proponents. Sonatype suggests, “With less visibility and fewer controls surrounding open source in less mature organizations, we suspected the lower breaches in the immature group were more an indication of lack of breach awareness. What is clear, however, is that the elite development groups that use DevSecOps practices also operate other best practices.”
Those best practices are well-illustrated in the elite teams’ attitude towards the use of open source components. The same need for speed in software development that leads developers to say they have little time for good security practices also leads to the massive use of open source software — it is quicker and easier to use open source code than spend days or even weeks on coding something new.
But this same open source code can introduce vulnerabilities: Heartbleed, Poodle, Bash and Struts2 are just the high-profile examples. A study by Synopsis in May 2018 showed that 96% of the more than 1000 codebases it examined contained open source components — and 78% of those contained at least one open source vulnerability (the average per codebase was 64).
The Sonatype study shows that the elite development teams likely to use DevSecOps practices are also more likely to control their use of open source components. They are 117% more likely to manage their software supply chains. Sixty-two percent have an open source governance policy, and 53% maintain a complete software bill of materials so they know what components have been used where.
The same principle applies to software audits. Eighty-two percent of the elite group have tools to monitor and audit all environmental changes in the SDLC (compared to 59% in the other group). Similarly, 75% have all application-level credentials encrypted (compared to 46% in the other group). And 81% have a cybersecurity incident response plan in place (compared to 63%).
While there are no specific figures to indicate that DevSecOps leads to fewer subsequent breaches or lower breach costs, this survey clearly associates the adoption of DevSecOps with the adoption of other software development best practices. It simply seems to be the right thing to do. This survey doesn’t specifically demonstrate it, but Jonas Manalansan from Northrup Grumman sums up the general perception: “Successful DevSecOps projects are able to bring security into the DevOps processes without slowing them down. All in all, DevSecOps delivers reduced cost, reduced development churn, and reduced application attack surface, which delivers higher security and higher confidence to the organization.”
Related: Best Practices in Securing DevOps