What Is Reachability Analysis?
Reachability analysis is the practice of determining whether a vulnerability can actually be reached and exploited inside a specific environment. It answers a narrower question than a scanner does. A scanner reports that a CVE exists on a host. The analysis establishes whether an attacker has a viable path to that host, whether the vulnerable service is exposed along that path, and whether the conditions the exploit requires are present.
For security teams, this is the difference between a queue of thousands of “critical” findings and a short list of issues worth an emergency change window. Severity scores are calculated in the abstract, with no knowledge of your segmentation, your firewall policy, or which services are actually listening. Reachability supplies that missing context.
The scope of the term shifts by layer. In application security, SCA reachability analysis examines whether a vulnerable function inside an open-source dependency is ever called by the application at runtime. At the infrastructure layer, vulnerability reachability is a network question: can an attacker traverse from a plausible entry point to the affected asset given real topology and access controls. Both apply the same logic to different graphs.
The Gap Between Vulnerability Discovery and Actual Risk
Discovery is a solved problem. Tenable, Qualys, and Rapid7 do it well, and most enterprises already hold more findings than they can process. The bottleneck sits after discovery, in deciding what to act on.
A vulnerability becomes a real risk only when three things line up: an attacker can reach the asset, the vulnerable component is exposed in a way the exploit can use, and no compensating control breaks the chain. Miss any one of the three and the finding is theoretical, however alarming its CVSS score. In practice, roughly 1% of vulnerabilities in a given environment are genuinely reachable and exploitable, which leaves ~99% of critical findings competing for remediation capacity they do not deserve.
That ratio matters more every quarter. Time-to-exploit has collapsed from years to hours as frontier AI models turn published CVEs into working exploit code, so deferring by severity band no longer buys the time it used to. We worked through that shift in Reachability Analysis: The End of Vulnerability Guesswork.
How Reachability Analysis Works
The method correlates two datasets: what a vulnerability requires, and what the environment allows.
The inputs are the network topology (assets, interfaces, routes), the enforcement layer (firewall rules, security groups, segmentation policy, identity boundaries), the vulnerability inventory from existing scanners, and the exploit requirements for each CVE (network position, privilege level, listening service, configuration state).
The correlation runs in five steps:
- Build the graph. Ingest assets and connectivity to model how traffic can move between segments, subnets, and cloud accounts.
- Layer on enforcement. Apply firewall and policy rules so the graph reflects permitted paths instead of physical adjacency.
- Resolve exploit requirements. For each finding, establish what an attacker would need: a route to a specific port, a foothold at a given privilege level, a particular service configuration.
- Test conditions against the graph. Determine whether a path exists from a plausible entry point that satisfies every requirement.
- Produce evidence. Output the specific path and conditions that make the vulnerability exploitable, or name the control that breaks it.
Step five is the one that changes team behavior. A finding backed by a traced path and a named blocking control is defensible in a change review; a score is not. AI assisted vulnerability reachability analysis extends this by reasoning through exploit conditions at a scale manual review cannot match, evaluating each finding against your specific topology rather than a generic model.
Reachability in On-Prem, Cloud, and Hybrid Networks
On-Prem
On-prem reachability follows physical and logical network structure: VLANs, routing, firewall zones, and east-west controls. Topology changes slowly, which makes the analysis stable over time. The recurring problem is legacy segmentation and undocumented rules that leave open paths nobody intended.
Cloud
In cloud environments, reachability is defined by configuration rather than cabling. Security groups, VPC peering, IAM roles, and service endpoints determine who can reach what, and any of them can change in a single deploy. Identity becomes part of the path, since an over-permissive role can create reachability that no network rule would.
Hybrid
Hybrid is the hardest case, because a single path can cross both models: an on-prem host reached through a cloud workload over a VPN or direct connect. Neither the network team’s view nor the cloud team’s view covers the whole route, and the seam between them is where exposure accumulates. The analysis has to model both domains as one graph, a point we cover in The Blind Spot in Exposure Management: Reachability.
How Astelia Applies Reachability Analysis
Astelia maps your network through read-only integrations and uses agentic AI to analyze exploit requirements against that live topology, surfacing the ~1% of vulnerabilities an attacker can actually reach. Every finding arrives with the path that makes it exploitable and several remediation options, including segmentation and configuration changes rather than patching alone. See Identify True Exposure for how this works in practice.
Related terms: Exposure Management · Vulnerability Management · Understanding CTEM
