Reachability analysis checks whether the vulnerable code in a software library is actually called by your application. If it is not, the risk is lower and the fix can wait. For a CFO, the point is simple: it spends scarce engineering hours on the vulnerabilities that can really hurt, instead of on every alert a scanner raises.
What problem is the CFO paying for today?
A scanner compares your libraries against a database of known flaws. Modern applications pull in hundreds of libraries, so the list of findings is long. Each one costs someone time to read, judge and fix or dismiss. That time is a real line in the budget, and most of it goes to findings that nobody is going to exploit.
Think of a building inspection. A report says "the fire door on floor nine is faulty". Useful. A report saying "every door in every building we own has a part number on a recall list" is not, until someone checks which doors are installed and used. Reachability is that check.
How does it work, in plain words?
Safeguard's documentation describes three kinds of check.
- Static: reads your code and builds a map of which functions call which, then looks for a path from your code to the vulnerable function.
- Dynamic: records what actually runs in production. Vulnerable code that never runs is marked as cold.
- Configuration: reads framework settings to see whether the vulnerable code is switched on at all.
The result is a class on each finding: reachable, conditionally reachable (needs a flag or route that is off today), unreachable, or unknown. Unknown findings are treated as potentially reachable, which is the safe default.
What does the CFO get?
Three things worth saying out loud.
Better ordering. Reachability is one input to a priority score alongside exploit likelihood data, known exploited status and how exposed the system is. The team works the top of the list first and can explain why.
A defensible backlog. "Unreachable" findings are not ignored, they are ranked lower with a reason on record. That is easier to defend to an auditor than a silent mass dismissal.
Less waste, not less safety. The goal is to remove work that does not reduce risk, not to cut the security budget.
What are the honest limits?
Be straight with finance about these, because a CFO will remember a surprise.
Static analysis cannot always decide. Code that uses reflection, runtime evaluation or dynamic dispatch lands in the unknown class. Some vulnerabilities depend on data, not just on whether a function is called, and can be missed even when the function looks unused. Support also differs by language, with some languages in preview for static analysis according to Safeguard's docs.
Also, "unreachable today" can become reachable after the next code change. Reachability is rechecked, it is not a permanent verdict.
How do you put numbers on it?
Do not borrow a vendor's percentage. Measure your own. Here is the arithmetic, using made-up round numbers just to show the method: if your team handles 400 findings a month and spends 30 minutes triaging each, that is 200 hours. If a pilot on your own repositories shows that a quarter of them are unreachable and can be deprioritised with a recorded reason, the saved time is 50 hours a month. Replace each number with your own data from a four week pilot.
What to do
- Count findings per month and the average triage time today.
- Pick two or three representative repositories for a pilot.
- Run reachability on them and record how many findings fall into each class.
- Review a sample of the unreachable ones with an engineer to check the call.
- Multiply saved triage time by loaded hourly cost and present the range.
- Agree a rule for the unknown class and for rechecking after releases.
- Report back after one quarter with real numbers.
Quick check
Does reachability replace patching?
No. It changes the order. Unreachable findings are ranked lower, not deleted, and should still be fixed when convenient or when code changes make them reachable.
Can reachability be wrong?
Yes. Reflection, runtime evaluation and data driven flaws can hide real paths from static analysis. That is why uncertain results are classed as unknown and treated as potentially reachable.
Sources
Last reviewed: 18 October 2026.
