Over a million developers have joined DZone.

Devops, Security, or Both: Who Holds the Reins to Container Deployment and Management?

DZone's Guide to

Devops, Security, or Both: Who Holds the Reins to Container Deployment and Management?

Is there a correct answer to this question? Gartner says this is a question of rapidly-increasing importance. Read on for some insight.

· DevOps Zone ·
Free Resource

Automatic continuous monitoring keeps continuous deployment pipelines flowing smoothly and efficiently. Try Instana APM to automatically monitor containers and microservices!

The DevOps-Security hybrid model is not a new thing. Gartner first introduced this model nearly five years ago. It was driven by the need to define where DevOps’ responsibility for security starts and ends, and how security teams can facilitate a streamlined process for building and deploying software in a secure manner.  

Since then we’ve come a long way and today this model is often referred to as DevSecOps. The beauty of this hybrid model is that it integrates the best of both worlds – delivering value that is greater than the sum of its individual parts.

In the container space, DevSecOps becomes even more relevant and actionable. Until recently, DevSecOps wasn’t so easy to achieve due to the lack of standardized, usable technology and tools. But now, the path to DevSecOps is open.

Security Is Not Traditionally a DevOps Thing – and Vice-Versa

Let’s take a look at the “traditional” roles of DevOps and security.


The DevOps movement sprung up as a push to get developers (the dev part) and operations (ops, the people who manage servers) a little closer. In the container space, rapid development cycles mean that DevOps tend to perceive traditional security processes and controls as impediments - stumbling blocks that they need to address but don’t necessarily have the time or mindset to handle.

In container environments, images are assembled by developers from self-sourced and/or open source components. This places tremendous power in the developers’ hands, and as Spiderman has taught us: with great power comes great responsibility. For reasons of preferring expediency over security, developers may choose to use unvetted code. Or they may inadvertently include code with known (or unknown) vulnerabilities. Either way, this can represent a serious security risk.

At the same time, developers can’t be expected to know and address all security risks. Security is not their main responsibility; creating and running applications is. This means that they can’t afford to dedicate a large portion of their time to security checks.

Security Professionals

Security teams are traditionally responsible for creating and enforcing the procedures and policies that determine what constitutes acceptable vs. unacceptable risk. They may not be the ones fixing the vulnerabilities, but they do decide which vulnerabilities must be fixed. In order to accomplish this, Security requires visibility and enforcement capabilities over the process and outcome. They need to know which containers are running where, and be able to establish a clear container security checklist.  

This is good in theory. The problem is that rapid container development cycles strain traditional security processes and controls. They truly can’t keep up with the pace of change. In some organizations, we see that they have tried to cope with this by periodically shifting security experts into their DevOps team. This is great for the short-run but what about the long-run? That’s why we see a steady shift towards the combination of both DevOps and Security.  

By collaboratively and transparently integrating security at multiple points in DevOps workflows, the new DevSecOps model minimizes the impact on agility and speed while maximizing the security of the build and ship process.

This process is often referred to as “shifting security left” – moving security practices into the early phases of design and coding, instead of applying them haphazardly at the last minute before release. The DevSecOps model offers a security schema that fits the way container developers think and work – incremental, automatic, efficient, and repeatable.

How to Start Talking DevSecOps?

To facilitate implementation of the DevSecOps model, security controls must be automated within DevOps toolchains. From a process standpoint, security needs to start “talking DevOps”, not the other way around. The tools used need to be transparent to DevOps teams, and shouldn’t impede DevOps agility – yet at the same time fulfill legal and regulatory compliance requirements, with full control over policy and visibility given to security teams.

Container technology is probably the great enabler of DevSecOps. Not only does it make for rapid, repeatable application development and deployment cycles, but it also makes it possible for them to be more secure. Containers are immutable and therefore are never patched in runtime, but simply replaced with new versions. This shifts much of the security controls to the “left”, i.e., upstream into the development cycle.

Automatic real-time observability is critical to getting the full benefit of CI/CD. Hear @DevOpsDon discuss how Franklin American Mortgage Company cut their new application deployment time from 6-12 months to 2 weeks with the help of Instana APM.

devops ,security ,containers ,software development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}