Is Vulnerability Management Dead? A Security Architect's Take

Is Vulnerability Management Dead? A Security Architect's Take

Speaker: Snir Ben Shimol

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~7 minutes

TL;DR

Snir Ben Shimol, CEO and co-founder of Zest Security and a veteran of Varonis and Prisma Cloud, argued that traditional vulnerability management is broken — not because the tools are bad, but because visibility without a remediation path is not security. Drawing on research across hundreds of enterprises, he proposed a cloud-specific survival framework built around enrichment, infrastructure-as-code correlation, mitigating controls, and AI-assisted triage.

Introduction

The title was provocative by design: "Is Vulnerability Management Dead?" By the end of the talk, Ben Shimol's answer was effectively yes — in its current form. The evidence he assembled was not theoretical. In research conducted across enterprises with more than 10,000 employees and significant cloud footprints, every organization studied maintained an ongoing backlog of over 100 critical vulnerabilities and misconfigurations, despite having visibility tools, having prioritized findings, and having opened remediation tickets.

Knowing about a problem and being able to do something about it are, it turns out, very different things. Ben Shimol built his case around a simple analogy: if you are in Mexico drinking margaritas and you know your apartment door is unlocked in New York City, that knowledge does not make you more secure. Visibility without action is theater.

What the Research Actually Shows

▶ Watch: Research findings — backlogs, exploitation timelines, and organizational friction (07:20)

Zest's research produced numbers that should alarm practitioners. Sixty-two percent of SOC-reviewed security incidents traced directly to known vulnerabilities or misconfigurations — problems that were in a ticket queue somewhere. The Verizon Data Breach Investigations Report confirmed a parallel finding: exploitation of known vulnerabilities now outpaces phishing as an initial access vector. And Mandiant's data shows the time to exploit has compressed to five days for some vulnerabilities, with some exploitations occurring in under an hour from disclosure.

Against that backdrop, the operational reality Ben Shimol documented is staggering. Security engineers spend six to eight working days per month on prioritization and analysis alone — before any remediation begins. Changing a cloud misconfiguration takes close to a full month on average. Remediating an application vulnerability takes more than eight weeks in many organizations. With a five-day exploitation window, those timelines are incompatible with meaningful security outcomes.

The root causes are structural: 49% of backlog items sit unresolved because teams need time to determine the best remediation path; 26% involve risk that genuinely cannot be remediated (legacy healthcare systems, business-critical infrastructure that cannot be touched); 25% are blocked waiting for other departments. Security teams are not the ones who fix vulnerabilities — they are the ones who identify them and then wait for engineers, DevOps, and application teams to act. With more than four people involved in the average remediation, coordination overhead alone can extend timelines to impractical lengths.

Why Cloud Makes This Harder

▶ Watch: Cloud-specific complexity — misconfigurations, SCA ownership, and patching (13:50)

On-premises vulnerability management is largely a patching problem: find the unpatched system, apply the patch, done. Cloud is categorically different. Misconfigurations — publicly exposed services, unencrypted sensitive data, microservices with paths to privilege escalation — are not vulnerabilities in the traditional sense and do not have a "patch" to apply. They require understanding the intended state of an environment, the blast radius of a change, and the downstream effects on dependent services.

The ownership problem compounds this. Ben Shimol posed a question to the audience: does software composition analysis (SCA) belong to the vulnerability management team or the application security team? The answer varies by organization, and the confusion means that findings in container base images — which are simultaneously a DevOps concern and a security concern — frequently fall through the cracks between teams. He documented cases where developers fixed a misconfiguration in the AWS console and opened the same ticket the following week when Terraform re-deployed the original misconfigured state. The fix was applied to the runtime environment, not to the infrastructure-as-code template that defined it.

The Survivor Kit: A Practical Framework

▶ Watch: Enrichment layer, cloud guardrails, and infrastructure-as-code correlation (21:30)

Ben Shimol's framework for making vulnerability management functional again has several layers, ordered from foundational to advanced:

Foundational layer: Visibility scanners (CSPM, SCA) are a solved problem — open-source tools work, and teams do not need to spend a million dollars on them. A unified data layer that aggregates findings from all sources into a single repository is the first actual requirement. Cloud inventory with enrichment — what assets are publicly accessible, what contains sensitive data — follows from there.

Enrichment layer (free): CVSS, KEV (the CISA Known Exploited Vulnerabilities catalog), and threat intelligence from providers like VulnCheck give context that scanners alone cannot. VPC and gateway metadata, CDN and load balancer data, and business criticality tags (which should be applied to repos, systems, identities, and assets by the teams who own them) are all extractable from existing cloud infrastructure without additional tooling.

DevOps correlation (moderate to advanced): Understanding what is managed by Terraform, CloudFormation, Pulumi, or other IaC tools is the key to sustainable remediation. When a finding traces back to a specific Terraform module, the fix can be applied where the configuration is defined rather than where it manifests. For Kubernetes environments, base image mapping — connecting container vulnerabilities to the specific images that introduce them — is necessary to prioritize patching effort. GCP presents specific challenges because it wraps Kubernetes in ways that obscure the correlation.

Cloud guardrails (advanced but high-value): AWS Service Control Policies and Resource Control Policies can deny specific malicious activity patterns even when the underlying vulnerability cannot be immediately remediated. Ben Shimol gave the example of Lambda functions storing secrets in environment variables — a pattern that generates repeated findings. An SCP can be written to deny queries that would access those secrets, reducing exploitability by roughly 80% without touching the application code. This is not a substitute for remediation; it is a structured way to live with risk while working toward a fix. The Next.js vulnerability that hit on a Saturday was cited as a real-world example where WAF and RASP tools in blocking mode bought teams the time to remediate properly the following week.

AI as the Remediation Accelerator

▶ Watch: Using AI and LLMs to automate remediation paths (33:15)

The final layer of the framework is where AI enters. Ben Shimol's argument was specific: many remediation decisions cannot be automated with traditional rules because they are inherently contextual. A given CVE might have five or six valid remediation paths depending on the cloud environment, the IaC tooling in use, the secret manager being used, and the specific asset configuration. Rules cannot encode all those branches. LLMs can reason across them.

Concretely: feeding an LLM the infrastructure-as-code files for a cloud environment alongside a misconfiguration finding and asking whether the vulnerable asset exists in any Terraform state files is a forensic task that security engineers currently do manually and slowly. An LLM can do it quickly. Similarly, identifying the single patch that resolves the largest number of CVEs across a set of containers is an optimization problem well-suited to AI-assisted analysis.

Ben Shimol flagged that different models perform better for different tasks — OpenAI's o3 model for patching reasoning, Anthropic's Claude for code review and IaC-specific remediation generation — and emphasized that inputs to AI models should never include actual secrets or production credentials.

Notable Quotes

"62% of incidents tied directly to vulnerabilities and misconfigurations. Knowing about an open front door does not make you more secure." — Snir Ben Shimol (▶ 06:10)

"50% of risk cannot be remediated. Half your backlog will end up with two things: accept risk, or no patch available." — Snir Ben Shimol (▶ 24:40)

"Involve your mitigating controls in vulnerability management. But do not get addicted — mitigating controls can be bypassed. Remediation is the goal." — Snir Ben Shimol (▶ 30:00)

Key Takeaways

• Visibility without remediation capacity is not security. Every enterprise in Zest's research had prioritized, ticketed backlogs of over 100 critical findings — and still experienced incidents tied directly to those findings.
• The exploitation window is now five days or less. With remediation timelines measured in weeks, the gap between "known" and "fixed" is where nearly all cloud breaches occur.
• IaC correlation is the missing link. Fixing vulnerabilities in the runtime console while leaving the IaC template unchanged means the same finding re-appears every deployment. Trace the problem to its source.
• Cloud guardrails are a legitimate risk reduction tool. SCPs and RCPs can reduce exploitability significantly while longer remediation tracks proceed — as long as teams treat them as mitigation, not resolution.
• AI is necessary to reach a five-day remediation timeline. The contextual complexity of cloud environments — multiple IaC tools, multiple teams, multiple valid remediation paths — is beyond the reach of rule-based automation. LLM-assisted triage and remediation recommendation is the path to closing the gap.