Reachability should inform a gate, not run it alone. If analysis shows your code never calls the vulnerable function, you can downgrade the finding from block to warn. Keep a fallback: block anyway when the flaw is known to be exploited or when the analysis is uncertain.
What reachability analysis answers
A vulnerability sits in a library. Whether it matters depends on whether your application can reach the vulnerable code. Reachability analysis builds a picture of calls from your code into the library and asks if a path exists to the affected function. It turns "this package has a flaw" into "this flaw can or cannot be triggered from here".
The CVSS specification supports this style of reasoning. Its environmental metrics exist so an analyst can customize the score for the affected asset and existing controls, and it says consumers should supplement the base score instead of relying on it alone.
A decision table for the gate
| Reachability result | Exploited in the wild? | Suggested gate action |
|---|---|---|
| Reachable | Yes | Block |
| Reachable | No | Block if High or Critical, else warn |
| Not reachable | No | Warn, review at next release |
| Not reachable | Yes | Warn loudly, schedule a fix, consider blocking |
| Unknown or cannot analyse | Any | Treat as reachable |
The last row is the important one. Analysis has limits: reflection, dynamic loading and generated code can hide calls. When the tool cannot tell, do not read that as safe.
Steps to introduce it
- Run reachability in report mode alongside your current gate for a month.
- Compare: how many blocked findings were not reachable?
- Sample those and have a developer confirm the analysis by hand.
- If sampling confirms it, let not reachable findings drop to warn.
- Keep the unfiltered count in your reports.
What it does to noise
Developers trust a gate more when it blocks for reasons they can verify. Fewer false blocks also means fewer exemptions to manage, which is a quiet security win because each exemption is a place for mistakes.
Limits to remember
Reachability describes today's code. A refactor can make a function reachable next week, so the result must be recomputed on each scan. It also does not replace patching: an unreachable flaw is still a flaw, and a dependency you never update becomes a problem eventually.
Try it yourself
Open the demo and watch how reachability reduces a long list to the findings that matter. Note what remains.
Click through it at your own pace, or open it full screen.
Safeguard includes reachability analysis, and its policies can use it as one input to a gate. Run the free scan at gold.safeguard.sh/scan.
Quick check
Can reachability say a finding is safe forever?
No. It reflects the current code. Re-run it on every change.
What if the tool cannot decide?
Treat it as reachable and keep the normal rule.
Sources
Last reviewed: 19 October 2026.
