Cloud security posture is relational. A public IP range is not dangerous by itself, a permissive security group is not always exploitable, and a database encryption flag does not explain who can reach the database. The real risk appears when identities, groups, IAM roles, compute instances, VPC peerings, network rules, and data stores connect into a path an attacker can traverse.
Graph-based attack path analysis models those resources as nodes and relationships, then uses graph queries to find multi-hop exposure. The source article demonstrates this with Cypher patterns that connect internet ingress to sensitive data and identities to production databases through group membership, role grants, assumed compute, and VPC peering. The transferable technique is not the specific cloud provider; it is the security graph model and the query patterns that expose toxic combinations.
This approach is useful because many high-impact cloud findings are invisible to single-resource checks. A scanner can report “SSH is open” or “database is unencrypted,” but a graph query can answer “which external path reaches this unencrypted database?” and “which developer identity can indirectly access production through a peered network?”
A security graph represents cloud assets as entities and relationships. Nodes might include identities, groups, roles, compute instances, security groups, VPCs, IP ranges, and data stores. Edges encode the ways risk moves: MEMBER_OF, GRANTS, ASSUMES, IN_VPC, PEERED_WITH, ATTACHED_TO, and INGRESS_TO.
An attack path is a sequence of relationships from an entry point to a target. The entry point might be the public internet, a compromised user account, or an exposed workload. The target might be a production database, privileged role, secret store, or management plane. Path length matters less than exploitability: a five-hop path with common privileges may be more dangerous than a one-hop path blocked by policy.
A toxic combination is a set of individually acceptable permissions or configurations that become dangerous together. Developer group membership, VPC peering, role assumption, and an unencrypted database might each pass a local policy check, yet together they create indirect production data access.
Cloud posture analysis often fails when each resource is evaluated in isolation. Graph queries turn risk detection into relationship-aware joins over identity, network, compute, and data layers.
The pipeline begins by normalizing cloud inventory into typed nodes and edges. Each resource should have a stable identifier, provider metadata, account or project scope, and timestamps. Relationships should be directional and explicit so queries can distinguish “role grants access to compute” from “compute is in VPC.”
CREATE (internet:IPRange {cidr: "0.0.0.0/0", description: "public internet"}),
(sg_ssh:SecurityGroup {name: "ssh-open"}),
(vm:Compute {id: "i-public-01", platform: "AWS EC2"}),
(db:DataStore {name: "prod-db", type: "MySQL", encrypted: false}),
(internet)-[:INGRESS_TO {protocol: "TCP", port: 22}]->(sg_ssh),
(sg_ssh)-[:ATTACHED_TO]->(vm),
(vm)-[:CAN_REACH]->(db);Once the graph exists, attack-path queries become pattern matches. The query can constrain edge types, node labels, properties, path length, or target sensitivity. A basic public exposure query follows internet ingress through a security group to a compute node and then to sensitive data.
MATCH path =
(:IPRange {cidr: "0.0.0.0/0"})
-[:INGRESS_TO]->(:SecurityGroup)
-[:ATTACHED_TO]->(c:Compute)
-[:CAN_REACH*1..3]->(db:DataStore {encrypted: false})
RETURN c.id, db.name, length(path) AS hops;Identity paths expose privilege drift. A user may not have a direct production grant, but group membership can grant a role, that role can assume a compute identity, and the compute instance can reach a peered production network. Graph queries make the full chain visible.
MATCH (i:Identity)
-[:MEMBER_OF]->(:Group)
-[:GRANTS]->(r:IAMRole)
-[:ASSUMES]->(c:Compute)
-[:IN_VPC]->(dev:VPC)
-[:PEERED_WITH]->(prod:VPC)
<-[:IN_VPC]-(db:DataStore {encrypted: false, type: "MySQL"})
RETURN i.name, r.name, c.id, dev.name, prod.name, db.name;CSPM systems can use graph queries to prioritize findings by exploitability. Instead of sending separate alerts for an open port, a peered network, and an unencrypted database, the system can report a single path showing how those facts combine into reachable sensitive data.
Security teams can query which identities can indirectly reach production assets, which roles bridge accounts, and which groups create unexpected privilege chains. This is more actionable than reviewing IAM policies in isolation because the query includes network and resource context.
Graphs support simulated remediation. Remove an edge, tighten a security group, delete a VPC peering, or mark a role as non-assumable, then rerun the attack-path queries. This helps teams choose the smallest control change that breaks the highest-risk paths.
Collectors should focus on accurate resource and relationship extraction. Detection rules should live separately as versioned graph queries. This separation lets teams improve cloud inventory coverage without rewriting every risk detector, and lets security analysts add new path rules without changing collectors.
type Node struct {
ID string
Label string
Account string
Props map[string]string
}
type Edge struct {
FromID string
ToID string
Type string
Props map[string]string
}
type Rule struct {
Name string
Severity string
Cypher string
}Attack queries become brittle if every collector invents relationship names. Define a canonical vocabulary for identity, network, compute, and data edges. Provider-specific details can remain as properties, while high-level query logic stays portable.
A path result should include enough evidence for remediation: resource IDs, accounts, regions, policies, rule IDs, timestamps, and the exact edge sequence. Without evidence, the finding is hard to reproduce and easy to dismiss as a scanner false positive.