Sometimes, yes. Severity describes the flaw, not the asset. A low rated issue on a system that holds your most sensitive data and faces the internet can be a better fix than a critical rated issue on an isolated sandbox with fake data. The deciding facts are reachability, exposure, data and exploit evidence.
Severity is context free by design
CVSS v4.0 states that the Base score reflects intrinsic characteristics that are constant over time and across user environments, and that it assumes the reasonable worst case impact across different deployed environments. That is a feature. It lets the whole world talk about a flaw the same way. It also means the base number cannot know that one server is a sandbox and another holds payment records.
The specification says consumers should enrich Base metrics with Threat and Environmental values specific to their use of the system. That enrichment is the job asset context does.
A comparison
| Question | Low CVSS on crown jewel | Critical CVSS on test box |
|---|---|---|
| Who can reach it | Public | Nobody outside a test network |
| What it holds | Customer data | Fake data |
| Is vulnerable code used | Yes | No, the library is bundled but unused |
| Exploit evidence | Public proof of concept | None known |
| Business role | Revenue path | None |
On this table, the low score finding goes first. That is not a rule that low beats critical. It is the output of the questions.
A decision flow
- Is either flaw known to be exploited? If one is on a list such as CISA's Known Exploited Vulnerabilities Catalog, it moves up regardless of score.
- Is the vulnerable code reachable? If not, it moves down.
- Can an attacker reach the asset? Public beats internal beats isolated.
- What would a breach cost? Use your data label and criticality tier.
- Only then use the base score to break ties.
Notice that severity comes last. It is a tie breaker, not a starting point.
What can go wrong
- Chaining. A low severity flaw can be a link in a chain. An information leak that exposes a token may matter more than its score implies.
- Unknown reachability. If you do not know whether code is called, you cannot move a finding down. Assume it is reachable.
- Score gaming. If teams learn that low scores are ignored, they will argue for lower scores. Keep the process visible.
- Test box drift. A sandbox that quietly gained a production database is not a sandbox anymore. Check the data label before relying on it.
How to explain this to a skeptical manager
Say it in one sentence: the score tells us how bad the flaw can be, the asset tells us how bad it would be for us. Then show the table above using two real findings. People accept a reordered queue when they can see the facts behind each place.
Keep a floor
Do not let low severity findings on important systems sit forever. Give every finding on a Tier 1 asset a maximum age. Lower tiers can use a longer maximum, but none should be open ended.
Where Safeguard fits
Safeguard offers reachability analysis and vulnerability management with policies that can take asset information into account. Safeguard also offers a free scan at gold.safeguard.sh/scan if you want to see your own dependency findings first.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which findings drop out once you ask whether the vulnerable code is actually called.
Quick check
Does this mean I can ignore CVSS?
No. Use it as a tie breaker and as a signal of worst case impact, after exploit evidence, reachability and asset context.
What about low severity flaws that chain?
Treat chains as a reason to review a group of findings together on important assets, not one at a time.
Sources
Last reviewed: 19 October 2026.
