MAPPING THE BREACH · PART I
The shift to Cloud Attack Path Analysis
Introduction
As cloud estates spread across AWS, Azure, and GCP, security teams typically end up with three orthogonal views: CSPM misconfiguration lists, vulnerability scan reports, and IAM reviews of risky identities. Each view is useful, but none answers the architectural question that matters most: how can an attacker move from an external foothold to a crown‑jewel asset across all these clouds and identities?
Cloud attack path analysis addresses this by introducing a unifying layer — a multi‑cloud security graph that models assets, identities, data, and controls as nodes and relationships as edges — and then walks that graph to surface real routes an adversary could take. Architecturally, this shifts you from isolated tools and dashboards to a graph‑centric platform where multi‑cloud relationships and identity‑to‑asset mappings are first‑class design elements, not hidden implementation details.
1. Why flat lists stopped working
The scale problem is now undeniable. More than a hundred new CVEs are published every day, and by mid-2025 the public CVE corpus had passed a quarter of a million entries, with a large fraction never fully enriched with the metadata needed for automated asset matching. No team can patch everything, and “patch everything rated Critical” has quietly become a strategy that guarantees you work hard on the wrong things.
The deeper issue is that the industry’s default scoring signal measures the wrong thing. CVSS describes the theoretical severity of a vulnerability in isolation; it says nothing about whether the flaw is being exploited, whether the vulnerable component is reachable in your environment, or whether a compromise would actually reach anything valuable. Exploit-likelihood models such as EPSS, and catalogues of confirmed exploitation such as CISA KEV, add real-world signal, but they too evaluate each CVE on its own. A vulnerability with a modest severity score and a high exploitation probability on an internet-facing host routinely outranks a “critical” flaw buried on an isolated system.
A finding’s danger is not a property of the finding. It is a property of the finding’s position in the graph of your environment.
That single observation is the architectural pivot. Once you accept it, prioritization stops being a sorting problem over a list and becomes a traversal problem over a graph — and the platform you build to answer it looks very different from a scanner with a dashboard bolted on.
2. Cloud attack paths as graphs
In graph terms, an attack path is a sequence of nodes (entities) connected by edges (relationships) that links an entry point to a critical asset. Nodes represent workloads (VMs, containers, functions), identities (users, roles, service principals, machine identities), data stores, and control-plane components. Edges encode semantics: “reachable over network,” “can assume role,” “has permission to write,” “is owner of,” “federates to.”
Graph-based analysis runs traversals over this model to reveal chains where individually unremarkable weaknesses — public exposure, an unpatched CVE, a leaked credential, an over-broad role — combine into meaningful business impact. Instead of “here are 12,000 findings,” the graph shows what is connected to what, and why that connection matters. This is the core promise behind the security graphs and exposure graphs that now sit at the centre of modern CNAPP and exposure-management platforms, and analysts increasingly treat graph-driven path analysis as a defining capability rather than a nice-to-have.
3. The multi-cloud security graph architecture
A robust attack-path capability rests on one thing: a unified, continuously updated graph representing every asset, identity, configuration, relationship, and risk across providers. Mature platforms converge on a single data model and graph store precisely because correlating across code, configuration, identity, and runtime is impossible when each signal lives in its own silo. It is useful to describe the design in four layers.
Layer 1 — Ingestion and normalization
Connectors ingest resource inventories, IAM configurations, network policies, vulnerabilities, secrets, and runtime signals from AWS, Azure, GCP, Kubernetes, and key SaaS platforms. ETL pipelines normalize these heterogeneous inputs into provider-agnostic types — ComputeInstance, ContainerWorkload, IdentityPrincipal, StorageObject, NetworkEndpoint — stored as nodes with properties. Normalization is what lets a single traversal cross clouds without special-casing each provider’s syntax.
Layer 2 — Environment micrographs
Each account, subscription, or project is represented as a micrograph: a local subgraph of the assets, identities, and relationships within that environment. An Azure micrograph contains Entra ID entities, resource groups, managed identities, Key Vaults, and their role assignments; an AWS micrograph holds IAM roles, EC2 instances, security groups, S3 buckets, and KMS keys. Keeping environments as discrete subgraphs makes the model scalable and makes ownership and blast-radius boundaries explicit.
Layer 3 — Global graph assembly
Micrographs are stitched into a single global graph via cross-cloud and cross-identity edges: SSO, federation, OIDC trust, SCIM provisioning, and API integrations. This is the step most tools get wrong. Modelling “Okta user → Azure group → Entra ID role → AWS IAM role via federation” as explicit, queryable edges turns cross-cloud movement — the exact thing that makes hybrid breaches so hard to scope — from an undocumented integration into a path you can actually search for.
Layer 4 — Graph store and query engine
The global graph lives in a graph database that supports expressive path queries and graph analytics. A Cypher- or Gremlin-style syntax lets you ask questions that were previously multi-day manual investigations: “find every path from an internet-facing asset to PII-tagged storage,” or “enumerate identities whose blast radius includes production databases.” Microsoft’s Security Exposure Management is a concrete public example of this pattern: it exposes the environment as ExposureGraphNodes (devices, identities, groups, and cloud assets like VMs, storage, and containers) and ExposureGraphEdges (relationships such as “affecting,” “routes traffic to,” “is running,” “contains”), then hunts over that graph for attack paths.
4. Identity-to-asset mapping as a first-class design
Blast radius — the set of assets, identities, and data reachable from a single compromised entity — is fundamentally an identity problem. Attack path analysis tells you the route; blast radius tells you the scope of everything reachable from a starting point. In the cloud, most powerful actions are governed by identity rather than a network perimeter, and research consistently shows the majority of accounts hold more privilege than they use. That means a single over-privileged identity can hand an attacker enormous reach before any lateral movement occurs at all. Architecturally, identity-to-asset mapping therefore has to be explicit in the schema, not buried inside IAM JSON.
A schema built from three constructs
• Identity nodes — users, groups, roles, service principals, managed identities, API keys, and machine identities. Attributes capture origin (IdP vs. cloud IAM), tenant, risk flags (MFA disabled, stale credentials), and ownership.
• Permission and trust edges — HAS_PERMISSION_TO, CAN_ASSUME_ROLE, MEMBER_OF, OWNER_OF, CAN_DEPLOY_TO, each with directionality and properties (scope, conditions, resource patterns). UserA –HAS_PERMISSION_TO→ StorageAccountX captures read/write access; SPy –CAN_ASSUME_ROLE→ IAMRoleZ models a cross-identity pivot.
• Asset nodes with context — databases, buckets, clusters, and queues carry labels such as Environment=prod|dev, DataSensitivity=PII|PCI|Public, and ApplicationTier=tier0|tier1|tier2. These properties feed directly into path scoring and blast-radius calculation.
Get Abhinav Paliwal (TheKillChainGuy)’s stories in your inbox
Join Medium for free to get updates from this writer.
With this schema, the engine calculates an identity’s blast radius by traversing outward from an identity node across permission edges into asset nodes. Identity-centric questions — “show all identities that can reach any tier-zero asset,” “which service accounts carry a toxic combination of exposure and privilege” — become one-line queries rather than manual IAM audits. The same view powers what-if analysis: assessing the impact of a role change, or scoping a post-compromise investigation, by asking what a given identity could touch.
A misconfiguration that wouldn’t matter if an IAM role were right-sized, plus a federation trust nobody has audited in eighteen months, plus accessible data — that toxic combination is invisible in any single tool and obvious in the graph.
5. Building attack paths on top of the graph
Once the graph and its identity mappings exist, attack-path analysis becomes a set of graph computations rather than bespoke product logic. Four operations do most of the work.
1. Entry-point identification. Tag plausible footholds: internet-facing workloads, exposed APIs, externally reachable SaaS endpoints, and identities at high risk of phishing or credential stuffing. A path without a realistic starting point is just theoretical graph traversal — the foothold is what anchors it to an actual threat scenario.
2. Critical-asset definition. Tag the crown jewels: PII and PCI data stores, payment systems, tier-zero infrastructure, high-value SaaS. This lets the engine focus on paths with real business impact instead of arbitrary reachability.
3. Path traversal and scoring. For each entry point, traverse toward critical assets along edges of reachability (network), permission (IAM), and trust (federation), scoring every path that lands.
4. Choke-point and fix-path detection. Identify the nodes and edges that sit on many high-risk paths, and for each path compute the minimal set of changes — revoke a permission, rotate a secret, tighten a security group — that breaks it.
Public platforms make this concrete. Microsoft’s exposure graph generates attack paths by simulating attacker scenarios across collected data, and its dashboard reports not just the number of paths and critical assets but the number of choke points through which many paths flow. The pipeline below generalises the pattern.
6. Scoring that reflects reality
The weakness of every isolated metric — CVSS, EPSS, KEV — is that none of them knows anything about your environment. A scoring model built for graph-based prioritisation should separate the properties of a thing from the properties of its situation, and combine them deliberately.
7. Choke points and the graph theory behind them
A choke point is a node or edge — an account, a group, a permission, a central secrets store, a federation link — through which a large number of distinct attack paths must pass to reach high-value targets. In graph terms, these are the nodes with high betweenness centrality: the fraction of shortest source-to-target paths that run through a given node. Fixing one such node can break dozens of downstream paths at once, which is why mature programs prioritise these high-traffic junctions first.
Betweenness is not the only useful measure. Closeness centrality highlights nodes from which an attacker (or a response action) can propagate quickly; degree centrality flags common access points; PageRank-style measures surface identities that other privileged identities trust. Each answers a different question, and endpoint volume can be actively misleading — the noisiest assets are often strategically worthless, while a quiet, structurally central node appears on half the paths and rarely triggers an alert. Recent research on topology-aware vulnerability prioritisation makes the same point quantitatively: ranking fixes by structural position in the attack graph, rather than by CVSS or EPSS alone, cuts more attack paths per fix and raises the attacker’s minimum cost faster.
8. Two architectural pivots: identity and IaC
Workload → identity
From an attacker’s perspective, compromising a workload is usually just a means to reach a more powerful identity. Architecturally, pivoting from workload to identity is simply switching traversal direction — “from this compromised node, which identities and their assets are reachable?” Workload nodes reference identities through instance profiles, service-account bindings, managed identities, and embedded credentials; identity nodes reference the workloads they control through deployment permissions and ownership edges. Modelling both directions turns “compromised pod → service account → everything that account can touch” into a first-class graph path, and encourages teams to treat identity as the primary attack surface rather than an afterthought.
Into the infrastructure-as-code plane
IaC defines desired state; if a template encodes an insecure pattern, every deployment mints new attack paths at scale. Bringing Terraform, ARM/Bicep, CloudFormation, Helm charts, and Kubernetes manifests into the graph as nodes linked to the runtime assets they manage lets policy-as-code checks (OPA, Checkov, static analysis) inspect them for patterns that would create dangerous paths — public subnets tied to sensitive data, over-privileged deployment roles, unencrypted storage. Findings become attributes on nodes and edges, feeding the same scoring. Best of all, the engine can simulate how a proposed change would alter the attack surface before a pull request merges, rejecting the ones that would introduce an exploitable chain. This is design-time threat modelling at scale, and it aligns with the shift-left, CI/CD-integrated direction of current CNAPP guidance.
9. A worked multi-cloud attack path
The concepts come together in a single chain that crosses all three planes. A public GKE service in GCP exposes a container running an image with a critical RCE, reachable through an internet-facing load balancer. That container holds AWS access keys in plaintext because of misconfigured secret management; the keys grant an IAM role with sts: AssumeRole into other roles. One of those roles can assume a federated identity in Azure via an OIDC trust originally set up for analytics. That Azure identity owns a storage account tagged DataSensitivity=PII and holds Contributor rights on a resource group hosting tier-zero services. Finally, a CI/CD pipeline identity tied to the Terraform state for that resource group can modify ingress rules, deploy new workloads, and rotate secrets in the cluster.
In the global graph, the chain reads: GCP Container → LoadBalancer → AWS IAM Role → Azure Federated Identity → Azure Storage (PII) → Terraform Pipeline Identity → Production AKS Cluster. The engine scores it high on every axis: trivial exploitability (RCE plus plaintext credentials), a low hop count, and severe impact (PII exfiltration plus persistent control over a tier-zero cluster). The fix path is equally legible — remove the plaintext keys, constrain the cross-cloud federation, tighten the Azure storage permissions, and lock down the Terraform and CI/CD identities — and each candidate fix can be ranked by how much of the path it removes.
10. Design principles for an attack-path platform
• Graph-first. Treat the security graph as the core architecture. Scanners, connectors, and dashboards are producers and consumers of graph data, not independent silos.
• Provider-agnostic abstractions. Normalise identities and assets into common types and wrap cloud-specific differences in adapters, so adding a new service never forces a schema rewrite.
• Identity-centric reasoning. Make identity-to-asset mapping central to blast-radius and path scoring. Prioritisation should be rooted in what a compromised identity can reach, not how many CVEs exist.
• Continuous recomputation. Ingest and recompute continuously so paths evolve with a dynamic estate rather than freezing into point-in-time snapshots.
• Deep IaC and CI/CD integration. Wire graph insight into PR checks and policy-as-code so future paths are caught at design time, not only fixed in production.
With this architecture, attack-path management stops being a dashboard feature. It becomes the organising principle of a cloud security program: one multi-cloud graph, one identity-to-asset model, and one path-aware way of deciding what to fix next — and why.
Not “what’s wrong here” — but “what’s the shortest walk from the internet to your crown jewels, and which single edge closes it?” That’s the shift: from finding to path.
