Reachability

A CVE against a package you depend on is not automatically a fire drill. If the vulnerable code path is a transitive dependency you never import, on a service that is not internet-facing, it matters far less than the same CVE in a package your code calls directly on a public endpoint. Reachability captures that difference and puts the alerts that actually matter at the top.

How it works

Reachability combines three independent signals into a single EffectivePriority (0-100) and a plain-language verdict on each alert:

• Usage - how your project uses the package, gathered locally by av reach analyze. It uploads evidence (package names, manifest paths, file:line import sites) - never your source.
• Exploit context - EPSS, CISA KEV, and the CVE’s attack vector.
• Exposure - whether you have declared the project internet-facing.

The result is a verdict badge on every alert - Likely exploitable, Needs review, Likely not exploitable, or Unanalyzed - with the evidence one click away.

It annotates, it does not hide

Reachability prioritises; it never changes an alert’s RED / YELLOW / GREEN tier and never suppresses an alert. When the machine gets it wrong, one click records a human override with a reason, and the override wins from then on.

Reachability is a Business and Enterprise capability.

In this section

av reach analyzeGather usage evidence locally and upload it - never your source.

How EffectivePriority worksThe three layers, KEV pinning, and the verdict bands.

Reading and overriding verdictsWhere the verdict shows up and how to override it.

Prioritise alerts with reachabilityWire av reach analyze into CI in a few minutes.

SAST reachability verdictsWhat each code-finding verdict means and why some findings read Not applicable.