What Is Reachability Analysis and Why Does It Matter? | Blog | Endor Labs

What it is

An Endor Labs explainer on reachability analysis — determining whether an application's execution paths actually reach a vulnerable function in a dependency, rather than just flagging every package that matches a known CVE. The summary already names the three approaches and five types; what it cannot carry is the tradeoff each one forces and what each type actually surfaces, which is the decision-relevant content below.

How it works

The analysis builds a call graph of your application and traces execution paths from your code's entry points to the vulnerable function inside a dependency. A path existing means reachable; no path means it drops off the priority list.

The three approaches trade accuracy, coverage, and overhead differently:

flowchart TD
    Q[Which reachability approach?] --> S[Static: reads source/bytecode]
    Q --> D[Dynamic: instruments running app]
    Q --> R[Runtime: monitors production]
    S --> S1[Complete coverage, no overhead;<br/>misses reflection/dynamic dispatch,<br/>flags paths that never run]
    D --> D1[Real runtime behavior;<br/>only sees paths tests exercise,<br/>adds instrumentation overhead]
    R --> R1[Ground truth under real load;<br/>reactive not preventive,<br/>privacy questions, misses edge cases]

The five types describe what is measured, not how it runs:

• Function-level — traces whether your code calls the specific vulnerable function; highest noise reduction, but depends on a CVE-to-function database (Endor builds theirs via program analysis).
• Dependency-level — coarser; asks only whether a vulnerable dependency is used at all. Excludes unimported and test/dev dependencies, and surfaces phantom dependencies (packages used but never declared in a manifest).
• Package baselining — flags deviations from a package's normal behavior (e.g., Log4j calling the network or executing code instead of just touching the filesystem); works for prioritization and active blocking.
• Package usage in containers — identifies which OS/base-image packages your app actually invokes, so you patch those instead of hundreds of unused system libraries — the point that makes a FedRAMP 30-day patching window achievable.
• Internet reachability — combines network topology with vulnerability data to rank internet-facing services first.

What to do

This is a conceptual explainer — no patches, commands, or CVE IDs. Use it to choose an approach: function-level for maximum noise reduction, dependency-level for a simpler cut, package-in-container to escape mass system-library patching, and internet reachability to triage external attack surface.

Caveats

Each approach has a stated limit (above); none is complete alone. Static over-reports via reflection/dynamic dispatch; dynamic and runtime under-report paths that tests or production load never exercise. The page is vendor content and does not benchmark these tradeoffs quantitatively.