Override a CVSS base score when your own context clearly changes the risk: the vulnerable feature is off, the service is not exposed, or the asset is unusually sensitive. Record the reason and who agreed, because an unexplained override looks like a bypass.
What the specification itself says
The CVSS 3.1 specification says the base score reflects intrinsic severity and that consumers should supplement it with temporal and environmental scores. Environmental metrics, in its words, enable the analyst to customize the score depending on the importance of the affected IT asset, including existing security controls. So adjusting for context is part of how CVSS is meant to be used, not a hack.
Reasons to lower a finding
- The vulnerable function is never called, as shown by reachability analysis.
- The feature is disabled by configuration in every deployment.
- A control sits in front of the service and blocks the attack path.
- The package is a test dependency that never ships.
Reasons to raise a finding
- The flaw is known to be exploited in the wild.
- The service is internet facing and holds sensitive data.
- A working exploit is public and your version is affected.
- The component sits in a trust boundary, such as authentication.
Overrides compared
| Override | Evidence needed | Review by | Expiry |
|---|---|---|---|
| Lower, not reachable | Call graph or code review note | Security | 90 days or next release |
| Lower, feature off | Config in version control | Service owner and security | Until config changes |
| Raise, exploited | Public exploitation report | Security | Until fixed |
| Raise, sensitive asset | Asset classification | Service owner | Review yearly |
Steps to implement
- Keep the original base score visible next to the adjusted one.
- Store the override with its reason, evidence link and approver.
- Give every lowering override an expiry. Raising overrides expire when fixed.
- Re-evaluate when the code or configuration changes.
- Report the count of overrides so growth is visible.
What not to do
Do not lower a score because the fix is inconvenient. Do not edit the scanner's database. And do not override the same class of finding across all projects without evidence, since the same package may be reachable in one service and not in another.
Quick check
Is overriding CVSS the same as suppressing a finding?
No. An override changes priority with a stated reason. A suppression hides the finding. Prefer overrides that keep it visible.
Who should approve a lowered score?
Someone other than the author, usually security, with the service owner consulted.
Safeguard's reachability analysis and policies give evidence for context based decisions, and every gate decision records its reason. Run the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
