Your CSPM tells you tens of thousands of findings are open. Some are critical, many are medium, and a few are informational. The dashboard is red. The backlog grows. And the team fixes findings roughly in the order they arrived, because nothing in that list explains which ones actually matter.
Attack path analysis answers a different question: which of those findings line up into a real path from the internet to a database with customer data?
That distinction between a list of isolated issues and a connected chain of reachable risk is what separates cloud security tools that generate work from those that help you prioritise it.
This article explains what cloud attack path analysis is, how it works technically, where it fits alongside other security concepts, and what to look for when evaluating it.
A finding is not an attack path
A finding is a single observation: “this S3 bucket is public,” or “this EC2 instance has an outdated Apache,” or “this IAM role has admin permissions.” Each one is a fragment. In isolation, each may look like a medium-severity issue that lands in the backlog.
An attack path strings fragments together into a story. It answers: starting from the internet, can an attacker actually reach something valuable by chaining these fragments?
“Public-facing EC2 with a known CVE → attached IAM role with overly broad permissions → that role can read an S3 bucket tagged with PII”; that is not three medium findings. That is one critical path.
The unit of security worth fixing is not the individual finding. It is the chain. And the only way to see chains is to model the environment as a connected graph, not a flat list.
Why finding-lists fail in cloud security
List-based security tools (traditional CSPMs, vulnerability scanners, compliance dashboards) share three failure patterns that attack path analysis is built to solve.
The backlog that never closes
Detection is solved. Every tool finds issues. The problem is triage. When everything is flagged at once with a CVSS score and no environmental context, most findings never get acted on. Mean time to remediate drifts from days into seasons. The team is busy, but not effective.
The crown jewels nobody flags
Only a small fraction of cloud security alerts actually touch a sensitive asset. A misconfigured security group on a test instance and a misconfigured security group on a production database instance may have the same CVSS score, but they are not the same risk. Without reachability context, the list cannot tell you which one matters this week.
The Criticals that stay open for months
When teams cannot see which Critical finding is part of an active attack chain “where the misconfiguration is reachable from the internet and connected to sensitive data” they fix findings in arrival order. Real adversaries do not attack in arrival order. They look for the path of least resistance to the highest-value target.
Attack path analysis inverts the prioritisation model: instead of “fix by severity,” it becomes “fix by reachability and impact.”
What makes up a cloud attack path
A cloud attack path is built from two primitives: nodes (the things in your environment) and edges (the relationships between them).
Node types
- Assets: EC2 instances, RDS databases, S3 buckets, Lambda functions, Kubernetes pods, load balancers, VPCs, subnets, security groups, and every other deployed resource.
- Identities: IAM users, roles, service accounts, machine credentials, non-human identities, Kubernetes service accounts.
- Vulnerabilities: CVEs on workloads, outdated packages, unpatched libraries, container image vulnerabilities.
- Threats: Active indicators of compromise, suspicious CloudTrail events, anomalous access patterns.
Edge types
Edges represent how nodes connect. The quality of attack path analysis depends entirely on which edge types the system models:
- Network edges: PART_OF_SUBNET, MEMBER_OF_VPC, ATTACHED_TO_SECURITY_GROUP, ROUTES_THROUGH_INTERNET_GATEWAY. These describe physical and logical network reachability.
- Identity edges: STS_ASSUMEROLE_ALLOW, HAS_PERMISSION, MEMBER_OF_GROUP, CAN_ACCESS. These describe what an identity is allowed to do.
- Dependency edges: RUNS_ON, MOUNTS_VOLUME, READS_FROM, CONNECTS_TO. These describe runtime relationships between services.
A concrete example
Consider this path:
Internet
→ Public Load Balancer (port 443 open to 0.0.0.0/0)
→ EC2 Instance (CVE-2024-XXXX, Apache RCE)
→ IAM Role attached to instance (sts:AssumeRole, s3:GetObject on *)
→ S3 Bucket (tagged: contains-pii, no encryption at rest)Each node in this chain has its own finding. The load balancer’s public exposure is a finding. The unpatched CVE is a finding. The overly broad IAM role is a finding. The unencrypted bucket is a finding.
But the attack path is the chain: internet-reachable entry point → exploitable vulnerability → privilege escalation → crown-jewel data exposure. That chain is what an attacker would actually walk, and it is what your team should fix first.
How cloud attack path analysis works
Under the hood, attack path analysis requires three things: a graph data model, a traversal algorithm, and a way to surface results without burying them in a separate sub-app.
The typed asset graph
Every cloud resource becomes a node. Every relationship between resources becomes a typed edge. “This EC2 is in this subnet, this subnet has this route table, this route table has an internet gateway” each of those is a distinct edge with a specific type.
This is not a generic parent-child hierarchy. It is a typed relationship graph where edge types carry semantic meaning. The difference matters: a generic graph might show that an EC2 “belongs to” a VPC, but a typed graph shows the specific network path (subnet → route table → internet gateway) that makes the EC2 reachable from the internet.
The approach is inspired by open-source graph models like Cartography, but tuned for the scale and query speed a production CNAPP requires; sub-second responses on million-node graphs.
Hop-by-hop traversal
Starting from a public-facing asset, the analysis engine walks the graph one hop at a time, following only network-meaningful relationships. Not every edge matters for reachability. Parent-child relationships, tagging relationships, and organisational hierarchy do not represent attack paths. Only edges that describe how traffic, permissions, or access actually flow are traversed.
Key properties of a well-designed traversal:
- Configurable depth: Most implementations default to 4 hops, which covers the majority of real-world attack chains. Deeper traversals catch edge cases but increase computation.
- Cycle-safe by construction: The traversal tracks visited nodes at every hop. No infinite loops, no duplicate paths. A configurable depth cap stops runaway queries.
- Performance isolation: Traversal runs against read replicas or partitioned stores, never blocking the inventory pipeline or slowing down the CSPM scan.
- Per-resource-type traversal rules: Not all resource types are traversed the same way. An IAM role is walked differently than a subnet. The rules are tunable.
Posture on every hop
A good attack path implementation does not just show the chain, it shows the security posture at every node along the chain. Each node carries its failure counts, severity levels, and specific finding IDs. You see risk accumulating along the path, not just at the endpoint.
This matters for remediation: if you cannot patch the CVE on the EC2 today, maybe you can tighten the IAM role or restrict the security group. Any break in the chain eliminates the path.
Attack path analysis vs. adjacent concepts
Attack path analysis overlaps with but is distinct from several other security practices. Understanding the boundaries helps teams use the right tool for the right question.
| Concept | What it asks | When it runs | Unit of output |
|---|---|---|---|
| Vulnerability management | Which CVEs do we have? | Periodically (scan-based) | Individual CVE findings |
| Threat modeling | What could go wrong architecturally? | Design-time / review cycles | Threat scenarios and mitigations |
| CSPM | What is misconfigured? | Continuously | Misconfiguration findings |
| Blast radius analysis | If this identity is compromised, what can it reach? | On-demand or continuous | Outbound reachability from an identity |
| Attack path analysis | Which weaknesses chain into a real path to impact? | Continuously | Connected paths from entry to target |
A few distinctions worth noting:
- vs. Vulnerability management: CVSS and EPSS tell you about exploit likelihood and technical severity. Attack path analysis tells you whether the affected resource is reachable, privileged, and connected to sensitive data. Both views matter; neither is sufficient alone.
- vs. Threat modeling: Threat modeling is a design-time exercise, you reason about what could go wrong before deploying. Attack path analysis is continuous and environment-driven, it looks at what is deployed now and updates as resources, identities, and networks change.
- vs. CSPM: CSPM tells you what is misconfigured. Attack path analysis tells you which misconfigurations are reachable and chainable into real risk. CSPM is the detection engine; attack path analysis is the prioritisation layer.
- vs. Blast radius: Blast radius analysis starts from a compromised identity and walks outward “if this role is compromised, what can it reach?” Attack path analysis starts from the internet and walks inward “from the outside, what paths lead to this crown jewel?” They are complementary directions on the same graph.
Questions attack path analysis can answer
Once your environment is modelled as a graph with attack path traversal, you can ask questions that were previously unanswerable with list-based tools.
Which databases are actually reachable from the internet?
Not “which RDS instances have a public flag set” that is a configuration check. The graph confirms whether a complete network path exists: public IP → subnet → route table → internet gateway → security group rule → database endpoint. Configuration flags lie; the graph does not.
What is the blast radius of this IAM role?
Starting from a specific identity, walk every STS-assumable role and permission grant. See what is in reach if the identity is compromised: 47 assets, 12 with PII tags, 3 with production database access. That is the blast radius, and it tells you whether to prioritise tightening that role.
Did anything become newly internet-accessible this week?
A funnel that triggers when the “exposed AND misconfigured” subset grows catches misconfiguration drift before an attacker does. A single route table change or security group modification can create a new path that did not exist yesterday.
Which subdomain takeovers are ranked by what they reach?
DNS-based exposure (dangling CNAMEs, unclaimed subdomains) is a first-class attack path source. Most graph-based tools only think about network paths. But a takeable subdomain that routes to an internal service with database access is a path worth knowing about, ranked by what the attacker can reach from there.
How many resources are in PCI scope, in production, internet-reachable, and part of an active attack chain?
This is where composability matters. Attack path status should be a filter you combine with severity, compliance scope, environment tag, time window; not a separate UI you visit to see “attack path findings” in isolation.
What to look for in an attack path implementation
Not all graph-based security tools are built the same way. When evaluating attack path analysis capabilities in a CNAPP, six criteria separate real implementations from marketing features:
Is the graph the foundation or a bolt-on?
Most CNAPPs bolt on a separate graph tool; it is a marketing feature, not the architecture. If the graph is not the same data store that powers inventory, identity, and compliance, you are looking at a demo feature, not a production system.
Does it traverse network-meaningful edges only?
Some implementations traverse generic parent-child edges (“this EC2 belongs to this account”). Those paths are technically valid graph queries but they are not attack paths. Real attack path traversal follows only edges that represent how traffic, permissions, or access actually flow: PART_OF_SUBNET, MEMBER_OF_VPC, ATTACHED_TO_SECURITY_GROUP, STS_ASSUMEROLE_ALLOW.
Is it a filter primitive or a separate sub-app?
If attack path analysis lives in a separate “Attack Paths” menu item and you cannot combine it with your existing severity, compliance, tag, and time-window filters, it is a silo. The most useful implementation exposes attack path status as a column, composable with everything else you already filter by.
Does it carry posture on every hop?
The path should show not just the chain of nodes, but the security state at each node: what findings exist, what severity, which specific issues. This is what makes the path actionable — you can break the chain at the weakest link.
Does it normalise across clouds?
AWS, Azure, and GCP have different resource models, different IAM systems, and different network primitives. A useful implementation normalises these into the same edge taxonomy so that “public-facing finding in Azure” walks the same traversal logic as one in AWS. Without normalisation, multi-cloud environments require separate mental models for each provider.
Can it handle scale?
Million-node graphs are common in enterprises with dozens of accounts. If the traversal engine cannot run in sub-second time at that scale, it is not production-ready. Look for evidence of partitioned storage, read-replica isolation, and configurable traversal depth.
How Cloudanix approaches attack path analysis
Cloudanix models your cloud as a typed asset graph with 300+ resource types and typed relationships across AWS, Azure, and GCP. Attack path analysis is a traversal query against that same graph — not a separate system.
The traversal walks from internet-facing assets through network-meaningful edges, confirming reachability at each hop, with a configurable depth (4 hops by default). Each node in the returned path carries its full security posture.
has_attack_path is exposed as a filter primitive — a column you can use in any list view, dashboard, alert rule, or report, composed with severity, compliance framework, environment tag, or time window. It is not a separate feature buried in a sub-menu.
The same graph powers CSPM, CIEM, contextual severity, asset inventory, and blast-radius analysis. One data plane, one schema, one traversal engine.
For a deeper look at the product implementation, see the Attack Path product page.
Related reading
- What Is a Cloud Security Graph? — the graph model underneath attack path analysis
- CNAPP vs CSPM: What’s the Difference? — where attack paths fit in the broader platform picture
- How to Prioritize Vulnerabilities Based on Business Risk — the prioritisation methodology attack paths enable
- How to Audit IAM Permissions Across Multi-Cloud — the identity side of the graph
- What Is Threat Modeling? — the design-time complement to continuous attack path analysis
Frequently asked questions
What is an attack path in cloud security?
An attack path is a sequence of connected steps — crossing network exposure, vulnerabilities, identity permissions, and data access — that an attacker could chain together to move from an entry point (typically the internet) to a high-value target (typically sensitive data or a production system).
How is attack path analysis different from vulnerability scanning?
Vulnerability scanning identifies individual CVEs on individual assets. Attack path analysis takes those findings and determines which ones are reachable from the internet, connected to privileged identities, and able to reach sensitive data. A CVE on an isolated internal test instance is not the same risk as the same CVE on an internet-facing instance with a role that can read your production database.
Does attack path analysis require agents on every host?
No. Most of the information needed — cloud configuration, IAM relationships, network topology, resource metadata — comes from cloud provider APIs. Vulnerability data for workloads may come from agentless snapshot scanning or lightweight agents, but the graph and traversal logic itself is API-driven.
How often should attack paths be recalculated?
Continuously. Cloud environments change frequently. A single IAM policy change, a new route table entry, a security group modification, or a new deployment can create or eliminate a path. Batch recalculation (daily or weekly) misses the configuration drift that creates exposure windows.
What is a “crown jewel” in the context of attack paths?
A crown jewel is any asset whose compromise would have significant business impact: databases with customer PII, secrets managers, production Kubernetes control planes, storage containing financial records, or infrastructure that supports revenue-critical services. Attack path analysis prioritises paths that terminate at crown jewels over paths that terminate at low-value targets.
Can attack path analysis work across multiple cloud providers?
Yes, provided the graph normalises resource types and relationships across providers. AWS VPCs, Azure VNets, and GCP VPC networks serve similar functions but have different APIs and naming. A cross-cloud attack path implementation maps these into a unified edge taxonomy so that traversal logic works consistently regardless of provider.
