Why Vulnerability Counts Don't Tell the Whole Story

Vulnerability count is the easiest metric to report and one of the least useful to act on. A program can close thousands of low-risk findings on isolated test systems and report a huge number, while a handful of exploitable, internet-facing critical findings sit untouched. The raw count would never tell you that happened.

Counts hide distribution

Closing a lot of vulnerabilities doesn't tell you much on its own. The number worth tracking is how much risk-weighted exposure dropped on the assets that count. A program should be able to say, specifically, what happened to critical and high-severity findings on internet-facing and identity-critical assets, separately from the aggregate count across the whole estate.

Age matters as much as severity

A critical finding that's twelve hours old and a critical finding that's been open for six months are not the same risk, even at an identical CVSS score. Mean time to remediate, broken out by severity and asset criticality, tells you whether the program is actually keeping pace with new findings or slowly accumulating debt that the aggregate count is masking.

What I report instead

• Reduction in critical and high-severity findings specifically, tracked apart from the blended severity total.
• Mean time to remediate, segmented by severity and asset criticality.
• Exposure on internet-facing and identity-critical assets, tracked as its own line.
• Recurrence: findings that reopen after being marked remediated, which usually points at a validation gap.

None of this makes the reporting more flattering in the short term. It makes it accurate. A program that can show real reduction on the metrics that matter earns more trust than one that can only point to a large total closed-ticket count.