Unreachable does not mean the upgrade is free. Reachability lowers the urgency of the fix, but the upgrade can still break the code you do call. Size testing by what the upgrade changes, not by how scary the advisory looks, and use the extra time to test properly instead of skipping the work.
Two separate questions
When a scanner flags a vulnerable dependency, two questions get mixed up.
- How urgent is it? That depends on whether the vulnerable code can be reached and exploited in your application.
- How risky is the upgrade? That depends on what changes between the old and new versions, and which of those changes touch code you use.
Reachability analysis answers the first. It says little about the second. A package can have a vulnerable function you never call and a changed parsing routine that you call on every request. The upgrade is risky even though the vulnerability is not.
What unreachable buys you
Time and choice. If the vulnerable function is not called, you are less likely to need an emergency merge, and you can pick a calm moment, a smaller step or a batch with other updates. You can also schedule a proper test pass, a canary release and a rollback plan without pressure.
It does not buy you permission to ignore the finding. Code paths change. A feature added next quarter may call the function. A reachable status today is a statement about today's code, so record it with a date and revisit it when the code changes.
Size the testing by what changed
| What the upgrade changes | Testing to run |
|---|---|
| Only the vulnerable function and its tests | Full existing suite, quick smoke test |
| Code you call, behavior unchanged | Existing suite plus the features that use the package |
| Code you call, behavior changed | Targeted tests for the changed behavior, replay of real inputs |
| Large upgrade across many versions | Plan as a project, stage it and keep a rollback |
| Transitive dependency you never import directly | Check the lockfile diff and run the suite on the full tree |
To find out what changed, read the release notes and compare the two versions, as described in our post on reading the diff between two package versions.
A sensible routine
- Record the reachability result with the date and how you determined it.
- Set a deadline. Unreachable findings still need an owner and a date, usually further out than reachable ones.
- Combine with scheduled updates. Merge the fix with the next batch of routine updates if your process allows it.
- Run the suite and a smoke test at minimum, and add targeted tests where the diff shows changed behavior you rely on.
- Re-check reachability when the code that calls the package changes.
When to move faster anyway
Raise the priority if the vulnerability is being actively exploited, if reachability analysis is uncertain, if the package is on a path that handles untrusted input, or if a customer or auditor asks for the fix. Reachability is evidence, not a verdict, and uncertain evidence should not delay an easy fix.
Safeguard offers reachability analysis to show whether vulnerable code is called by your application, along with dependency scanning and policies and gates so that your own rules decide what blocks a merge. Its autonomous remediation can open fix pull requests, but it is off by default with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and watch how many findings drop out once reachability is applied, then think about which of the rest you would test first.
Quick check
Can I skip the fix entirely if the code is unreachable?
You can defer it with a recorded decision and a review date, but code changes can make it reachable later. Most teams still fix it in a normal release.
Does reachability reduce the testing I need?
It reduces urgency, not testing. The upgrade can break the code you do use, so test according to what the upgrade changes.
Last reviewed: 19 October 2026.
