Reachability analysis checks whether your application can actually call the vulnerable code in a dependency. That turns triage from a debate about severity into a lookup. Reachable flaws on exposed services go to the front of the queue, and the rest get a scheduled, lower urgency fix.
What triage costs
Triage is the stage between "alert raised" and "someone owns a fix". Without code level context, each alert needs a person to read the advisory, find where the package is used, guess whether the vulnerable function is called, and argue about priority. Multiply by hundreds of alerts and the stage becomes the bottleneck.
What reachability adds
A package can contain many functions. An advisory usually affects one or a few. If your code never calls the affected function, directly or through other libraries, the flaw is present but not reachable from your application paths. Reachability analysis traces call paths from your code into the dependency to answer that question.
It does not mean the flaw is harmless. Code changes, new features may start calling the function, and static analysis has limits. It means the urgency is different.
A decision table
| Reachable? | Exposed to the internet? | Suggested handling |
|---|---|---|
| Yes | Yes | Front of the queue, expedited path |
| Yes | No | Normal high priority |
| No | Yes | Scheduled fix, recheck on code changes |
| No | No | Routine update cycle |
| Unknown | Any | Treat as reachable until you know |
Pair this with other signals, such as whether the flaw is being exploited, as covered in our posts on prioritisation. Reachability answers a question the others cannot: does my code touch it?
Steps to adopt it
- Run reachability on your most exposed services first. Prove it on a small set.
- Compare to your manual triage. Check for cases where people deprioritized something reachable.
- Change the queue order. Sort by reachable and exposed, then by severity.
- Set a recheck rule. When a service changes, rerun, since an unreachable flaw can become reachable.
- Record the evidence. Keep the call path in the finding so auditors and teammates can follow it.
Where it can mislead
- Dynamic calls. Reflection and plugin systems can hide call paths from analysis.
- Unsupported languages or frameworks. Treat coverage gaps as unknown, not safe.
- Stale results. An analysis from last quarter says little about today's code.
For these reasons, treat unreachable as a lower priority and a scheduled fix, not as permission to ignore.
Effect on the window
Triage time drops because many alerts get an answer without a meeting. Total exposure also changes in a subtler way: the reachable flaws start earlier, so the ones that matter most get shorter windows even if the total workload is unchanged.
Measure it
Track median time from alert to owner for reachable findings versus the rest. You want the reachable number to be clearly smaller. If it is not, your queue is not using the signal.
Try it yourself
Open the demo and watch how reachability cuts a long list of findings to a short one.
Click through it at your own pace, or open it full screen.
Safeguard includes reachability analysis alongside dependency scanning, so triage can start from call paths. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is an unreachable vulnerability safe to ignore?
No. It is lower urgency. Code changes can make it reachable, so schedule the fix and recheck.
What if reachability is unknown?
Treat it as reachable until you can show otherwise.
Last reviewed: 19 October 2026.
