Most vulnerability management programs were designed around a set of assumptions that are no longer true. Monthly scans. A 30-day SLA for critical findings. Human analysts triaging results and deciding what to patch first. A dedicated Patch Tuesday cadence that gives you a week or two to respond before the noise gets loud.

Those assumptions were built for a world where developing a working exploit from a published CVE took weeks, sometimes months. Skilled attackers, plenty of time, a fair amount of manual work. The defender had a window. Not a comfortable one, but a window.

That window has closed. AI has compressed the exploit development timeline from weeks to hours, and in some cases, to less than a day. A critical vulnerability published on Monday morning can have working exploit code circulating by Monday afternoon. Your 30-day SLA doesn't account for that. Neither does your monthly scan schedule.

The Problem with How Most Programs Are Built

Traditional VM programs optimize for coverage and compliance, not speed. The typical architecture looks like this: authenticated scans run weekly or monthly, results flow into a ticketing system, analysts triage based on CVSS score, and patches get deployed on a quarterly cycle with critical exceptions handled manually.

This architecture has three failure modes in an AI-speed threat environment:

  1. Detection lag: A vulnerability that's actively being exploited at scale can sit undetected in your environment for weeks if you're running monthly scans. By the time you see it, you may already be compromised.
  2. Prioritization failure: CVSS scores are static. A CVSS 7.5 that's being actively exploited in the wild is more dangerous than a CVSS 9.8 with no known public exploits. Triage based on CVSS alone consistently prioritizes the wrong things.
  3. Remediation bottleneck: Manual remediation workflows, ticket, assign, schedule maintenance window, patch, verify, can't operate at the speed the threat environment now demands for truly critical vulnerabilities.

CISA KEV Is the Floor, Not the Ceiling

The CISA Known Exploited Vulnerabilities catalog is a valuable resource, and every VM program should be treating KEV additions as immediate priority. But treating KEV as your primary prioritization signal is a mistake. By the time a vulnerability appears in the KEV catalog, it's already being actively exploited in production environments. KEV is a floor, the minimum bar for things you must patch, not a ceiling for what you should be tracking.

The better signal, especially for vulnerabilities that haven't yet reached KEV status, is EPSS: the Exploit Prediction Scoring System. EPSS uses a machine learning model trained on real-world exploitation data to predict the probability that a given CVE will be exploited in the wild within the next 30 days. A CVE with a CVSS score of 7.0 and an EPSS score of 0.94 is far more urgent than a CVE with a CVSS score of 9.5 and an EPSS score of 0.02. EPSS tells you what attackers are actually interested in. CVSS tells you how bad it could theoretically be.

Running CVSS and EPSS together, filtered against your actual asset inventory and exposure surface, gives you a genuinely defensible prioritization model, one that holds up when your CISO asks why you patched X before Y.

"If a critical CVE drops Monday morning, when does your team know about it? When does it get triaged? When does remediation start? If you can't answer those questions in hours, your program isn't architected for the current threat environment."

What AI-Speed VM Actually Requires

Rebuilding a VM program for AI-speed attacks isn't about buying a new scanner. It's about rearchitecting the entire detection-to-remediation workflow. The components that matter:

The AI Threat Acceleration Is Real

This isn't theoretical. Security researchers have demonstrated AI-assisted exploit development that reduces the time from CVE publication to working proof-of-concept from weeks to hours. The Cloud Security Alliance's AI security research has documented how AI tools are lowering the barrier to entry for exploit development, meaning not just elite threat actors but mid-tier actors now have access to capabilities that were previously out of reach.

The implication for defenders is straightforward: the population of attackers who can operationalize a new vulnerability within 24 hours of publication has grown dramatically. Your VM program needs to be faster than the fastest realistic attacker timeline, not faster than the average one.

The Business Framing

The window between "vulnerability publicly disclosed" and "actively exploited at scale in production environments" used to be measured in weeks. It is now measured in hours for the vulnerabilities attackers care about.

A VM program with a 30-day critical SLA doesn't offer 30 days of protection. It offers a 30-day liability, a documented, auditable period during which your organization knew about a critical vulnerability and hadn't remediated it. In regulated industries, that liability has legal and compliance dimensions beyond the technical risk.

Rebuilding your VM program for AI-speed attacks is not a future investment. It is the current minimum bar for operating a defensible security program. The organizations that move first will have the metrics, the playbooks, and the institutional knowledge to operate at that speed. The ones that wait will be doing it reactively, under pressure, after an incident that was avoidable.