A CVSS score of 9.8 means the vulnerability is rated as severe in the abstract: easy to attack, with high impact if it is attacked. It does not say whether your systems are exposed or whether anyone is exploiting it. Treat it as a reason to check quickly, not as a measure of your risk.
The one sentence to give an executive
"The score tells us how bad this flaw could be anywhere. Our job now is to find out how bad it is for us."
That framing is accurate. FIRST, which maintains CVSS, says the standard is designed to measure the severity of a vulnerability and should not be used alone to assess risk. The Base score represents only the intrinsic characteristics of a vulnerability (FIRST).
What the score does and does not include
| The score reflects | The score does not reflect |
|---|---|
| How the flaw can be attacked in general | Whether the affected component is on your internet-facing systems |
| The impact if it is attacked | Whether the vulnerable code path is ever called |
| (With Threat metrics) exploit maturity | What controls you already have in front of it |
| (With Environmental metrics) your adjustments | The value of the data on the affected system |
FIRST describes variants of the score by the metrics used: CVSS-B for Base only, CVSS-BT with Threat, CVSS-BE with Environmental, and CVSS-BTE with all three. A score in the news is almost always the Base score. When Threat and Environmental metrics are applied, FIRST says the result can be considered much closer to risk.
Three questions that turn a score into a decision
- Are we running it? An inventory answers this. If you cannot list your components, this is the first problem to fix.
- Is it exposed? An internal-only component with no untrusted input is a different situation from one facing the internet.
- Is anyone using it? CISA maintains a catalog of vulnerabilities known to be exploited in the wild and says organizations should use it as an input to prioritization (CISA KEV). Exploitation evidence moves a ticket up the list.
Answering these three takes hours, not weeks, if the inventory exists.
What to avoid saying
Avoid "we have a 9.8 problem" unless you have confirmed you run the affected component. Avoid averaging scores into a single number for a slide; it hides the few findings that matter. Avoid treating a lower score as safe, since a medium flaw that is reachable and exploited can matter more than an unreachable critical one.
What to put in the update
A good executive update uses the score as one line, then moves on: the flaw name, the score and its source, whether we run it, whether it is exposed, whether exploitation is known, what we are doing, and when the next update comes.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how the list of critical findings shrinks when only reachable code paths are counted. That is the gap between a score and your risk.
Where Safeguard fits
Safeguard can help here: the free scan at gold.safeguard.sh/scan lists the dependencies in a project and the known issues attached to them, and reachability analysis shows which findings your code can actually hit.
Quick check
Is a 9.8 always urgent?
It is always worth checking quickly. Whether it is urgent for you depends on exposure, reachability and exploitation evidence.
Can a low score be dangerous?
Yes. If it is reachable and being exploited, it can outrank a higher unreachable score.
Sources
Last reviewed: 19 October 2026.
