Call us now

Enterprises still aren’t investing enough in DevOps security and some don’t know what DevOps is, study says

Enterprises are spending a lot of time, money and effort to speed up their software development, but they still don’t focus on DevOps security. This is the general gist of a new study by Hewlett Packard Enterprise (HPE).

In fact, there’s still some quite serious barriers between DevOps and security teams. The HPE survey even points out cases where developers don’t even know their colleagues in the security teams. Even worse, 90% of security IT pros say ensuring proper security to the applications has become more difficult since their organizations deployed DevOps.

Wait. What is DevOps?

HPE has found that some organizations don’t even know what DevOps means. 30% of respondents have replied their organization isn’t practicing DevOps and yet, they actually are doing processes from DevOps. This creates an even deeper confusion among companies and teams.

The survey goes to try and make more sense of what DevOps actually is in accordance with the actual activities by organizations. There are several practices of DevOps which are commonly used: Integrated teams, Automated testing, Frequent development, Continuous integration, Application security testing automation, Continuous performance monitoring and Continuous deployment.

The main characteristic to DevOps is frequent deployment, HPE says. Forrester expects that while in 2010 an organization had an average of four application release per year, by 2020 this will jump to 120 releases for a 30x increase.

Gartner on the other hand expects that by the end of 2016 50% of enterprises should have started to actively use DevOps. HPE says it survey found that 90% of surveyed organization have at least some form of DevOps already in place.

“We don’t need no security”

Sadly, security is rarely among them. The study found that 99% of respondents agree that adopting a DevOps culture could improve application security. But then comes the reality. 17% of organizations say they aren’t using any technologies to protect their applications. Something, which the HPE survey rightfully calls “shocking”. A mere 20% say they do secure SDLC testing throughout development.

“The overwhelming sentiment emerged that DevOps in itself has had little to no impact on application security adoption or effectiveness in their organizations. When asked about the effect of DevOps on key application security use cases such as frequency and thoroughness of testing, the result on a scale of 1 to 5 was 3.38, a statistically neutral (no effect) finding”, the survey says.

HPE has found other problems, too. Out of the top 10 US Bachelor’s Computer Science programs, none require a security class to graduate. Furthermore, the team looked at over 100 job openings for software developers by Fortune 1000 companies. None required any experience or knowledge in secure coding.

There’s also the constant pressure to bring applications to market which cuts time and effort spent on security. In short, security has pretty much being pushed back. It’s an afterthought with it being dealt with if and when there’s an issue.

The solutions are already available

So, how to solve these problems? HPE recommends that “security should be a shared responsibility across the organization to eliminate barriers”. Enterprises should also leverage automation and analytics into security testing and solve simpler problems this way. This should free up the IT pros to work on the high priority risks.

Finally, companies should make more effort into raising awareness for security. They should also fill in skill gaps with additional trainings. This includes proper security trainings for DevOps and software developers, too.

“Organizations should integrate security tools into the development ecosystem to allow developers to find and fix vulnerabilities in real-time as they write code. This makes it easy and efficient to develop securely, and educates the developer on secure coding in the process”, HPE says.

Image credit: Flickr (CC) / Idaho National Laboratory