Five facts settle most severity disputes: the package is shipped, the vulnerable function is called, the input is attacker controlled, a fix exists, and the service is exposed. Collect them in that order. A score alone starts arguments, and evidence ends them.
Why scores do not settle it
A base score describes the flaw in general. It does not know whether your service ever calls the affected code. One team sees a high score and demands action. Another sees an internal batch job and shrugs.
Neither is wrong about their own context. The fix is to agree on which facts you will look at before you argue about the number.
The five facts, in order
- Is it shipped? Confirm the package is in a deployed artifact, not just a dev tool or test dependency. A dependency tree or an SBOM answers this.
- Is the vulnerable code reachable? Check whether your code, or a library you call, reaches the affected function. Reachability analysis does this automatically, and a code search for the API is a manual start.
- Can an attacker control the input? If the function parses data from the internet, that is different from parsing a config file only an admin writes.
- Is a fix available? A fixed version, a patch, or a configuration change changes the cost side of the decision.
- Is the service exposed? Public, partner facing, internal, or isolated. Exposure sets how many people could try.
Record it in one place
Put the five answers in the ticket as short lines. Anyone joining the thread can see the basis for the call.
| Fact | Answer | Where it came from |
|---|---|---|
| Shipped | Yes, in the payments API image | SBOM |
| Reachable | Yes, called from the upload handler | Reachability result |
| Attacker controlled | Yes, file contents | Code review |
| Fix available | Yes, a patch release | Advisory |
| Exposure | Public | Service catalog |
If all five are yes, the dispute is over: fix it now. If the first two answers are no, schedule the update with routine maintenance and note why.
Handling the middle cases
Mixed answers are where judgment enters. Agree in advance on a default.
- Reachable but internal only: fix within the normal sprint.
- Not reachable but publicly exposed: update soon, and re-check reachability when the code changes.
- Unknown: treat as reachable until someone shows otherwise, with a short time box to find out.
Writing these defaults down avoids relitigating them each time.
Try it yourself
Click through it at your own pace, or open it full screen. Follow how the check separates a finding that matters from one that only looks alarming.
Safeguard offers reachability analysis and SBOM and dependency scanning, which supply the first two facts without manual digging. You can try a free scan.
Quick check
Is an unreachable vulnerability ignorable?
It is lower urgency, not zero. Schedule the update and re-check when the code changes.
Who decides when teams disagree after the evidence is in?
The owner of the service decides, within the written defaults agreed with security. Escalate only if the defaults do not cover the case.
Last reviewed: 19 October 2026.
