You are presenting your report and you add this in a slide: "Open vulnerabilities: 2,845, down 9% from last quarter." Everyone nods and improves. You swipe.
Now ask the harder question. Is the company safer than it was last quarter? The number cannot answer that. It never could.
Vulnerability count became the default security KPI because it is easy to produce. It is not the default because it is accurate. Security leaders who keep reporting it are measuring the size of a to-do list and calling it protection.
Why vulnerability counts became the default metric
Scanners produce lists. Lists have lengths. A length can be trended, charted and compared across quarters with no extra work.
Compliance frameworks reinforced the habit. Auditors ask whether you have a vulnerability management process and whether you can show findings being closed. Closed findings are countable, so the count became the evidence.
There was also no obvious alternative. Judging whether a flaw is actually exploitable in your environment used to take a skilled analyst hours per finding. Counting took seconds. Teams chose the metric they could afford.
What the number actually tells you
A vulnerability count tells you three things:
- How much your scanners currently flag.
- How much scanning you are doing.
- How large your remediation backlog is.
That is useful for capacity planning. It helps you decide how many engineering hours to set aside for fixes. It is a workload measure.
It is not a risk measure. Those are different things, and treating them as one is where the trouble starts.
What the number does not tell you
It does not tell you what an attacker can reach. A critical flaw in a library that your application never calls is not the same as a critical flaw on a public login endpoint. Both count as one.
It does not reflect business context. A medium-severity issue in a payment flow can matter more than a high-severity issue in an internal tool. The count treats them by severity label alone.
It does not show speed. Two companies can both have 500 open findings. One fixes exploitable issues in two days. The other takes two months. The count is identical.
It does not show direction. The number can rise while your security improves. You add scanner coverage and find issues that were always there. You ship more code. A new disclosure lands against a dependency you have not touched in a year. Each of these raises the count and none of them means you got less secure.
The reverse also holds. A falling count can mean you scan less, suppress more, or have simply stopped looking.
The perverse incentives
Any number that is rewarded gets optimized. This is Goodhart's law: when a measure becomes a target, it stops being a good measure.
When teams are judged on open findings, sensible people respond in predictable ways:
- They close easy, low-risk findings first because those move the number fastest.
- They defer hard, high-risk fixes because those move it slowly.
- They narrow scan scope or raise severity thresholds.
- They mark findings as accepted risk to clear them from the report.
None of this is bad faith. It is a rational response to the metric. The result is a dashboard that improves while exposure stays flat or worsens.
Fewer findings is not automatically better security either. It is only better if the same coverage was maintained and the remaining issues matter less. The count alone cannot confirm either condition.
Better security KPIs
The replacement is a small set of measures tied to exposure and risk reduction. Five cover most of what an executive needs.
Exploitable exposure. The number of issues that an attacker could realistically exploit given how your systems are built and deployed. Start from your full findings list, then remove anything that cannot be triggered in your environment. This is the number that most closely tracks real risk.
Reachable critical issues. Of your critical and high findings, how many sit on code paths an attacker can actually reach. Track this as a count and as a share of all criticals. A large backlog with few reachable criticals is a manageable position. A small backlog with many reachable criticals is not.
Time to remediate reachable issues. Measure how long reachable critical issues stay open, from detection to verified fix. Report the median and the slowest cases. Averaging across all findings hides the ones that matter, so scope this to reachable issues only.
Residual attack paths. Individual findings can chain. A minor misconfiguration plus a weak access rule can add up to a route to sensitive data. Track the number of viable paths to your most important assets, and watch whether fixes actually close them.
Coverage. Every metric above depends on how much of your environment you actually assess. Report the share of code, cloud and web applications under continuous scanning. Without it, a good number could just mean a small view.
Together these answer what the board really asks. What can hurt us, how fast do we close it, and are we getting better?
How modern platforms generate these metrics automatically
These KPIs are harder to compute than a count. Reachability needs an understanding of how your code, cloud configuration and running application fit together. Attack paths need that understanding across layers. For a team with no dedicated security staff, or one or two people, doing this by hand is not realistic.
That is the gap application security platforms are built to close. The useful ones determine reachability from the customer's own context instead of relying on severity labels. They cover code, cloud and web applications together, because attack paths cross those boundaries. They also track change over time, so trend lines come from the platform and not from a spreadsheet someone rebuilds every quarter.
Rezliant's Maestro works this way. It applies its own analysis of a customer's context to determine what an attacker can actually reach, and it scans whichever of code, cloud and web app the customer builds. It then generates the fix and pushes it to engineers to review and merge. That last step matters for reporting. When remediation is part of the engineering workflow, time to remediate becomes something you can measure instead of estimate.
The principle applies whatever tool you choose. If a platform can only hand you a bigger list, it will not produce better KPIs.
A new executive security dashboard
A useful dashboard fits on one page and has six tiles:
- Exploitable exposure, with quarter-over-quarter trend.
- Reachable critical issues, as a count and as a share of all criticals.
- Median time to remediate reachable critical issues.
- Residual attack paths to your most important assets.
- Coverage across code, cloud and web applications.
- Total backlog, shown last and labeled as workload.
Keep the backlog on the page. It still informs staffing. It just stops being the headline.
When you present it, use plain sentences. For example: "Reachable critical issues fell from 14 to 6. Median time to fix them is now three days. Coverage is complete across our production applications." A board can act on that. Nobody has to decode a severity label.
The shift also helps outside the boardroom. Investor diligence and enterprise customer security reviews increasingly probe how you manage risk, not just whether you run scans. A reachability-based story is easier to defend than a shrinking list.
Frequently asked questions
Should we stop tracking vulnerability count entirely?
No. Keep it as a workload and capacity measure. Stop using it as the measure of security.
What if we cannot measure reachability yet?
Start with what you have. Track time to remediate for critical and high findings on internet-facing systems, and add coverage reporting. Then work toward reachability as tooling allows.
How do we explain a rising count to the board?
Show it next to exploitable exposure and coverage. If exposure is falling while the count rises because scanning expanded, the story is a good one and the metrics will show it.
The line to remember
A shrinking backlog is nice. A shrinking attack surface is what matters.
The first tells you how busy your team has been. The second tells you whether the company is safer.
Measure security by risk reduction, not finding volume.