Move the argument from the label to the evidence. Ask whether the code is reachable, whether the service is exposed, whether the issue is known to be exploited, and what the fix costs. Write a one page tiebreak rule in advance, so a dispute ends in a day with a decision on record.
Why these fights happen
A scanner reports a severity number. An engineer knows the code never calls that function. Security knows a score is not the whole picture either. Both are right about different parts.
The FIRST specification for CVSS describes scores as severity, and says consumers should supplement the base score with temporal and environmental scores. In other words, the base number is a starting point. Your context is meant to change it.
Five questions that settle most disputes
| Question | Evidence to check |
|---|---|
| Is the vulnerable code reachable? | Call path from an entry point, or a reachability result |
| Is the service exposed? | Internet facing, internal only, or isolated |
| Is it exploited in the wild? | CISA's KEV catalog lists vulnerabilities known to be exploited |
| How likely is exploitation soon? | EPSS gives a probability of exploitation in the next 30 days |
| What does the fix cost? | Version bump, code change, or architecture change |
If the answers are no, no, no, low, and cheap, fix it in the normal flow. If the answers are yes, yes, yes, high, and expensive, escalate and plan mitigation. Mixed answers need a short conversation, which the process below covers.
A tiebreak process
- The engineer records their view and evidence in the ticket, in three sentences.
- Security replies with their view and evidence within one working day.
- If they still disagree, a named person decides: the engineering manager for risk in their own service, with security able to escalate to a director for anything exposed or exploited.
- The decision, the reason and a review date go in the ticket.
- If circumstances change, such as a new exploit, the review date is brought forward.
Keep the record
Every accepted risk should have an owner, a reason, and an expiry. This protects engineers, who can show why a decision was made, and security, who can show it was reviewed.
Avoid these traps
Do not let the loudest voice win. Do not downgrade a finding to make a dashboard look better. Do not treat "not exploitable" as permanent: a later advisory or a code change can reverse it.
Try it yourself
Click through it at your own pace, or open it full screen. Check which signals the demo uses to judge whether a finding is likely to matter.
Safeguard combines reachability analysis with exploit signals so a ticket can carry the evidence above. Try the free scan.
Quick check
Who should have the final say on severity?
The owner of the affected service decides risk acceptance, with a path to escalate when the issue is exposed or known to be exploited.
Is a low CVSS score safe to ignore?
Not automatically. Context such as exposure and exploitation can raise real risk, so check the evidence before closing it.
Sources
Last reviewed: 19 October 2026.
