Is reachability analysis the same as SAST?

No. SAST looks for possible flaws in code you wrote. Reachability analysis starts from a known vulnerability in a dependency and asks whether your application can actually call the vulnerable code. They share methods, such as call graphs and data flow, but they answer different questions.

Two questions, two tools

A SAST tool might tell you a line builds a query from user input. A reachability check might tell you that a library you depend on has a known flaw, and that your code never calls the affected function.

What they share

Both rely on analyzing code without running it. Both build a picture of how functions call each other and how data moves. That is why a vendor may offer both on one engine, and why the vocabulary overlaps. OWASP describes static analysis as using techniques such as taint analysis and data flow analysis. Reachability uses related ideas, applied to the question of whether a call path exists.

Where each one stops

SAST has the limits OWASP describes: false positives, difficulty with code that cannot be compiled, and weakness in finding access control or configuration problems.

Reachability has its own limits. A static call graph is an estimate. Reflection, dynamic loading and plugin callbacks can hide a call path, so "not reachable" is a strong hint, not a guarantee. Related posts explain what static analysis misses with reflection and whether a call graph is exact.

How teams use them together

A sensible order for triage:

1. Fix findings from SAST that are in exposed code and have high confidence.
2. For dependency alerts, check reachability first. A reachable vulnerability in an exposed service goes to the front of the queue.
3. Keep unreachable ones on a watch list. A code change can make them reachable later.

This does not mean ignoring unreachable vulnerabilities forever. It means ordering work so the likely exploitable items come first.

What to ask a vendor who offers either

For SAST, ask about languages, build needs and how data flow is followed. For reachability, ask which ecosystems are supported, whether the result shows the call path, and how the tool handles reflection. Ask to see a real path, not a score.

A worked example: one service, two questions

A team maintains an order service. Two reports land on the same day.

The SAST report says: in the refunds handler, a request value reaches a file path without a check. That is a possible path traversal, found in code the team wrote. The action is a code change.

The dependency report says: the XML parsing library at version 2.3 has a published flaw in a function that handles external entities. The fix is in version 2.4. The question is whether the team's code ever calls that function.

A reachability check answers it. It builds a picture of which functions the application calls, then looks for a path to the flawed function. Suppose the service only uses the parser's simple text mode and never enables external entities. The result: the vulnerable function is not reachable. The team still plans the upgrade, but it moves down the queue behind the file path issue.

Notice that neither report substitutes for the other. The first finds a flaw in the team's own code. The second narrows a list of alerts about code the team does not control.

Step by step: triage a mixed backlog

1. Separate findings by origin: your code, or a dependency.
2. For your code, sort by confidence and exposure, and assign owners.
3. For dependencies, run reachability first. Group results as reachable, not reachable and unknown.
4. Fix reachable items in exposed services first.
5. For not reachable items, schedule routine upgrades.
6. For unknown items, treat them as reachable until someone reviews.
7. Rescan after changes, since reachability can change when code changes.

Where each method gets its input

Reachability depends on the inventory, so it is natural to run it after dependency scanning has identified what is vulnerable.

Why "unknown" is a real category

Static call graphs are estimates. Frameworks call your code through reflection, annotations and configuration, and plugins can register callbacks at runtime. A tool that cannot resolve these will either guess or mark the result unknown. Good tools show you which. If a vendor reports only "reachable" and "not reachable," ask how reflection and dynamic loading are handled. The honest answer includes the words "it depends" and a description of what the tool does in those cases.

How to evaluate a reachability claim

1. Pick a dependency alert where you already know the answer, for example a library function your code clearly calls.
2. Pick another where you know the function is never called.
3. Check that the tool reports them correctly and shows the path for the first.
4. Pick a case with reflection and see how the tool describes it.

The exercise takes an afternoon and gives you far more insight than a feature list.

Combining the signals

Reachability is one input among several for prioritizing dependency alerts. Others include whether the service is exposed to the internet, whether the flaw is known to be exploited, how severe it is and how hard the fix is. Treat reachability as a strong filter, not a final decision, and keep a watch list so that changes in your code do not quietly bring an old issue back into play.

Reporting

When you report to leadership, separate the two counts. "Eleven findings in our own code, four high confidence. Sixty dependency alerts, of which nine are reachable." That structure is clear, and it shows why the numbers should not be added together.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a list of dependency alerts shrinks when calls are checked.

Quick check

Safeguard's reachability analysis, which traces whether vulnerable code is actually called, is generally available, along with SBOM and dependency scanning. You can try the free scan at gold.safeguard.sh/scan.

Sources

• OWASP, Static Code Analysis

Last reviewed: 19 October 2026.