Explain reachability as a triage step: a flagged dependency is only urgent if your code actually calls the vulnerable function and an attacker can reach it. Show the evidence for each deferred finding, keep the decision reviewable and set a date to look again.
Why reviewers push back
A scan listing hundreds of findings looks bad. If you answer "most of those do not matter", a reviewer hears an excuse. The way through is to show your reasoning and evidence, and to never drop a finding without a record.
What reachability means
A vulnerability lives in a specific function or feature of a library. If your application never calls that code, or the feature is switched off, the flaw cannot be triggered through your product. Reachability analysis checks whether a call path from your code to the vulnerable code exists. It narrows a long list to the findings that deserve attention first.
It is a prioritisation aid, not a license to ignore things. Some reviewers will still want upgrades on a schedule.
How to present it
| Finding state | What you tell the reviewer | Evidence |
|---|---|---|
| Reachable and exposed | We are fixing it, with a target date | Ticket, fix pull request |
| Reachable, not exposed | We have a compensating control and will fix in the next release | Control description, ticket |
| Not reachable | We deferred it with a recorded reason and review date | Analysis output, notes |
| Fix not available | We track upstream and apply a mitigation | Advisory link, mitigation |
Every row has an owner and a date. The not reachable rows are the ones to handle most carefully: record how you determined it, and re-check when the code or the advisory changes.
A sample explanation
"We prioritise findings by whether our code reaches the vulnerable function and whether it is exposed to outside input. Of the findings flagged, these are reachable and being fixed by the dates shown. The remainder are not reachable in our current code; each has a recorded analysis and a review date, and we re-check when dependencies or code change."
Limits to state up front
- Analysis depends on language and framework support, and call paths through reflection or dynamic loading can be hard to see.
- A finding that is unreachable today can become reachable after a code change.
- Reachability does not replace updating libraries; it orders the work.
Saying these out loud builds trust. Reviewers hear a team that understands the method, not one hiding behind it.
Try it yourself
Open the reachability demo and watch a long list of findings narrow to the ones with a call path. Look at what the tool shows you to justify each call.
Click through it at your own pace, or open it full screen.
Safeguard includes reachability analysis alongside dependency scanning, so you can show which findings have a call path. See a sample result with the free scan at https://gold.safeguard.sh/scan.
Quick check
Can we close unreachable findings?
Defer them with a recorded reason and a review date rather than deleting them from the record.
Will every reviewer accept this?
No. Some will want upgrades regardless. Offer a schedule for those.
What if our analysis is wrong?
That is why reviews are dated and repeated. Correct the record and tell the customer if it mattered.
Last reviewed: 19 October 2026.
