Why Vulnerability Counts Are a Misleading Metric

"We reduced our vulnerability count by 40% this quarter" sounds like unambiguous good news in a board deck. It's also one of the easiest metrics to improve without making the organization meaningfully safer — and sometimes one of the easiest to improve while actually making things worse. Total open vulnerability count persists as a headline metric mostly because it's simple to produce, not because it's a good measure of security posture.

The Problem with a Single Number

A raw count collapses a huge amount of relevant information into one figure. It treats a critical, actively exploited, internet-facing finding the same as a low-severity finding on an internal test server with no path to sensitive data. It treats a finding that appeared yesterday the same as one that's been open for eleven months. It says nothing about whether the count went down because of real remediation work or because a scan simply covered less of the environment this cycle.

This creates perverse incentives. A team under pressure to reduce the number can do so by narrowing scan scope, lowering scan sensitivity, or focusing effort on easy, low-risk findings that pad the closure count while the handful of genuinely dangerous, harder-to-fix issues remain untouched. None of this happens out of bad faith — it happens because the metric itself rewards volume over risk reduction.

What Changes in the Count Can Actually Mean

A rising or falling vulnerability count can be explained by several very different underlying realities:

• Scan coverage changed — scanning more assets, or scanning the same assets more thoroughly (for example, switching from unauthenticated to authenticated scanning), will increase the count even if the environment's actual risk hasn't changed at all — you're just seeing more of what was already there.
• A new CVE affecting common software was disclosed — a single widely used library can generate dozens or hundreds of new findings across your environment overnight, with no change in your organization's actual security practices.
• Remediation genuinely occurred — the count going down because real fixes were applied is the only version of this story that reflects improved posture.
• Findings were suppressed or scope was narrowed — the count going down because you're looking at less, or filtering more aggressively, looks identical on a dashboard to genuine improvement.

Without decomposing which of these is driving the number, the count alone tells you almost nothing useful.

Better Metrics to Track Instead

Rather than reporting a single count, mature programs track a small set of metrics that better reflect actual risk trajectory:

• Mean time to remediate (MTTR), by severity tier — how long does it actually take to close a critical finding versus a medium one? This measures whether remediation is keeping pace with detection.
• SLA compliance rate — what percentage of findings are closed within their assigned deadline, broken down by severity and by owning team?
• Age of the oldest open critical/high findings — a small number of long-lived critical findings is a bigger risk signal than a large total count dominated by low-severity noise.
• Percentage of internet-facing critical/high findings remediated within a defined window — this isolates the subset of findings that matter most for external risk.
• Scan coverage — what percentage of known inventory is actually being scanned, and how much of that is authenticated versus unauthenticated? A count is meaningless if you don't know what fraction of the environment it's even drawn from.
• Recurrence rate — how often does a "remediated" finding reappear, indicating the fix didn't actually hold or a fresh instance of the same misconfiguration was introduced elsewhere?

Reading a Trend Instead of a Snapshot

Even good metrics need to be read as trends over multiple cycles, not single data points. A count going up this month because scan coverage expanded is a different story than a count going up because remediation stalled — both look identical without the surrounding context of what changed operationally between cycles. Reporting should always pair the number with a short explanation of what moved it, not the number alone.

What to Actually Put in a Leadership Report

For an audience that needs a fast, honest read on program health rather than a raw dashboard export, a more useful report structure includes:

• MTTR by severity tier, trended over the last several cycles.
• SLA compliance percentage, with call-outs for teams or asset categories consistently missing targets.
• Age and count of the longest-open critical and high findings, by name if the list is short enough.
• Scan coverage percentage and any recent expansion or contraction, with the reason noted.
• A short narrative explaining any significant count change, rather than the number alone.

Producing this kind of decomposed, trended reporting by hand — pulling MTTR, SLA compliance, and coverage separately out of scan exports and ticketing systems — is exactly the kind of recurring manual effort that causes teams to fall back on the simple, misleading total count instead. Venstap's reporting is built around finding lifecycle and asset context specifically so metrics like MTTR by severity, SLA compliance, and scan coverage are available directly rather than requiring a separate reconciliation exercise every reporting cycle. A single vulnerability count will always be the easiest number to put in a slide. It's rarely the number that tells you whether your organization is actually getting safer.