Reachability analysis checks whether the vulnerable part of a software library is actually used by your application. A scanner without it flags every library with a known flaw. With it, the team can focus first on flaws their code can really trigger. For a committee, call it sorting alerts by whether the door can be opened.
The plain words version
Say it in four sentences:
- Our software uses many outside libraries.
- Some libraries have publicly known flaws.
- A flaw only matters if our code can reach the broken part.
- Reachability analysis tells us which flaws we can reach, so staff fix those first.
A house analogy
A building has fifty doors with faulty locks listed in a report. Forty of them open into a sealed room nobody enters. Ten open onto the street. A guard who fixes all fifty at once may still be fixing the first forty when something happens at the street doors. Reachability sorts the doors.
Be honest about the limit: a flaw that is not reachable today can become reachable after a code change, so teams keep watching.
What the committee needs to decide
| Question | Why the committee cares |
|---|---|
| Does this reduce staff time on alerts? | Staff time is the scarce resource |
| Can we see why an alert was ranked low? | Trust requires the reasoning |
| What does it miss? | No method catches everything |
| Who reviews the low priority list? | Someone must own it |
Three questions to ask a vendor
- How does the tool decide something is not reachable? Look for a clear description, such as tracing calls from your code into the library.
- Can we see and override the decision? Staff must be able to inspect and challenge a ranking.
- What happens when code changes? The ranking should update when the code does.
What not to promise
- Do not say reachability removes risk. It reorders work.
- Do not say a low rank means ignore. It means later, with a review date.
- Do not compare alert counts between tools without knowing how each counts.
What to say if someone objects
A common objection is "if a flaw exists, why not just fix everything?" The honest answer is that staff time is limited and some updates break things. Updating a library can force changes elsewhere, and in a small team each change needs testing. Reachability does not argue against fixing. It argues for an order, with the most exposed items first and the rest on a schedule.
Another objection is "can we trust the tool's judgment?" That is why the pilot checks a sample by hand. A tool earns trust by being right on your own code, not by a claim on a slide.
A pilot measure that fits
Pick one project. Count findings before reachability and after. Then have a developer check a sample of the "not reachable" group by hand. If the sample holds up, the committee has evidence from its own code.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how the finding list shrinks when unreachable items move down, and note what stays at the top.
Safeguard includes reachability analysis alongside dependency scanning, and offers a free scan at gold.safeguard.sh/scan so you can see a result on your own project.
Quick check
Does reachability analysis mean unreachable flaws can be ignored?
No. They can be scheduled later and rechecked when code changes.
How can a committee test the claim?
Run a pilot on one project and hand check a sample of the findings marked not reachable.
Last reviewed: 19 October 2026.
