A reachability call path is a chain from an entry point in your code through functions to the vulnerable one. Read it from the top: is the entry point reachable by outside input, does each step really happen, and can the data you control reach the last call. Then fix, mitigate or record an exception.
What a path looks like
Tools format them differently, but the idea is the same.
handleUpload (your code)
parseArchive (your code)
lib.Extract (dependency)
lib.unpackEntry (vulnerable function)
The top line is where execution starts. The bottom line is the flawed function. Everything between is the proof.
Step 1: Check the entry point
Is the first function an HTTP handler, a message consumer, a command line parser, or a test? A path that starts in a test file only matters if tests ship. A path from a public endpoint matters more than one from an admin tool.
Step 2: Check each hop
Open the code for each step. Is the call conditional on a flag that is always off? Is it wrapped in a branch that cannot run in production? Static analysis ignores most conditions, so a path can exist on paper and not in practice.
Step 3: Check the data
Read the advisory. What kind of input triggers the flaw? Now trace the data. Does anything you control or an outside party controls reach the vulnerable call, or is it a constant? The VEX specification treats this as its own case with a label for code that cannot be controlled by an adversary.
Step 4: Decide
| Finding | Action |
|---|---|
| Real path, outside input reaches it | Upgrade or patch now |
| Real path, input is trusted only | Upgrade on your normal schedule |
| Path is not real in practice | Record the reason, set a review date |
| Cannot tell | Treat as reachable until you can |
Step 5: Leave a note
Write down the path, your conclusion and the date. The next person will otherwise redo the work.
A time box
Give each finding ten to fifteen minutes. If you cannot resolve it, escalate or assume reachable. A review that never ends is a backlog of its own.
Click through it at your own pace, or open it full screen.
A short example
A finding shows a path from a function named exportReport through a template library to a flawed formatter. Reading step one shows exportReport is only called by an admin command line tool. Step three shows the formatter only runs with a legacy option that your config disables. The path exists on paper, nobody outside the team can trigger it, and the option is off. You note all three facts, upgrade at the next routine window, and move on.
Quick check
What if the path runs through a test file?
Then it matters only if that code ships or runs in a pipeline with access to secrets. Otherwise lower the priority and note why.
Do I need to read every hop?
For findings you plan to dismiss or escalate, yes. For routine upgrades you do not need to.
Safeguard shows reachable paths on findings so you can do this review. Try the free scan on a repository you know well.
Sources
Last reviewed: 19 October 2026.
