Continuous Delivery Demands Continuous Security

DevOps has gone mainstream and organizations are racing to take advantage of tools and practices designed to help develop better products faster. Automation is a key component of DevOps, but as with all things security is somehow the last element invited to the party. As businesses embrace DevOps and adopt continuous delivery, they will also need to implement continuous security to stay ahead of attackers.

Many organizations are moving to embrace DevOps and microservices. These technology trends depend heavily on automation, and that results in IT infrastructures changing at an unprecedented speed. It was already a challenge to keep up with the pace of security with a traditional IT environment, and now security professionals are faced with an exponentially more dynamic landscape to protect. Thankfully, the same tools that automate change can also be used to automate and accelerate security efforts.

Get the Report REPORT: 2015 Gartner Magic Quadrant for Application Security Testing (AST)

Slow and stable wins the race?

Change is often seen as the enemy of computer and network security. Security professionals work to understand the vulnerabilities that exist in the network and endpoints and take steps to remediate or mitigate them to reduce or eliminate the risk they pose. As soon as something changes on the network or a new application is introduced, that equilibrium is destroyed and the security professional has to start over to identify vulnerabilities and minimize risk.

“Today, security teams are constantly trying to keep up with security threats. Unfortunately, in most organizations, checking for vulnerabilities only happens when it’s time to deploy the finished system,” explains Colin Campbell, director of patterns and practices at Chef. “The tools, such as checklists, scans, and (often vague) documentation, result in point-in-time review that impacts the ability to deploy quickly and safely.”

Andrew Storms, vice president of security services at New Context, says, “The thing that stirs fear for a lot of security people with continuous delivery is the idea of constant change and sped-up processes. For some reason, security feels that when things go slow, they have more control and will be more secure. Somehow only having a monthly change window on production makes things better, unless of course there is a nasty zero day and everyone has to wait a month to get a patch distributed.”

Slow as the problem, not the solution

Nick Galbreath, founder and CTO of Signal Sciences, says that fixing vulnerable code doesn’t necessarily take very long in and of itself. He pointed out, though, that many vendors take 100 or even 180 days or more to develop and issue a patch.

There are a number of factors that contribute to this lag, according to Galbreath. Long, painful build processes and release cycles are one. A lack of confidence that a patch can be undone if it ends up breaking more than it fixes also adds additional testing and QA time to replace some of that paranoia with peace of mind before an update is deployed.

Most or all of these issues are addressed with a DevOps culture and a more rapid pace of development and deployment. When you combine DevOps with microservices and automation, you also get a more modular approach that can be easily rolled back or changed at the push of a button if any hiccups occur.

Check out the full story on TechBeacon: Keeping up with the pipeline: Automate security for continuous delivery.