What is reachability analysis?
Reachability analysis examines whether vulnerable code or misconfigured resources can be accessed and exploited through available attack paths. Modern platforms use an agentless security graph to unify network exposure, effective permissions, and data sensitivity—showing you both exploitability and blast radius in one view rather than requiring manual correlation across multiple tools.
Traditional vulnerability scanning creates long lists of potential security issues without explaining which ones matter most. Reachability analysis adds context by examining network exposure, identity permissions, and data flows to show you the complete picture. It maps the path from an entry point (internet-exposed load balancer, public S3 bucket) to a vulnerable component (misconfigured database, container with CVE, overprivileged service account) to validate whether an attack is actually possible in your environment.
Secure Coding Best Practices [Cheat Sheet]
The Secure Coding Cheat Sheet is designed to be your comprehensive, go-to resource for embedding security into every stage of your code development.
Why reachability analysis matters for cloud security
Cloud environments create complex interconnections between services, workloads, and identities that change constantly—36% of organizations have at least one cloud asset that supports more than 100 attack paths. Traditional security tools struggle to keep up with this complexity, which leads to alert fatigue where teams drown in low-priority warnings.
Reachability analysis solves this problem by focusing on exploitable vulnerabilities. It identifies toxic combinations such as a public-facing VM with a critical CVE (CVSS 9.0+) and overprivileged IAM roles granting access to sensitive data—concerning since 76% of organizations have at least one public-facing asset that enables lateral movement. When Bridgewater Associates used reachability analysis during the Log4Shell crisis, they discovered their actual exposure was much larger than initial scans showed, allowing them to focus remediation efforts on the vulnerabilities attackers could actually exploit.
Reachability-based prioritization vs severity-only triage
Traditional vulnerability management prioritizes based on CVSS scores alone, creating significant inefficiencies.
Severity-only approach
Treats all critical CVEs (CVSS 9.0+) as equally urgent
Generates thousands of high-priority alerts in large environments
Ignores whether vulnerabilities are actually exploitable
Wastes resources on unreachable issues while missing exploitable paths
Creates alert fatigue and deprioritization of security findings
Reachability-based approach
Combines CVSS with exploitability and blast radius
Identifies "toxic combinations" where multiple risks intersect
Focuses remediation on attack paths to critical assets
Reduces alert volume by 60-80% while increasing risk reduction
Enables risk-based conversations with business stakeholders
Example comparison
Severity-only: "You have 2,847 critical vulnerabilities to patch immediately"
Security team overwhelmed, unclear where to start
Business pushback on disruption and resource requirements
Many "critical" CVEs are in isolated dev environments
Reachability-based: "You have 12 exploitable attack paths to production databases, 3 are internet-reachable"
Clear prioritization based on actual risk
Business understands the specific threat to customer data
Focused remediation on paths that matter
This shift from vulnerability-centric to risk-centric prioritization aligns security efforts with business impact and enables more efficient resource allocation.
Compliance and regulatory alignment
Reachability analysis supports multiple compliance frameworks by demonstrating risk-based vulnerability management. It provides auditors with evidence that your organization prioritizes vulnerabilities based on actual risk and business impact, not just severity scores—and demonstrates compensating controls by showing when high-severity CVEs pose minimal risk because vulnerable components are unreachable from any entry point.
Key framework mappings:
ISO 27001: Risk-based prioritization demonstrates policy effectiveness (A.5), reachability context shows which assets pose real risk (A.8), and attack path analysis validates technical vulnerability management (A.12)
SOC 2: Demonstrates continuous risk identification (CC3), validates least privilege implementation (CC6), and shows effective change management through attack path closure (CC7)
NIST 800-53: Adds exploitability context to vulnerability scanning (RA-5), validates connection security (CA-3/CA-7), and demonstrates effective permission boundaries (AC family)
PCI DSS 4.0: Validates vulnerability remediation prioritization (Requirement 6), demonstrates network segmentation effectiveness (Requirement 11), and shows mature security program maturity (Requirement 12)
Vulnerability Management: The Complete Guide
Learn about vulnerability management and how you can improve your cloud security with best practices and tools—plus how you can get a 1-on-1 assessment.
Read more
Types of reachability analysis approaches
Different reachability analysis methods serve different purposes in your security strategy. Understanding each approach helps you choose the right tools for your specific needs.
Static reachability analysis
Static analysis examines code and configurations without executing them. This approach scans Infrastructure as Code templates, application source code, and dependency trees to map potential attack paths before deployment.
The main benefit is catching security issues early in development, which supports shift-left security practices. However, static analysis cannot always predict runtime behaviors or detect misconfigurations that only appear in live environments.
Dynamic reachability analysis
Dynamic analysis monitors actual runtime behavior and network traffic to validate exploitability. It observes how components interact in live environments to confirm whether theoretical attack paths are actually traversable.
This method provides higher accuracy because it's based on real execution paths and runtime conditions. The tradeoff is higher resource requirements and the fact that it typically identifies issues after deployment to staging or production.
Real-time reachability analysis
Near real-time analysis continuously monitors your cloud environment and detects changes that affect reachability (network paths, identity permissions, and resource configurations) as they happen, typically within seconds to minutes of the change. This matters in dynamic cloud environments where resources and permissions change within minutes.
Continuous monitoring and drift detection ensure your risk assessment stays current. You get immediate alerts when new exposures appear, enabling rapid response to emerging threats.
Telemetry sources and update latency
Near real-time reachability analysis depends on multiple data sources with different latency characteristics:
Cloud audit logs and APIs: Configuration changes appear within 30 seconds to 2 minutes, IAM policy updates propagate in 1-5 minutes, and network rule changes take seconds to minutes
Runtime telemetry: eBPF-based monitoring and service mesh observability provide sub-second to real-time visibility into traffic flows and container activity
Identity graph evaluation: Effective permissions calculation takes minutes to hours for complex role chains, with continuous updates as policies change
External attack surface: Internet-facing asset discovery runs hourly to daily, while DNS and certificate monitoring detects new exposures within minutes to hours
Most platforms achieve near real-time updates within 5-15 minutes for configuration changes, with runtime telemetry providing sub-minute visibility into active threats.
Watch 5-minute demo
Watch the demo to learn how Wiz Code scans infrastructure as code, container images, and CI/CD pipelines to catch risks early—before they reach the cloud.
Watch now
How reachability analysis works in practice
Reachability analysis combines data from across your cloud environment to build a complete risk picture. The process starts with asset discovery to inventory all cloud resources, then maps dependencies between applications, services, and infrastructure components.
The analysis creates a security graph that models relationships between all assets. It evaluates network paths, firewall rules, and permission chains to determine how attackers could move laterally through your environment. Advanced platforms add code-to-cloud correlation, tracing runtime findings back to specific Infrastructure-as-Code files, Git repositories, and developer owners—enabling source-level fixes and prevention in CI/CD pipelines rather than just runtime patching. Finally, it correlates these findings to score risks based on actual exploitability and potential impact, giving you a prioritized list of issues to fix.
Provider-specific reachability examples
Reachability analysis adapts to each cloud provider's networking and identity models:
AWS reachability paths:
Network layer: Security Groups, NACLs, VPC peering, Internet Gateways, and Transit Gateways determine which resources can communicate
Identity layer: IAM policies, STS AssumeRole chains, resource-based policies, and SCPs create permission paths to data
Service layer: Lambda triggers (S3, SQS, EventBridge), ECS task roles, and EKS pod identities extend reachability through event-driven architectures
Example path: Internet → ALB (public) → ECS task (vulnerable container) → IAM task role → RDS database (customer data)
Azure reachability paths:
Network layer: NSGs, Azure Firewall, Private Endpoints, UDRs, and VNet peering control connectivity
Identity layer: Azure AD role assignments, Managed Identities, and App registrations define access paths
Service layer: AKS NetworkPolicies, Function App triggers, and Logic App connectors create service-to-service reachability
Example path: Internet → Application Gateway → AKS pod (CVE) → Managed Identity → Key Vault → Storage Account (sensitive data)
GCP reachability paths:
Network layer: VPC firewall rules, Cloud Armor, VPC Service Controls, and Shared VPC determine network reachability
Identity layer: Service Account IAM bindings, Workload Identity, and Organization Policies control access
Service layer: GKE NetworkPolicy, Cloud Run ingress, and Pub/Sub subscriptions enable service communication
Example path: Internet → Cloud Load Balancer → GKE pod (misconfigured) → Service Account → Cloud SQL → GCS bucket (PII)
Kubernetes-specific considerations:
Services (ClusterIP, NodePort, LoadBalancer) expose pods to different network scopes
Ingress controllers and service meshes (Istio, Linkerd) add mTLS and policy layers
NetworkPolicy defaults (allow-all vs deny-all) dramatically change reachability
RBAC and admission controllers (OPA, Kyverno) gate identity-based access
Ephemeral pods and dynamic service discovery require continuous reachability updates
What is cloud security testing?
Cloud security testing is the process of evaluating your entire cloud infrastructure for security risks and misconfigurations—proactively, systematically, and continuously.
Read more
Benefits of implementing reachability analysis
Reachability analysis dramatically reduces false positives and alert noise. You stop wasting time on vulnerabilities that pose no real threat because the analysis confirms which issues are actually exploitable. Platforms that validate reachability both externally (outside-in attack surface scanning) and internally (graph-based path analysis) help teams remove truly exploitable paths first, reducing mean time to remediate (MTTR) for critical issues by 50% or more.
This leads to faster remediation times. When teams have a clear, validated list of critical issues, they can resolve them more efficiently. Organizations have used reachability context to eliminate critical vulnerabilities in production environments and sustain 'zero critical' states by focusing remediation on exploitable paths rather than all detected CVEs.
How to measure reachability analysis success
Track these metrics to quantify the impact of reachability-based prioritization:
Vulnerability metrics:
Percentage of reachable critical/high CVEs (target: <5% of total CVEs)
Mean time to remediate (MTTR) reachable issues vs non-reachable (target: 50% faster for reachable)
Number of reachable vulnerabilities in production (target: zero critical reachable)
Attack path metrics:
Number of closed attack paths to sensitive data stores (track monthly reduction)
Percentage of public-facing assets with paths to crown jewels (target: <10%)
Average attack path length to critical assets (target: increase through segmentation)
Operational metrics:
Reduction in security alerts requiring investigation (target: 60-80% reduction)
Percentage of remediation efforts focused on exploitable issues (target: >80%)
Time from vulnerability disclosure to reachability assessment (target: <24 hours)
Business impact metrics:
Security team productivity (hours saved on false positive triage)
Risk reduction velocity (critical exposures eliminated per sprint)
Audit and compliance efficiency (evidence of risk-based prioritization)
Challenges and limitations of reachability analysis
Scalability presents the biggest challenge for reachability analysis. Large cloud estates with millions of resources and dependencies create significant performance overhead during comprehensive analysis.
Maintaining accuracy in highly dynamic environments poses another major hurdle. Resources constantly get created and destroyed, so analysis models must update continuously or they quickly become outdated. Agentless, API-based discovery combined with near real-time telemetry keeps the reachability graph fresh in dynamic clouds—without the operational overhead of deploying and managing agents across thousands of ephemeral workloads. This creates coverage gaps where new threats slip through undetected—concerning given that recent industry reporting indicates the majority of interactive intrusions are malware-free and often exploit misconfigurations and identity abuse rather than software vulnerabilities.
Best practices for effective reachability analysis
Following proven strategies helps you get maximum value from reachability analysis. These practices ensure your analysis stays accurate, efficient, and integrated into existing workflows.
Integrate reachability analysis into development lifecycle
Embed security checks early in CI/CD pipelines to catch issues before production deployment. This shift-left approach creates feedback loops between runtime findings and development teams, building a culture of proactive security.
Early detection means:
Vulnerabilities get fixed during development when changes cost less
Security becomes part of the development workflow rather than a blocker
Teams learn secure coding practices through immediate feedback
Combine reachability analysis with SCA
Software Composition Analysis identifies open-source components and third-party libraries in your applications. Combining dependency scanning with reachability analysis shows whether vulnerabilities in dependencies are actually reachable through your code.
This combination helps you:
Understand which vulnerable dependencies pose real risks
Prioritize patching efforts on exploitable issues
Secure your software supply chain more effectively
Handle false positives and negatives
No analysis tool achieves perfect accuracy, so you need processes for managing incorrect results. Tune analysis thresholds to reduce noise without sacrificing coverage, and implement validation workflows to verify findings.
Regular reviews help you:
Identify patterns in false positives and adjust rules
Catch false negatives before they become incidents
Maintain team confidence in analysis results
Keep analysis models updated
The threat landscape evolves constantly with new vulnerabilities and attack techniques emerging daily. Your reachability analysis needs current threat intelligence to stay effective.
Regular updates ensure:
Detection rules catch the latest attack patterns
Scanning algorithms identify new vulnerability types
Analysis stays relevant as your environment changes
Foster team training and knowledge sharing
Reachability analysis provides deep insights, but teams need training to interpret and act on them. Build organizational expertise through security champions programs and cross-team collaboration.
Effective training programs:
Help developers understand security context in their code
Enable security teams to communicate risks clearly
Create shared responsibility for remediation
How Wiz connects vulnerabilities to exploitable attack paths through reachability analysis
Wiz's agentless Security Graph performs comprehensive reachability analysis across network, identity, and data layers in minutes—without agents or performance impact. The platform correlates network exposure, effective IAM permissions, and data sensitivity to surface toxic combinations where multiple risks intersect.
Wiz automatically identifies exploitable routes from entry points to critical assets. For example, Wiz shows when an internet-exposed container with a critical CVE also has an IAM role granting access to production databases containing customer PII—a toxic combination requiring immediate remediation.
Wiz calculates effective exposure by analyzing security groups, network ACLs, VPC configurations, and cloud-native firewall rules across AWS, Azure, and GCP. CIEM capabilities map how identities and permissions create access paths, evaluating IAM policies, role chains, and permission boundaries—even through complex multi-hop permission chains.
Wiz ASM validates external reachability with outside-in scanning, confirming which internal attack paths are exploitable from the internet. This external validation layer discovers shadow IT, forgotten assets, and exposed services that internal-only tools miss—then correlates these external findings with your internal security graph to show complete attack chains from the internet to your crown jewels.
Code-to-cloud correlation traces issues back to specific Infrastructure-as-Code files, Git repositories, and developer owners—showing you the exact Terraform file and line number that created the exposure. This enables you to fix vulnerabilities at the source and prevent similar issues in future deployments.
This unified approach across code, pipeline, cloud runtime, and external attack surface eliminates tool sprawl and blind spots. Instead of correlating findings from separate tools, you see complete attack paths in a single security graph—enabling security teams to communicate risk in business termsrather than technical jargon.
Ready tofocus on what's truly exploitable? See reachability analysis, attack paths, and code-to-cloud ownership in action—book a live demo to explore how Wiz identifies and prioritizes the risks that actually matter in yourenvironment.
Secure your cloud from code to production
Learn why CISOs at the fastest growing companies trust Wiz to accelerate secure cloud development.
