Reachability analysis

Why it exists

An SCA scan matches package versions against advisories. It knows that a version contains a flaw, but not whether your application uses the part with the flaw. A library with hundreds of functions and one vulnerable parser is reported the same way whether you call that parser or not, and across a large dependency tree that adds up to a backlog nobody can finish.

How reachability analysis works

1. Find the vulnerable code. The tool needs to know which function a vulnerability sits in. Advisories often do not say, so vendors maintain their own data.
2. Build a call graph. It maps which functions call which, from your code down through the dependencies.
3. Look for a path. If a chain of calls leads from your code to the vulnerable function, the finding is reachable. If not, it is marked unreachable and ranked lower.

Levels of reachability

Level	Question it answers	Trade-off
Dependency	Is the package imported at all?	Cheap, and removes unused dependencies only
Function	Can a call path reach the vulnerable function?	The common goal, and needs a call graph and vulnerability data per function
Runtime	Did this code load or run in production?	Evidence from real traffic, but only for what ran while it watched

A real exploit needs more than a path. The input has to reach the function in a form that triggers the flaw, which few tools can tell.

Where reachability analysis falls short

• Unreachable does not mean safe. It means the tool found no path. Reflection, dynamic imports and plugin loading can create paths that static analysis does not see.
• Language coverage varies. Statically compiled languages are easier to trace than dynamic ones, and tools differ on which ecosystems get function-level analysis.
• Vulnerability data is incomplete. If nobody has mapped an advisory to a function, the tool has nothing to look for.
• It changes with your code. Today's unreachable finding can be reachable after the next release, so the answer needs rechecking.
• It only ranks what was identified. A component the scanner never found cannot be analyzed. Without a complete inventory, reachability sorts part of the picture.

How to use it safely

• Use it to order work, not to dismiss it. Fix reachable findings first and schedule the rest, rather than closing them.
• Do not let it overrule active exploitation. A finding in CISA's KEV catalog or with a high EPSS score deserves a human decision even if it is marked unreachable.
• Be careful with internet-facing services. The cost of a wrong answer is highest where attackers can reach you directly.
• Record the reasoning. If you decide a finding does not apply, a VEX statement keeps the decision and tells your customers why.

For how reachability fits with severity, exploit data and business context, see how to prioritize vulnerabilities.

Which tools offer reachability analysis?

Many commercial SCA tools do, including Snyk, Endor Labs, Mend, Checkmarx, Semgrep and Aikido, and the depth differs by language. Go's govulncheck is a free example for one ecosystem. See the best SCA tools compared for what each covers.

Where CRACI fits

CRACI does not offer reachability analysis. It works on the step before it: knowing what is in the build at all. It is a GitHub Actions runner that records every package each job fetches, including the hidden dependencies that lockfile scanners miss, and keeps re-evaluating the SBOMs of what shipped as new vulnerabilities are published. If reachability is your top priority, use a tool built for it next to CRACI. See where CRACI fits next to your SCA tools.

Reachability analysis: frequently asked questions

What is reachability analysis in SCA?

It checks whether your code can actually call the vulnerable function in a dependency, so that findings with no path from your code can be ranked lower.

Is reachability analysis accurate?

It is useful but not proof. A reachable finding has a real path, while an unreachable one only means the tool found none. Reflection, dynamic loading and gaps in vulnerability data can all hide a path.

Can you ignore unreachable vulnerabilities?

Do not ignore them outright. Schedule them behind reachable findings, recheck after code changes, and give extra attention to anything being actively exploited or running in an internet-facing service.

What is the difference between reachability and exploitability?

Reachability asks whether code can get to the vulnerable function. Exploitability asks whether an attacker can use that path to do harm. A flaw can be reachable and still not exploitable in your setup.

Does reachability analysis reduce alerts?

Yes, that is its main purpose. How much depends on the language, the tool and how much of each dependency your code uses.