Deciding which vulnerabilities can actually be exploited in your code — and ignoring the rest.
Reachability analysis is the technique of determining whether a vulnerability in a dependency can actually be exploited from your application. A package can contain a critical CVE and still be harmless to you if your code never touches the vulnerable function. A package with a medium-severity CVE can be an immediate incident if the vulnerable function sits on your request path.
The analysis works by building a call graph of your application plus its dependencies, marking the known-vulnerable functions as sinks, and checking whether any path through your code reaches them from an untrusted source. If no reachable path exists, the vulnerability is present but not exploitable — and a mature security program quietly deprioritises it.
Three stages, at a high level:
A modern application depends on hundreds of packages and inherits thousands of known vulnerabilities across its transitive tree. Treating every finding as equally urgent exhausts engineering teams and ensures the actually-exploitable ones get lost in the noise.
Reachability analysis changes the question from "which CVEs are in my dependency graph?" (a list measured in the hundreds or thousands) to "which CVEs can reach my code from an untrusted input?" (usually a list measured in tens). That is a backlog a security team can actually work through.
Reachable-only filtering typically eliminates 70–85% of the raw SCA backlog without increasing real risk.
Engineers fix a smaller, more exploitable list faster than a bigger undifferentiated list. The P95 case improves even more.
"We reviewed every critical CVE and can show whether each is reachable in our codebase" is a more defensible posture than "we have 1,400 open CVEs and are working on them."
A finding that says "this is reachable from /api/login through these 5 hops" is actionable. A finding that says "CVE-2024-X in transitive lodash" usually is not.
The number of engineer-hours spent per actually-prevented incident improves by a factor you can quantify — and point at on a board slide.
Reachability is the backbone of Safeguard's triage output and fix prioritisation. It also feeds the zero-day discovery pipeline — where reachable taint paths become the structured context Griffin AI uses to hypothesise exploit conditions.
Point Safeguard at a repo. Get a reachable-only backlog back. Compare it to your current scanner's output.