Gartner Blog Network

Vulnerability Management in DevOps-style IT?

by Anton Chuvakin  |  June 4, 2019  |  5 Comments

As we mentioned here, the team (primarily Augusto and Anna, really) have started a project related to vulnerability management (VM) in “modern” (emerging, new, novel – the term matters not here) IT environments. The spotlight has been mostly concentrated on two technical environments:

  • Public cloud (mostly IaaS, but perhaps some PaaS)
  • Containers….

… and on DevOps (and perhaps broader “agile-style” IT) as the corresponding “modern” process. So, the term “modern” here applies to both technology stack (cloud, containers and of course containers in the cloud) and practices (DevOps and friends).

Now, we all know that largely mythical DevOpsSec / DevSecOps (defined here as simply “DevOps practice/culture that is not altogether negligent of security requirements or activities”) does happen at some places in real life.

If you have such an environment, here is what we’d like to know in regards to vulnerability management. But before proceeding, please note that the questions do not – NOT – apply to vulnerabilities in custom software and other appsec issues, the scope here is vulnerability assessment (VA), not DAST:

  1. Do you include vulnerability assessment (VA) in your DevOps processes in any way?
  2. How does the process look like? Who owns this process and how did security managed to get added to this? [I guess I imply here that security does not own this…please correct if wrong]
  3. Does security have “veto powers” to reject deployments due to vulnerabilities?
  4. Do you assess images (containers, virtual machines, etc) before production?
  5. If so, do you use static (without running code) or dynamic (launch and then connect/scan) methods?
  6. Do you assess running images during production? [please don’t remind us that this is stupid. people do all sort of stuff other people consider stupid. grow up :-)]
  7. Do you rely on container (Docker) or cloud vendor tools or dedicated vulnerability assessment tools for the assessment?
  8. In fact, do you utilize container-specific tools or general purpose VA tools that have container assessment functionality?
  9. Do you only remediate/replace images or do you ever see a need to remediate a runtime environment? [see comment above related to reminding us…]

There you have it – help make our team’s research more grounded in the real world…

Posts related to this project:

Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research

Category: vulnerability-management  

Anton Chuvakin
Research VP and Distinguished Analyst
8 years with Gartner
19 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio

Thoughts on Vulnerability Management in DevOps-style IT?

  1. Jeff Hall says:

    I had a client actually tell me a while back that Kubernetes, DevOps and continuous deployment was much more secure than traditional applications and did not need VA nor a firewall or any other traditional security stack devices. When they failed their penetration test, they were stumped.

  2. Coreos aka Red Hat aka IBM has an interesting tool in this space for assessing containers (

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.