DevOps has revolutionized how new applications are brought online, but it is also challenging how security teams do their jobs.

In theory, DevOps can make applications more secure by baking security into the Sofware Development Lifecycle from the earliest stages of that cycle. Right now, though, that’s not the case.

“While automation and team integration could lead to greater adoption of application security in the future, the current state is that most organizations are not implementing security within their DevOps programs,” noted a recent report by Hewlett Packard Enterprise on application security and DevOps.

“In mature security organizations, where application security is already an integral part of development, it continues to be prioritized as a critical DevOps component,” the report continued. “If a secure SDLC was not a disciplined practice before, it is often left behind in the rush to DevOps.”

1. Adjusting to Speed

One aspect of DevOps security teams must adjust to is speed. Eighteen-month development cycles are being reduced to six weeks or less. That severely impacts the time the team has to do due diligence.

Moreover, coding is being done by multiple teams. DevOps teams tend to be smaller and there are more of them so not only is code being produced more rapidly, but more infrastructure is changing more rapidly, too,  through automation and agile tools. “This breaks the traditional security approach in a pretty profound way,” Sami Laine, principal technologist at CloudPassage, said at a recent webinar.

It also requires that security tools be automated and orchestrated to match the speed at which the developers are working. Without a fully automated tool chain, security can bog down the DevOps process by hours or days. “This is fundamentally breaking the spirit and flow of the way DevOps should work,” Laine noted.

If an organization’s security tools are friendly to DevOps, most security tasks will be performed automatically in the same pipeline as the one used for producing the app. Only security issues that require human intervention will be flagged for developer action.

Instead of security erecting gates that code has to pass through before entering production, Laine explained, it needs to erect guardrails that allow developers to make mistakes but prevent them from creating disasters,

Tools and agility alone, though, don’t make DevOps and DevSecOps work, Laine noted. “It’s those things, plus a culture of respect and culture of collaboration,” he said.

2. Security’s Changing Role

Tension between security teams and developers have always been a problem due to conflicting goals. Developers want their software out of the pipeline as fast as possible. Security teams stand in the way of that with their testing and demand that developers go back to the drawing board to fix flaws.

There’s no room for that kind of tension in a DevOps environment. To reduce it, security teams need to alter their roles in the process.

Adrian Sanabria, a senior analyst with The 451 Group and who also participated in the webinar, sees security becoming a consulting organization within the enterprise. That shift will benefit security because it means security will be working more closely with developers. “We’re going to understand the constraints that they have,” Sanabria said. “We going to throw less things over the wall that shouldn’t be fixed or can’t be fixed easily because we understand the environment better.”

With the proper security automation tools in place, human intervention into DevOps can be kept to a minimum. “If there are any problems, they’re sent back to the developer,” Sanabria explained. “Security doesn’t even need to be involved in that transaction.”

Security involvement may be necessary if the developer has a question about the problem. Then security, wearing its consultant’s hat, can explain the severity of the problem, such as if you don’t fix it, the app will  be compromised within 10 seconds of going live.

3. New Skills

Security pros will also need new skills to better secure apps in a DevOps environment. Those include the ability to write code and scripts, as well as working with APIs. Those skills will be necessary for automating traditional security tasks and “baking” them into the development process. “No longer is it a question of baked-in versus bolted -n,” Sanabria said. “It’s just a question of how are you going to bake it in?”

Traditional security practitioners will remain relevant, he noted, although demand for infosec pros who have new skills is growing rapidly. He noted that in an informal survey of job listings he conducted, about 60 percent of them were looking for candidates with new skills.

DevOps is causing a change in security culture, Sanabria maintained. “In a lot of environments, people have described it to me as pulling off a Band-Aid,” he said. “Some people were able to make the shift, other people they had to either find different things for them to do or lay them off.”

“Talent acquisition becomes a really tough problem in this new environment,” he observed.

“In fact,” he added, “in some organizations, I’m seeing companies hiring developers and teaching them security because they find that easier than to take traditional security people with experience and to try to pull them over into this new world of new IT.”

White Paper - Proving Adherence to Software Security Best Practices

White Paper - Proving Adherence to Software Security Best Practices

Industry standards and the best practices for developing secure software. Please provide your email and name to receive your copy.

Success! Your copy is on the way.