Yes, often. Research projects pull in large scientific stacks, and most findings sit in code the analysis never calls. Reachability analysis checks whether your code can actually reach the vulnerable function. It shrinks the list to what to fix first, but it does not prove the rest is safe.
Definition
A dependency scan lists packages with known vulnerabilities. Reachability analysis adds a second question: does your project call the affected function or code path, directly or through other packages?
If the answer is no, the finding is real but not currently exploitable through your code. If yes, it moves up the list.
Why research code gets so many findings
A single imaging or statistics script can import a package that depends on dozens of others. A typical notebook environment has hundreds of packages, most of which you did not choose. Many advisories apply to features such as network servers, archive extraction or template rendering that a numerical script never touches.
That produces long reports and tired people. A student who sees 200 findings often fixes none.
What it looks like in practice
| Finding | Package used? | Vulnerable function called? | Action |
|---|---|---|---|
| Archive extraction flaw | Yes, for reading datasets | Yes | Fix now |
| Web server flaw in a plotting library | Imported | No server started | Schedule |
| Parser flaw in a library used only in tests | Test only | No | Defer |
The first row matters because it handles files from outside the lab. The others are real findings that can wait.
Where it falls short
- Dynamic behavior. Code that loads modules by name at run time is hard to trace.
- Notebooks. The code path can change from one cell run to the next.
- Changing use. A project that does not call a function today may call it after the next edit.
- Not a clearance. Unreachable means not reached today. Update when it is cheap.
So treat reachability as a way to order work, not as a reason to close findings forever.
A simple routine
- Scan the project for known vulnerabilities.
- Mark findings that handle untrusted input, such as downloaded data, uploads or network requests, as highest priority regardless.
- Use reachability to sort the rest.
- Update the reachable ones this term and schedule the others for the next routine rebuild.
- Record the reason for each deferral.
Questions to ask about any tool
When you try a reachability feature, ask which languages it supports, whether it follows calls across package boundaries, and how it treats code loaded at run time. Ask what it reports when it cannot decide. A tool that says unknown is more useful than one that guesses.
Also check that the result is explained. A reviewer, a funder or a colleague will want to see why a finding was ranked low, and a call path or a short reason is much easier to defend than a score.
Try it yourself
Open the reachability demo and compare the list before and after reachability is applied. Look for how many findings drop to a lower priority.
Click through it at your own pace, or open it full screen.
Safeguard includes reachability analysis alongside dependency scanning. You can see how it sorts a real project with the free scan.
Quick check
Can I ignore unreachable findings?
Not permanently. They are lower priority today, but a code change or a new feature can make them reachable.
Is reachability useful for notebooks?
It helps, but notebooks change often, so recheck after significant edits.
Last reviewed: 19 October 2026.
