A vulnerability count measures how much your scanners can see and how much the world discloses. It does not measure how likely you are to be breached. A falling count can sit comfortably beside rising risk.

The denominator keeps moving

CVE volume keeps climbing. An analysis of CVE data by researcher Jerry Gamblin counts 48,185 CVEs published in 2025, up 20.6% from 39,962 in 2024. FIRST’s February 2026 forecast put the 2026 median at about 59,427, with a 90% interval of 30,012 to 117,673. Trade press reporting on FIRST’s mid-year update puts the revised figure near 66,000 and says FIRST attributes the rise to changes in how flaws are found and reported, not to a decline in software quality. A metric that tracks this number is partly tracking the reporting habits of the CVE ecosystem.

Your own count carries more noise. Add a scanner, extend scanning to a new network or change a plugin set, and the number moves with no change in risk. Count findings per instance, and one widely deployed library produces thousands of rows. Decommission a test estate and the count falls while your exposure stays where it was.

Severity labels do not narrow the field

A common response is to count only critical and high findings. In 2025 that meant 18,987 CVEs, or 39.4% of everything published, according to the same Gamblin analysis. For scale, CISA added 245 vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog in 2025, as reported by SecurityWeek. The two sets are not the same, since KEV additions include older CVEs, so read this as a comparison of scale, not a ratio. The scale is the point: tens of thousands of high-severity labels, a few hundred confirmed exploited.

The reason sits in how CVSS works. FIRST’s CVSS v4.0 user guide says the base score measures severity, not risk, and should not be used alone to assess risk. It adds that vendors and bodies such as NVD usually publish only base scores, which leaves threat and environmental context to the consumer. A count of “critical” vulnerabilities is therefore a count of base scores: the one CVSS input that knows nothing about your network and nothing about what attackers are doing.

Counts reward the wrong behavior

Teams optimize what they are measured on. A burn-down target is met fastest by closing many easy, low-risk findings. A hard one, such as an end-of-life gateway that needs a replacement project, sits untouched because closing it moves the number by one. The count improves and the exposure does not. This is an interpretation of incentives, not a finding from the sources cited here.

The number that matters moves slower than the one on the dashboard

Verizon’s 2026 DBIR, covering Nov 01, 2024 to Oct 31, 2025, measured how organizations handled vulnerabilities in CISA’s KEV catalog. Only 26% were fully remediated, down from 38% the year before. Median time to full remediation rose from 32 days to 43. Between 60% and 70% were still open at day seven. Proactive remediation, before a vulnerability reached the KEV list, fell from 17% to 12%.

None of that shows up in a headline count. Set it beside the threat side. In the same report, exploitation was the initial access route in 31% of breaches, and Mandiant’s M-Trends 2026 estimates the mean time to exploit at -7 days. KEV is, by definition, the exploited set, and organizations in the DBIR’s data are closing it more slowly than before.

What to report instead

INSTEAD OFREPORTWHAT TO WATCH FOR
Total open vulnerabilitiesOpen exploited vulnerabilities on internet-facing assets, with the age of the oldestNeeds a reachability view and an exploitation source beyond KEV.
Count of critical and high findingsOpen findings that meet an exploitation-and-exposure rule you have written downThe rule must be agreed in advance. FIRST publishes no universal EPSS threshold; cutoffs are a risk-tolerance choice.
Average time to patchMedian and 90th-percentile time to remediate, split by exploitation statusThe DBIR’s 43-day KEV median is a reference point, not a target.
Scan completion rateShare of internet-facing and identity-adjacent assets assessed in the last N daysUnknown assets never appear in the denominator.
Number of exceptionsRisk acceptances past their expiry date, with ownerNeeds expiry dates to exist first.

For ranking, a staged rule is easier to defend than a single score. Start with KEV status and exposure. Add an EPSS threshold you choose against your own risk tolerance. Then decide actions with a scheme that ties each outcome to who must act. CISA’s SSVC does this, with outcomes running from Track to Act. NIST has proposed going further and combining EPSS, KEV and a derived metric called LEV, because EPSS tends to underestimate vulnerabilities already known to be exploited. LEV is a proposal, not an established standard, and NIST says its margin of error cannot yet be validated.

Where counts still belong

Counts are fine for what they measure: workload for patch teams, scanner coverage over time, backlog trend inside one tool. They are a capacity metric. The problem starts when a board pack presents them as a risk metric.

What to change this quarter

  • Move the total vulnerability count out of board reporting, or into an appendix.

  • Put the age of the oldest exploited vulnerability on an exposed asset next to whatever remains.

  • Write down the rule that decides which findings count as urgent, and who agreed it.

One test settles it. If the count halved tomorrow, would you believe your risk had halved? If not, it is not a risk metric.

Sources

How we label evidence

Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.

Part of the solutionManage Cyber Risk & ExposureKnow what attackers can reach and what it would cost.See how we work →

Related service

Vulnerability & Exposure Management

Use this to prioritize vulnerabilities by real exposure.

Talk to an ExpertSee this service →Related articles →
Also relevant:Cyber Risk AssessmentExternal Attack Surface ManagementBoard & Executive Advisory