A scanner can show a different severity than an advisory because the two used a different scoring version, a different publisher, different metric groups, or a tool-specific rule that adjusts the number. The scores are not necessarily wrong. They answer slightly different questions, so compare them only after checking how each was made.
Five common causes
1. Different publishers. A vulnerability can be scored by the maintainer, by a public database and by a platform. Each may reach a different Base score. FIRST notes that public bodies such as the National Vulnerability Database typically provide only Base scores.
2. Different CVSS versions. CVSS has had several versions. A v3.1 vector and a v4.0 vector for the same flaw can give different numbers because the models differ. A score without its version is hard to interpret.
3. Different metric groups. CVSS v4.0 has four groups: Base, Threat, Environmental and Supplemental. FIRST says Base metrics describe intrinsic qualities that stay constant over time and across environments, while Threat reflects characteristics that change over time, and Environmental reflects your own setting. A scanner that folds in Threat or Environmental data will show a different figure from one that shows Base only.
4. Tool rules. Some tools downgrade a finding when code is not reachable or a package is development-only, or upgrade it when exploitation is known. That is a deliberate priority adjustment, not a rescoring of the advisory.
5. Different advisory sources. Records in an OSV entry carry a severity array with a type, score and source. Two databases describing one issue can carry two entries.
FIRST's naming convention helps
FIRST recommends labels that say which metrics produced a number: CVSS-B for Base, CVSS-BE for Base and Environmental, CVSS-BT for Base and Threat, and CVSS-BTE for all three. If your scanner shows only "9.8", ask which one it is. Look for tools that display the label and the vector.
A comparison table
| If you see | It probably means |
|---|---|
| Advisory 9.8, scanner "High" | Scanner buckets scores or adjusted for context |
| Advisory v3.1 score, scanner v4.0 score | Different model, not an error |
| Two Base scores from two publishers | Publishers judged the flaw differently |
| Scanner higher than advisory | Exploit signal or asset importance raised it |
| Scanner lower than advisory | Not reachable, dev-only, or mitigated |
What to do about it
- Record the source and version of every score you act on.
- Use one scoring source as your default for gates, and write it down.
- Treat tool adjustments as priority, not as severity.
- When two scores disagree widely, read the vector, not the number.
For ordering decisions, pair severity with exploit signals. The CVSS, EPSS and KEV prioritization guide explains how those fit together.
Where Safeguard fits
Safeguard combines severity with reachability analysis and policies, so a gate can rely on rules you define instead of a single number. Try the free scan to see how a finding is presented.
Quick check
Which severity should I trust?
None blindly. Choose a documented default source for policy, then adjust priority with exploit signals and context.
Does a lower scanner severity mean the advisory is wrong?
Not usually. The tool may have applied a context rule. Check whether it shows the original score alongside its own.
Sources
Last reviewed: 19 October 2026.
