Treat the scanner's severity as a default, then adjust it with facts about your environment: whether the code is internet facing, what data it touches, and what other controls sit in front of it. Write down every override with a reason so it can be checked later.
Why default severity is not your severity
CVSS, the scoring system many tools borrow from, is open about its limits. The specification says the base score reflects intrinsic characteristics of a vulnerability and assumes the reasonable worst case across different deployed environments. It also says factors such as number of customers, monetary loss or public sentiment are outside its scope. For adjusting to your own setting it provides environmental metrics, which let an analyst customise the score by the importance of the affected asset and the presence of mitigations.
The qualitative bands in that specification are None at 0.0, Low at 0.1 to 3.9, Medium at 4.0 to 6.9, High at 7.0 to 8.9 and Critical at 9.0 to 10.0. Most scanners map their own ratings onto something similar.
Factors that should move severity
| Factor | Raises severity when | Lowers severity when |
|---|---|---|
| Exposure | Reachable from the internet without login | Only reachable from a restricted admin network |
| Data | Handles credentials, payment or health data | Handles public or synthetic data |
| Authentication | Exploitable by anyone | Needs a privileged account |
| Compensating controls | None in place | A tested control blocks the attack path |
| Reachability | The vulnerable code path is called | The code is dead or never receives untrusted input |
| Blast radius | A compromise reaches other systems | Isolated, low privilege service |
A simple procedure
- Start with the scanner's rating.
- Answer the six questions above for the specific finding.
- Move the rating up or down by at most one band per factor group, and no more than two bands in total, so overrides stay defensible.
- Write the override reason in the finding record.
- Have a second person approve any downgrade of a high or critical item.
- Revisit overrides when the architecture changes, for example when an internal service gets an external route.
Rules of thumb
Downgrading is riskier than upgrading, because the cost of being wrong is hidden. Require stronger evidence to lower a rating than to raise it. Never lower severity because a fix is inconvenient.
Be careful with compensating controls. A web application firewall rule is not a fix for the underlying flaw, and it can be bypassed. Count a control only if you have tested that it blocks this path.
For more on reading severity next to confidence, see SAST severity versus confidence.
Try it yourself
Open the demo and compare how a plain severity ordering differs once exploitability is considered.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers reachability analysis to show whether vulnerable code is actually called. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Is it acceptable to lower a scanner's severity?
Yes, with a written reason, evidence and a second approver for high and critical items. Review the override when the system changes.
Does CVSS measure risk?
Not on its own. It describes severity of the flaw. Risk also depends on your exposure, data and controls.
Sources
Last reviewed: 19 October 2026.
