Let this sink in: finding security vulnerabilities was never the bottleneck, vulnerability prioritization was. AI-scale discovery is about to make that impossible to ignore, and the teams that see it coming will pull ahead of the rest.

Here’s what kept me up this week. Anthropic ran a frontier model against some of the world’s most important systems and, in a matter of weeks, it surfaced more than ten thousand high- and critical-severity vulnerabilities. Then they said the part out loud that most of security has been avoiding for a decade: the constraint in cyber defense has already moved from finding vulnerabilities to patching them fast enough.

A little louder for the people in the back. The hard problem isn’t discovery anymore, It’s everything that happens after.

If you’ve run a security program, you already knew this in your gut. You were never short on findings. You were short on time, context, and a defensible way to decide what to touch first. AI just took the one thing you had too much of and gave you infinitely more of it.

More discovery is the wrong fix for a prioritization problem

Walk any show floor this year and you’ll see the same pitch in fifty booths: AI that finds more. More scanning, more coverage, more findings, faster. It’s an easy thing to sell because it’s an easy thing to measure. You can put “ten thousand vulnerabilities detected” on a slide and it looks like progress.

But if discovery was never the thing holding you back, then more discovery doesn’t help you, it buries you. A backlog you couldn’t clear at a thousand findings doesn’t become more tractable at fifty thousand. It may seem obvious to label this as a visibility problem , but it’s more nuanced than that. What you have is a “which of these can actually hurt me, and which do I fix first” problem, and pouring more raw findings into that is like fixing a flooded basement by turning up the tap.

The industry has a long habit of doubling down on the thing it already knows how to do, even when the evidence says the constraint has moved somewhere else. The teams that win the next few years won’t be the ones who find the most. They’ll be the ones who waste the least effort on findings that were never going to matter.

The math has been against “patch everything” for years

This isn’t a hunch. The data has been sitting in plain sight, and it’s brutal.

Across the published universe of vulnerabilities, only a small single-digit percentage are ever exploited in the wild. The Exploit Prediction Scoring System maintained by FIRST puts a fine point on it: if you remediate every vulnerability scored CVSS 7 or higher, the way most programs define “urgent,” you’ll cover roughly 82% of the ones that are actually exploited, but about 96% of that effort is spent on vulnerabilities that were never going to be touched. Ninety-six percent. That’s not a rounding error. That’s the overwhelming majority of your team’s nights and weekends spent on work that changed nothing.

And severity scores don’t even point you at the right targets. FIRST’s own research found that of all the CVEs scored 7 or higher, only about 2.3% were observed in actual exploitation attempts in a given month, while 28% of the vulnerabilities attackers actually used carried only medium scores. So a CVSS-first program is simultaneously drowning in false urgency and quietly deprioritizing more than a quarter of the things attackers are really exploiting. It gets the ranking backwards in both directions at once.

Meanwhile the volume keeps climbing. Something like 135 new CVEs are published a day, and the typical enterprise has the capacity to remediate maybe 10 to 15% of its backlog in a month. That gap was already untenable. Now imagine an AI discovery engine pointed at it. The arithmetic is getting worse and worse, until the point of breaking. 

When mean time to exploit goes negative, the patch race is over

This is the part that should reframe how every security leader thinks about this. While we’ve been arguing about scan coverage, the clock on the other side has run out.

Mandiant’s latest M-Trends report, built on more than 500,000 hours of incident response, estimates the mean time to exploit a vulnerability at roughly negative seven days. Negative. For a meaningful share of serious flaws, exploitation is happening before the patch even ships. The same report clocked the median hand-off from initial access to a follow-on attacker, often a ransomware crew, at 22 seconds, down from more than eight hours a few years ago.

But come back to that negative seven for a second, because it dismantles a foundational assumption. The entire patch-management paradigm assumes a sequence: vulnerability disclosed, patch released, defenders race to apply it before attackers arrive. That race is the whole mental model. But if exploitation precedes the patch, there’s no race to win. The starting gun goes off after the other runner has already crossed the line.

This is the genuinely interesting frontier, and I don’t mean that as a doom statement. It’s the opposite. Once you accept that you can’t patch your way to safety at negative-seven-day speed, you stop pretending the goal is a clean scan and start asking a better question: of everything that exists in my environment right now, what can actually reach me, and is it being touched? That question has an attainable answer. The patch race never did.

What makes a vulnerability actually matter

A vulnerability on a slide is a CVE and a severity score. A vulnerability in the real world is a specific thing, running in a specific place, reachable or not, exposed to the internet or not, sitting next to sensitive data or not, holding live credentials or not. The severity score knows none of that. It can’t. It was assigned in the abstract, by people who never saw your environment, before your environment existed.

So a critical-rated flaw on a workload that isn’t running, isn’t reachable from anywhere, and touches nothing sensitive is, in practice, noise. And a medium-rated flaw on a live, internet-facing service handling customer data is the thing that ends up in the incident report. Static severity ranks those two backwards, and almost every team is still triaging off it anyway.

The only place you learn which is at runtime. Not in the scanner’s model of your environment, but in your actual environment, as it’s actually running. It comes down to what’s executing, what’s exposed, what’s talking to what, and what’s sitting next to the data that matters.That context is what collapses ten thousand findings down to the twenty that deserve your week. Reachability turns a theoretical attack path into a real one or rules it out entirely. Runtime is the filter that the severity score can never be, because the severity score is a property of the vulnerability and exploitability is a property of your environment.

This is also why the discovery-engine arms race misses the point so completely. A better scanner gives you a longer list. Runtime gives you a shorter one. In a world where the inputs are about to be infinite, the only thing with leverage is the filter, not the firehose.

How to fix vulnerability prioritization by Monday morning

If I’m a security leader staring down this shift, I start by retiring the metrics that reward the wrong behavior. Scan coverage and total findings tell me how loud my tools are, not how safe my company is. A dashboard that’s green because we closed ten thousand low-consequence tickets while the one reachable, internet-facing, data-adjacent flaw sat open for a month is not a very helpful dashboard. 

The number that matters is time to fix the things that are genuinely exploitable in my environment, and whether that number is trending down. Everything else is motion pretending to be progress.

Three shifts follow from that, and none of them require waiting for a vendor:

First, prioritize on exploitability in context, not on severity in the abstract. Reachability, exposure, runtime activity, and data sensitivity are the inputs that separate the twenty from the ten thousand. A severity score on its own is a starting point, not a decision.

Second, assume exposure rather than chasing a clean scan. When the mean time to exploit is negative, “we’ll patch it before anyone finds it” is no longer a strategy, then continuous detection of what’s actually happening in your environment is the safety net that patching alone can’t be. Because it works even when the patch arrives second.

Third, point your AI budget at judgment, not just discovery. The valuable place to spend automation is on the part humans are slowest at: correlating reachability, exposure, and live behavior to decide what’s real, right now. Finding more was never the hard part. Deciding well, fast, at the scale the findings now arrive, is the whole game.

This isn’t unique to security. In the same work, titled “When AI builds itself”, where Anthropic showed how fast AI now finds vulnerabilities, they made a broader observation about their own engineers: as AI took over the writing and the testing, the scarce skill became judgment, deciding which problems matter and which results to trust. Computer scientists have a name for this. Amdahl’s Law says that speeding up one stage of a process just moves the constraint to whatever you didn’t speed up. AI is about to turn discovery into the easy part, everywhere. In security, that moves the entire game to judgment about what’s real and reachable, right now. 

Let me share where the real runtime advantage is

There’s a lot of noise right now about AI rewriting the balance between attackers and defenders. Most of it fixates on the frightening half: attackers move faster, find more, automate more. Fair enough, and the negative-seven-day number is real. But fixating there leads people to the wrong conclusion, which is that defense is hopeless and the only move is to brace for impact.

The quieter and more useful shift is the one buried in Anthropic’s piece almost in passing. Once finding is solved, and AI is solving it, defense stops being a discovery contest. It becomes a prioritization-and-response contest. And that contest is winnable. It’s won by whoever can see what’s real, in production, before anyone else does.

This isn’t a story about fear, it’s a story about advantage. The vulnerabilities were always going to be found, and soon they’ll be found faster than any human team could ever review, and that sounds like the problem but it’s actually the clarifying force. When discovery is infinite and free, it stops being where the value is. The value moves entirely to the filter: of everything that’s been found, what can actually reach me, and am I fixing that first?

The teams that internalize this will spend the next few years calm, focused, and fast, working a short list of things that are true. The teams that don’t will spend it drowning in a longer and longer list of things that aren’t true. Same data. Same AI. Completely different outcome. The difference is whether you’re looking at your environment as it really runs, or at a scanner’s guess about a version of it that never existed.

Finding the vulnerabilities was never the hard part. Knowing which ones can reach you always was. That’s the part worth getting right, and for the first time, it’s the part actually within reach.

Key Takeaways

• Discovery was never the constraint in vulnerability management. Prioritization and remediation always were, and AI-scale discovery makes that gap impossible to ignore.
• Only a small single-digit percentage of published vulnerabilities are ever exploited, so severity-first programs spend the overwhelming majority of their effort on findings that never mattered.
• Mean time to exploit has gone negative for many serious flaws, meaning exploitation now precedes the patch and the old patch race is unwinnable.
• Static severity scores rank threats backwards because exploitability is a property of your environment, not of the vulnerability.
• Runtime context (reachability, exposure, live activity, data sensitivity) is the filter that turns thousands of findings into the few that can actually reach you.