Vulnerability prioritization: discovery isn't the problem anymore

Key takeaways

• Most organizations remediate only ~10% of open vulnerabilities per month, regardless of size or maturity (Cyentia).
• Of 48,000+ CVEs published in 2025, ~800 were exploited in the wild. Only ~58 were reachable and likely to be targeted (Black Kite).
• CVSS and EPSS score the internet, not your environment. Neither can rank your backlog.
• EPSS usually moves after exploitation is confirmed, not before (Nucleus Security).
• Full AI automation is losing ground: 29% to 9% in a year, with 78% reporting missed critical bugs (Cobalt).
• The only reliable signal is an exploitation attempt from outside, validated by a human.

A CISO told me recently that she doesn't need help finding vulnerabilities. She already has thousands. What she needs to know is which twelve matter this quarter.

That is what vulnerability prioritization has become. Not a reporting feature buried inside a scanner, but the single decision that determines whether a security budget produces actual risk reduction or just a longer backlog. And the data behind that decision is unforgiving.

What vulnerability prioritization actually is

Vulnerability prioritization is the process of deciding which of the known vulnerabilities in your environment get fixed first, based on how likely each one is to be exploited against you specifically, rather than on theoretical severity alone. In practice it is a filtering problem: taking tens of thousands of published CVEs and reducing them to the short list an attacker could realistically use against your exposed assets.

The short version of what follows: severity scores describe a vulnerability, exploitability evidence describes your exposure, and only the second one can rank a backlog.

The remediation ceiling nobody can hire their way past

Research from the Cyentia Institute, analyzing 3.6 billion vulnerability observations, found that the typical organization can remediate only about 10% of its open vulnerabilities per month. That number barely moves whether you are a five person startup or a global bank with a mature program. It is not a resourcing gap you close with headcount. It is a structural ceiling.

Meanwhile the volume keeps climbing. The first half of 2026 alone produced 35,364 new CVEs, one every 7.4 minutes, up roughly 50% year over year. Tenable research puts the average enterprise backlog at over 100,000 open vulnerabilities in two thirds of organizations. Edgescan's 2025 statistics found that 45% of discovered vulnerabilities are still unpatched after twelve months.

Detection has vastly outpaced the capacity to act on what gets detected. Some in the industry call this the "find but never fix" crisis. It is an accurate name.

48,000 published CVEs, 58 that actually mattered

Here is the number that reframes the whole problem. Of the 48,000+ CVEs published in 2025, Black Kite's research estimates roughly 800 were ever exploited in the wild. Filter further, for vulnerabilities that are both discoverable from outside your perimeter and carry a genuinely high probability of targeted exploitation, and you are down to 58.

Forty eight thousand published. Fifty eight that actually mattered.

So the problem was never volume. The problem is that almost nothing in the standard toolkit can reliably tell you which handful of the 48,000 are the ones aimed at you.

Why CVSS and EPSS cannot prioritize vulnerabilities in your environment

CVSS measures theoretical severity. It has no idea whether your specific controls would block the exploit path, and FIRST itself states that base scores should not be used alone for prioritization.

EPSS, the Exploit Prediction Scoring System, is better. It estimates real world exploitation probability across the internet. But it still has never seen your environment, and it arrives later than most teams assume.

Nucleus Security studied CVEs added to CISA's Known Exploited Vulnerabilities catalog and found that the median EPSS score movement was 121 times larger after a vulnerability was confirmed exploited than before. In several cases, active exploitation was already underway before EPSS gave any meaningful signal.

Global scoring systems answer a global question: how dangerous is this vulnerability, in general, across the internet? They were never built to answer the only question that matters to you, which is whether this one is exploitable, specifically, in your environment, right now.

There is only one reliable way to answer that. Try it, from the outside, using the same tools and the same perspective an actual attacker would use.

Why the answer still needs a human in it

This is where the industry's own recent data gets interesting. Cobalt's 2026 AI and Pentesting Pulse Report, surveying 455 security professionals, found that the share of organizations relying entirely on AI automation for testing dropped from 29% to 9% in a single year. The reason: 78% had experienced fully automated scanning tools missing critical vulnerabilities outright. False negatives, not just noisy false positives.

A Stanford study (ARTEMIS) measuring autonomous AI pentest agents against human testers found the best performing agent still submitted 18% invalid findings. Top human testers hit 100% valid. Off the shelf agent tooling, not purpose built for the task, was far worse: the best of those reached only a 55% valid submission rate.

None of this means AI does not belong in the process. It means AI is excellent at generating candidates and terrible, on its own, at being the final word on whether a candidate is real. Someone has to close that gap, and right now that someone is a human who stakes their professional judgment on being right.

How to prioritize vulnerabilities: four rules for buying security testing

Put the pieces together and a different way of buying security testing falls out naturally.

• Test from the outside, the way an attacker actually would. Not just what internal scanners can see, but what is visible and reachable to someone with no inside knowledge of your architecture.

• Validate every finding with a human before it reaches your team, so your backlog becomes a list of confirmed, exploitable issues instead of a longer list of maybes.

• Pay for the confirmed findings, not the process. If discovery volume is not the bottleneck, there is no reason to keep paying for volume. Pay when something real is found, nothing when it is not.

• Keep the record of everything that was tried and did not work, not just what succeeded. This turns out to matter almost as much as the findings themselves. When a regulator or an auditor asks how you know your prioritization decisions were sound, "here is everything an external attacker's toolset attempted against our perimeter, and here is what held" is a fundamentally stronger answer than a scanner report. Under frameworks like NIS2 and DORA, that distinction is the difference between a defensible process and an assertion.
  
  

How UNGUESS Security applies this

UNGUESS Security is the offensive security arm of UNGUESS, with a network of 200+ European security researchers working alongside specialized AI agents. The model maps directly onto the four rules above.

The platform maps your exposure the way a hacker sees it, same outside in perspective, no assumptions about internal architecture you have not confirmed. Every candidate finding is then attempted and validated by a vetted ethical hacker before it becomes something your team has to act on. You pay for the vulnerabilities that turn out to be real, and nothing for the ones that do not, because the commercial model is success fee by design.

You also get a full account of what was tried against everything else, which is exactly the evidence an auditor or regulator wants to see when they ask how you knew your priorities were right.

If you want to see the starting point of that picture for your own domain, the self serve vulnerability scan on security.unguess.io/app maps your externally exposed assets and returns a report within a few hours.

The backlog is not going to get shorter

CVE volume is not slowing down, and no organization is going to remediate its way to zero open vulnerabilities. That was never really the game. The game is knowing, with confidence, which small number out of the large number is the one an attacker would actually use, and being able to prove, later, that you knew.

See what a hacker sees: security.unguess.io/app