> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Reachability Analysis
> Whether a vulnerable dependency is actually reachable in your application, plus KEV and EPSS exploit signals, so you triage real exposure first
A package can appear in your dependency graph, be imported, and still not be
exploitable in practice: the vulnerable function may never be called, or nothing
an attacker controls may reach it. Reachability is one of the strongest signals
for reducing noise. Combined with advisory severity and the KEV and EPSS exploit
signals below, it indicates which findings to prioritize.
Reachability analysis goes beyond checking whether a package is imported. For each
vulnerable dependency, ZeroPath assesses whether the vulnerable code path is
actually invoked from your application, and weighs whether attacker-influenced
input can reach it.
Reachability and exploitability are related but distinct. Reachability is whether
the vulnerable code is invoked from your code. Exploitability is whether an
attacker can trigger it, given inputs, configuration, and trust boundaries.
Reachability is a necessary condition for exploitability, not proof of it.
## Package reachability
Every vulnerable package receives a reachability status:
* **Reachable** — the vulnerable code path is invoked in your application.
* **Not reachable** — the package is present but the vulnerable path is not
invoked. Dependencies that run only at build or development time are weighted
toward this state.
* **Not tested** — analysis has not run for this package yet.
A package stays **not tested** until analysis has run for it; ZeroPath does not
assume reachability. Each result includes a short summary, and you can filter the
inventory and findings views by package reachability.
A **not reachable** result lowers priority but is not proof of safety. Static and
AI-assisted reachability can miss reflection, dynamic dispatch, deserialization,
and configuration-driven invocation. Do not treat "not reachable" as a reason to
leave a critical or KEV-listed advisory unpatched.
## Exploitability on findings
At the finding level, ZeroPath rolls each finding's reachability verdict into the
exploitability buckets you can filter the findings view by:
* **Likely exploitable** — reachable.
* **Needs review** — reachability is ambiguous.
* **Likely not exploitable** — not reachable.
* **Not yet analyzed** — analysis has not completed for this finding.
Findings in the likely-exploitable bucket are the highest priority. Reachable
findings can be addressed with [auto-remediation](/sca/remediation), which opens
upgrade PRs. The [preconditions](#preconditions) on a finding indicate what still
has to be true for a reachable issue to fire.
## Exploit intelligence: KEV and EPSS
Reachability tells you whether a vulnerability is exploitable in your code. Two
industry feeds tell you whether it is being exploited in the wild, and ZeroPath
enriches every CVE finding with both, refreshed daily:
* **CISA KEV** (Known Exploited Vulnerabilities) flags a finding as **Known
exploited** when its CVE is in CISA's catalog of vulnerabilities under active
exploitation, with the date CISA added it and a known-ransomware-campaign flag.
An active-exploitation listing is the strongest priority signal for a finding.
* **FIRST EPSS** (Exploit Prediction Scoring System) is the probability that a CVE
will be exploited in the next 30 days, shown as an **EPSS** score with its
percentile rank, so you can rank not-yet-exploited CVEs by likelihood.
A finding that is reachable, KEV-listed, and high-EPSS is your top priority. A
not-reachable finding with a low EPSS score and no KEV listing can usually wait.
If a CVE is not in KEV or EPSS does not score it, no badge is shown. When a feed
cannot be reached during a scan, ZeroPath records an
[Exploit intelligence unavailable](/sca/coverage) coverage warning.
## Preconditions
When a vulnerability is reachable but its exploitation depends on conditions that
cannot be confirmed from code alone, ZeroPath surfaces **preconditions**, for
example "Vulnerable method is only called with server-controlled input" or
"Requires a specific runtime configuration to trigger." Preconditions let you
judge real-world exploitability for each reachable finding.
## Transitive triage
Most dependencies are transitive, and investigating every transitive CVE
indiscriminately buries the findings that matter. Before spending analysis effort
on a transitive vulnerability, ZeroPath evaluates whether the dependency chain
actually exposes it. Deep, opaque chains and development-only dependencies are
deprioritized, so investigation concentrates where a real, reachable path is
plausible.
## Threat model & application context
If you have configured a [threat model](/platform/threat-model) or application
context for a repository, reachability analysis and transitive triage incorporate
it. Out-of-scope areas, trust-zone boundaries, and assumptions you define factor
into reachability verdicts, so dependencies in subtrees you have marked out of
scope generate far less noise.
Reachability and exploitability are AI-assisted, probabilistic assessments. Treat
them as prioritization signals, and confirm critical supply-chain findings with
human review before relying on them to deprioritize a finding or auto-merge a fix.