DevSecOps: 3 Things Infrastructure Pros Should Know

As enterprises have begun adopting DevOps practices, they've experienced numerous benefits like greater agility, increased productivity and improved application quality. However, DevOps has generally not lived up to expectations when it comes to security.

In theory, DevOps should improve security, but that has not always been the case in practice. A 2016 HPE survey on application security and DevOps found that 99% of respondents believed that DevOps offered the opportunity to improve application security. However, most of those polled felt that DevOps in itself had little to no actual impact on application security adoption in their organizations.

In fact, many IT pros say that DevOps principles and security seem to be at odds with each other. The 2017 DevSecOps Community Survey from Sonatype revealed that 58% of IT pros believe security is an inhibitor to DevOps agility.

This reality has spawned an offshoot within the larger DevOps movement called "DevSecOps," which promotes integrating security throughout IT. Gartner first began using the term DevSecOps in 2012, and the idea has been garnering a lot more interest recently, particularly as security breaches and ransomware attacks dominate the news.

Here are three key things infrastructure professionals should know about DevSecOps:

1. Everyone does security

If the DevSecOps movement has a mantra, it's this: "Everyone is responsible for security." Adherents believe that the traditional siloed approach, where the security team has the primary responsibility for all security matters, has slowed innovation and resulted in IT environments that are less secure than they should be.

On the DevSecOps blog, DevSecOps advocate Shannon Lietz wrote that the intent of DevSecOps is to build on that mindset of an all-inclusive security responsibility "with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required."

For infrastructure professionals, that means making decisions and conducting day-to-day operations with one eye on security, rather than assuming that the security staff will handle security needs.

2. DevSecOps requires collaboration

Just as DevOps requires developers and operations personnel to work together more closely, DevSecOps means that developers and operations personnel must collaborate with security staff.

In the past, some security teams have developed a reputation for saying "no" to projects or for slowing down initiatives. As a result, developers and operations personnel have sometimes cut security out of the loop rather than go through the effort required to get their approval. But for DevSecOps to work, developers and infrastructure professionals have to go back to talking with the security folks.

securityabstract.jpg

In the Sonatype report, DevSecOps evangelist DJ Schleen wrote, “Business needs require software to be developed and shipped in a timely fashion. Developers want to code the software in the most optimal way possible. The operations team wants the application to be highly available and stable. And the security team wants it to have no vulnerabilities and low risk to the organization. This isn’t a situation where having one team succeeding means another has to falter – rather it’s a perfect ecosystem for collaboration.”

3. DevSecOps requires cultural change

Implementing DevOps requires a big cultural change, and so does implementing DevSecOps. Several groups and individuals have attempted to describe this cultural change by coming up with a "DevSecOps Manifesto." The manifesto at DevSecOps.org stresses that security pros need to alter their approach; through security as code, they can learn how to to operate and contribute value with less friction.

DevSecOps blogger Larry Maccherone has a separate manifesto that focuses more broadly on the cultural change necessary throughout the IT organization. He calls for empowering developers and other staff to make security decisions rather than relying on policy enforcement mechanisms.

"Policies frequently get ignored and the policies-with-teeth approach encourages development teams to hide information and applications from that security apparatus," he wrote. "On the other hand, if you assume that development teams want to their best and that they just need help understanding how to do it, you create a completely different dynamic. Suddenly, the security leaders are helping rather than policing the development teams."

That sort of cultural change can only occur with active support and encouragement from the top of the organization. And as CIOs and IT managers become increasingly concerned about security threats, many are looking for new approaches that can help them increase their security profile.

Infrastructure pros shouldn't be surprised if they start hearing their bosses talk about implementing DevSecOps. While this approach will mean doing some things differently, it could be tremendously beneficial for organizations, and developing the new skills that DevSecOps requires could also help individuals further their careers.