Re-run reachability analysis whenever the code, the dependencies or the advisory data changes. In practice that means on every pull request, on every dependency update, and on a schedule for findings you set aside as unreachable. A not reachable label describes one build on one day, not a permanent fact.
Why results go stale
Three things feed a reachability result: your code, your dependency versions, and the advisory data naming vulnerable functions. Change any one and the answer can flip.
The triggers
- A pull request that adds or changes a call. A new import can wake a dormant function. Run on the diff.
- A dependency upgrade or downgrade. New versions add and remove functions, and they change which internal calls the library makes.
- A new entry point. A new endpoint, job or consumer creates new starting points.
- An advisory update. Records get revised. A record that listed no function can later gain one, and a path may appear.
- A tool or analysis update. Better call resolution can reveal paths the old version missed.
- A deployment change. Enabling a feature flag or a plugin can turn on code that was off.
A review cadence for set aside findings
| Finding type | Re-check |
|---|---|
| Critical or high, unreachable | Every release, and monthly at minimum |
| Medium, unreachable | Quarterly |
| Low, unreachable | On dependency upgrades |
| Anything with a KEV listing | Immediately on a new entry |
These intervals are a starting suggestion, not a standard. Adjust to your release speed and risk.
Make it automatic
Manual re-checks fade. Put the analysis in CI so each change triggers it, and store the result with the commit. A set aside finding then reopens by itself if a path appears, instead of waiting for someone to remember.
Pair this with the exception habit in how to set up a security exception process, where every exception carries an owner and an expiry date.
What to record
- The commit and date analyzed.
- The tool and version.
- The conclusion and the reason.
- The next review date.
A small example
A team marks a high severity finding unreachable in March because their service never calls the parsing function. In June a developer adds an import feature that calls it. With analysis in CI, the pull request check flags the finding as reachable before merge, and the developer picks a fixed version in the same change. Without it, the flaw ships and sits unnoticed until the next quarterly review.
Quick check
Is a nightly scan enough?
It catches advisory changes. It will not catch a pull request before merge. Use both a change trigger and a schedule.
Should a reopened finding alert someone?
Yes, especially when a previously unreachable high severity item becomes reachable. That is the event this process exists to catch.
Safeguard runs reachability analysis as part of dependency scanning and can sit in pull request checks. See the free scan.
Last reviewed: 19 October 2026.
