Analysis · Published 25 Aug 2026

Your Vendor's Rising CVE Count Is Now a Green Flag, Not a Red One

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

AI has made finding software flaws cheap, which means a disclosure tally now measures how hard a codebase is being searched, not how badly it was built. Every scorecard that punishes high counts is reading the metric upside down.

Listen7 min

There is a number on every security questionnaire that has quietly stopped meaning what it used to. A supplier's CVE count, the running tally of publicly disclosed vulnerabilities, has been read for two decades as a proxy for build quality: more flaws, worse software. That reading has just inverted. The suppliers with the fastest-rising counts are increasingly the ones spending hardest to find their own bugs, and the suppliers with clean sheets are increasingly the ones nobody has properly searched.

Follow the mechanism. A disclosure count is not a measurement of one thing. It is the product of two variables: how many flaws exist in the code, and how much effort is spent looking for them. For most of the industry's history the second variable was roughly constant, because discovery was expensive human labour. Skilled researchers were scarce and fuzzing farms cost real money; triage ate engineering hours on top. With search effort held broadly steady across vendors, counting disclosures told you something (imperfect, but something) about the code itself.

AI-driven vulnerability discovery breaks that assumption. When a machine can read a codebase at scale, generate candidate flaws and reproduce them without a human in the loop, search effort stops being a constant and becomes the dominant variable. The count no longer measures the target. It measures the searchlight.

Is a high CVE count a sign of bad software?

It never was a clean signal, and now it is close to the opposite of one. Watch the release notes of any vendor that switches on machine-scale discovery and you should expect the same shape: a long, flat baseline, then a cliff, with more security fixes landing in a couple of releases than in years of prior updates. Nothing about the code got worse in that moment. What changed is that knowing got cheap.

The deeper shift is that the whole pipeline is automating, not just the finding. Discovery, reproduction, severity triage, routing to the right developer, drafting the patch, writing the regression test: each stage that used to need a person is being handed to a machine. That matters because the real rate limit on vulnerability management was never how many bugs you could find. It was how many you could afford to know about. A human triage team can absorb a few dozen credible reports a week before the queue itself becomes the vulnerability. Automate the pipeline end to end and the affordable-to-know quantity explodes, and disclosure counts jump with it.

This is the part naive vendor scoring gets backwards: a questionnaire that docks points for high CVE volume is docking points for exactly the investment it should be rewarding.

Who wins when finding bugs is nearly free?

Nearly free is not evenly free. The capability is concentrated: running frontier-model discovery across a large codebase takes serious compute and access to the strongest models. A vendor that can borrow that capability from sister teams inside its own company can scan continuously. An unfunded open-source project, or a mid-tier supplier without an AI division, cannot. The likely result is a security divide between the AI-haves and have-nots: not a difference in how buggy the code is, but a difference in who knows where their bugs are.

Public code sharpens the race. When source is open, an attacker pays no reverse-engineering toll; the same automation that lets a defender surface a thousand flaws is available to an adversary the moment the capability is within reach. That is not an argument against open code. It is an argument that the meaningful metric has moved from how many flaws you have to who runs the discovery pass first and how fast the fixes ship. Search cadence and patch latency now carry the signal a CVE count used to.

The second-order effect is worse. If buyers keep penalising disclosure, they do more than misread the market; they optimise it in the wrong direction. A vendor watching its customers score raw counts has a rational incentive to search less and disclose slower. Bad metrics do not merely fail to measure diligence. They tax it.

What should boards and procurement teams do now?

Re-baseline, on purpose, before the next contract cycle. Go through everywhere a raw vulnerability count is load-bearing: questionnaire scoring, risk-register thresholds, contractual clauses that trigger on disclosure volume, the quarterly slide the board sees. Each of those now punishes the diligent and flatters the unsearched. Replace them with questions that survive the inversion: does the supplier run a continuous discovery programme, machine-assisted or otherwise; what is the median time from discovery to shipped fix; is there a published disclosure policy with dates you can audit. A supplier that answers those well while posting a rising CVE count is showing you its homework. One with a spotless record and no discovery story is showing you an unlit room.

That rewrite is a strategy exercise before it is a tooling one, the kind of metric re-plumbing we take on in technical strategy work: deciding what a number is actually evidence of before anyone gets paid or penalised on it. And if the plan is to point discovery agents at your own estate, two disciplines apply before the first scan. The machinery needs the containment we set out in secure agentic systems, and the consequential calls (severity, exploitability, when to disclose) need a person on them, for the reasons argued in practical AI with human control. Automating the search is not the same as automating the judgement.

The bug count stopped measuring the code the day machines started reading it at scale. It measures the searchlight now. Buyers who keep scoring it the old way are not choosing the safest supplier on the shelf; they are choosing the darkest.

Questions people ask

Is a high CVE count bad when choosing a software vendor?

Not on its own. A CVE count is the product of flaws present and effort spent finding them, and AI-driven discovery has made effort the dominant variable. Judge suppliers on discovery cadence, median time from discovery to patch, and the transparency of their disclosure policy instead of the raw tally.

How should security questionnaires change now that AI finds vulnerabilities?

Remove scoring and contract clauses that trigger on disclosure volume, because they penalise suppliers who search hardest. Ask instead whether the vendor runs continuous discovery, how fast confirmed flaws become shipped fixes, and whether its disclosure record is auditable with dates.

Does AI-powered bug hunting help attackers as much as defenders?

The capability is symmetric, and openly published code removes any reverse-engineering barrier, so the advantage goes to whoever runs the discovery pass first. Defenders keep the edge only by scanning continuously and shipping fixes faster than adversaries can weaponise findings.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.