When a vulnerability alert reaches your phone, ask three things in order: is the vulnerable code reachable from your application, is a fix available, and does anything need a human tonight. Reachability evidence answers the first question, and it often turns a page into a ticket for Monday.
Why reachability changes the decision
A dependency can contain a known vulnerability that your code never calls. Reachability analysis traces call paths from your code into the library to see whether the vulnerable function can actually run. The Safeguard iOS listing describes reviewing findings together with the reachability evidence behind each one, which is the part you need on a small screen.
Without it, every alert looks the same size. With it, you can separate "a path exists from an exposed endpoint" from "the package is installed but never imported in a way that reaches the flaw".
Click through it at your own pace, or open it full screen.
The three minute routine
- Read the headline. Package, version, severity, and whether the finding is in production code or a test tool.
- Check the evidence. Is there a call path? Does it start from something exposed to the internet, such as a request handler, or from an internal script?
- Check the fix state. Is there a patched version, and is a fix already in progress or merged?
- Decide. Escalate, assign, or defer with a note.
What to decide on the phone
Reasonable phone decisions:
- Mark it as needing urgent action and ping the owner, when there is a reachable path from an exposed entry point.
- Defer with a written reason, when the code is unreachable and there is no known exploitation. Note that "unreachable today" can change after a refactor, so set a review date.
- Confirm that a fix is on its way and who owns it.
What to leave for a laptop
- Reading a long diff.
- Changing policy or gate settings.
- Anything that needs you to compare versions across many repositories.
- Merging a change to a sensitive service. A tired late night approval on a small screen is how mistakes ship.
Write down the decision
Whatever you decide, record why. A line such as "not reachable from any public handler as of this review, recheck after the next release" saves the next person an hour. It also gives auditors a trail if you later map findings to compliance controls.
Common traps
- Treating "unreachable" as "safe forever".
- Ignoring severity in the other direction: a critical flaw in an exposed library deserves attention even before you finish the analysis.
- Forgetting transitive dependencies, which are often where the vulnerable code lives.
Quick check
Is an unreachable vulnerability safe to ignore?
Not forever. It lowers urgency, but code changes can make it reachable later, so record the reason and set a review point.
Should I merge a fix from my phone?
Only for low risk changes you have already reviewed in full. For anything sensitive, read the diff on a larger screen first.
Sources
Last reviewed: 19 October 2026.
