A raw count of critical vulnerabilities is easy to read but weak by itself. Severity scores describe technical impact, not your risk, and the count changes when scanners or scoring rules change. Use it as one line next to exploit evidence, exposure, and age, not as the headline.
What the severity score says about itself
The FIRST documentation for CVSS version 4.0 states plainly that base scores are not risk and should not be used alone for patch prioritization. Base severity is a measure of technical characteristics of a flaw. It does not know whether your system is exposed, whether attackers use the flaw, or what the system holds.
CISA makes a related point. In its BOD 22-01 FAQ it says known exploited vulnerabilities should be the top priority, and that CVSS can still be part of a program, especially for automation. In other words, severity and exploitation both matter, and they are different questions.
Why the count misleads
- It moves with the scanner. A new tool or a changed rule alters the count with no change in real risk.
- It ignores duplicates. One library in fifty images is fifty findings but one fix.
- It ignores context. A critical finding on an unreachable code path and one on an internet-facing login service score the same.
- It invites gaming. Teams can lower the count by downgrading severity or dismissing findings.
What to show beside it
| Companion | What it adds |
|---|---|
| Known exploited count | Evidence of attacker use |
| Reachable subset | Whether your code can call it |
| Internet-facing subset | Exposure |
| Oldest open age | Neglect |
| Fixable now | What is cheap to remove |
Five columns is more than most executives want, so choose two or three that fit your business and keep the others for the team.
A better headline sentence
Instead of "we have 312 criticals", try: "Of our critical findings, a small number are known exploited or internet-facing, and those are our focus this month." Use your own numbers. The sentence points at what is being done, which is what a leader wants to hear.
If the board asks for the critical count anyway
Give it, with a definition: which scores count as critical, which scanner, which scope, and the date. Add the trend and a sentence on what changed. Do not refuse the question. Answer it and add context.
Steps to improve your report
- Write down how your tools define critical.
- Add one exploit signal, such as the KEV catalog or an exploit prediction score.
- Add one exposure signal, such as internet-facing or reachable.
- Show age.
- Note method changes on the chart.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should we stop using CVSS?
No. It is a useful input, especially for automation. Just avoid using the base score alone to decide priority.
Is a lower critical count always better?
Not if it fell because of a scanner change or dismissals. Check the reason before celebrating.
Sources
Last reviewed: 19 October 2026.
