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)
… 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:
- Do you include vulnerability assessment (VA) in your DevOps processes in any way?
- 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]
- Does security have “veto powers” to reject deployments due to vulnerabilities?
- Do you assess images (containers, virtual machines, etc) before production?
- If so, do you use static (without running code) or dynamic (launch and then connect/scan) methods?
- 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 :-)]
- Do you rely on container (Docker) or cloud vendor tools or dedicated vulnerability assessment tools for the assessment?
- In fact, do you utilize container-specific tools or general purpose VA tools that have container assessment functionality?
- 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:
- Is Vulnerability Management Hopeless?
- Considering Remediation Approaches For Vulnerability Prioritization (by Augusto)
- Upcoming Vulnerability Management Research (2019)
- Does Vulnerability Assessment Even Matter?
- We Scan and We Patch, but We Don’t Do Vulnerability Management
- WannaCry or Useful Reminders of the Realities of Vulnerability Management
- Critical Vulnerability Kills Again!!!
- What is Your Minimum Time To Patch or “Patch Sound Barrier”
- Patch Management – NOT A Solved Problem!
- On Vulnerability Prioritization and Scoring (2011!)
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
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.
Wow, this is truly dumb. New and untested infra for which you also lack skills is more secure because … eh…eh…eh…… 🙂
Coreos aka Red Hat aka IBM has an interesting tool in this space for assessing containers (https://github.com/coreos/clair).
Thanks for the pointer, will check it later today
Looks like Quay  is sometimes part of this tool-chain. As they say in their own documentation: “Quay Enterprise supports scanning container images for known vulnerabilities with a scanning engine such as Clair.”
Note: Quay acquired by Coreos (2014) acquired by Red Hat (2018) acquired by IBM (tbd… 2019?).