Thousands of findings. A handful that can actually reach your data.
A CSPM dashboard full of misconfigurations is a to-do list, not a risk picture. The findings that matter are the ones that chain together into a path from something an attacker can touch to something you cannot afford to lose. This guide shows you how to find those paths and fix them first.
A list of misconfigurations is not a risk picture.
Open a mature cloud estate in any posture tool and you will see thousands of findings, each with a severity score, each demanding attention. Here is the trap. That score rates the finding in isolation. It knows the bucket is public. It does not know whether anything an attacker controls can actually get to that bucket, or what sits behind it.
Severity answers “how bad is this thing on its own.” An attacker never asks that. They ask “can I get from where I am to something worth stealing, and what is the shortest way.” Those are different questions, and only the second one is about real risk. A critical finding stranded behind three controls is theatre. A medium one sitting on a live path to your customer database is a breach waiting to be claimed. Reachability beats severity, every time.
Cloud risk is a graph, and identity is the perimeter.
Stop picturing your cloud as a list of resources and start picturing it as a graph of who can reach what. The nodes are assets and identities. The edges are permissions and trust. In that picture, the perimeter is no longer the network. It is identity. The firewall barely matters when a leaked key can assume a role that opens the door from the inside.
A real attack path looks like a chain: a public asset, which can assume a role, which can assume another role, which can read a sensitive data store. Each link is mundane on its own. Strung together they are an intrusion. The thing that wires them is almost always one over-permissioned identity, quietly connecting two parts of your estate that were never meant to touch.
The shift in question. Stop asking “is this resource configured correctly.” Start asking “what can this identity become, and what can it reach once it does.” That second question is the whole game.
The toxic combinations.
Individual findings rarely sink you. Combinations do. These are the patterns that turn a quiet dashboard into a live path, and they are what an attacker hunts for first. Learn to spot them and you can ignore most of the noise.
- Public exposure meets power An internet-reachable asset that can assume an identity with rights it never needed. The exposure on its own is a paper cut. Wired to a role that can read a data store, it becomes a way in.
- Privilege-escalation chains Role A can assume role B, which can assume role C, which can touch production. No single hop looks alarming. End to end, a foothold on the first becomes ownership of the last.
- Trust across boundaries A role in one account trusts a principal in another, or a workload in one cloud holds credentials for a second. Attackers love a trust edge that crosses a boundary your team mentally treats as a wall.
- Secrets that open everything else An access key in a public repo, a token baked into a container image, a credential printed in a CI log. One leaked secret can skip every control you built and land an attacker straight inside.
Turn the noise into paths. Seven steps.
This is the work, in order. It is runnable by hand on a small estate and worth automating on a large one. The goal at every step is the same: get from a flat list of findings to a ranked set of real paths from exposure to data.
- 01
Inventory what is actually reachable
Start at the edge. Enumerate every asset an outsider can hit: public IPs, load balancers, exposed storage buckets, API gateways, management consoles left open. Not what the architecture diagram claims is private. What responds when you knock from the internet. This is your real front door, and it is usually wider than anyone believes.
- 02
Map identities, roles, and trust
Pull the identity graph. Every role, every policy, every assume-role and federation edge, every cross-account trust. Resolve wildcards into the permissions they actually grant. The question you are answering: from any given principal, what can it become, and what can it reach once it gets there?
- 03
Locate the sensitive data stores
Find the things worth stealing. Databases, object stores holding customer records, secrets managers, backups, snapshots, model weights. Tag them as the targets. Everything else in the graph only matters in relation to these.
- 04
Trace the paths that connect exposure to data
Now walk the graph from edge to target. Which reachable asset, through which chain of role assumptions and trust edges, ends at a sensitive store? Each complete walk is an attack path. A finding that sits on a path is real. A finding that sits on nothing is hygiene.
- 05
Rank by reachability and blast radius
Drop raw CVSS as your sort order. Rank by two things: can an attacker actually get here from the outside, and how much do they own once they do. A medium-severity misconfiguration on a live path beats a critical one stranded behind three controls. Sort the work the way an attacker sorts targets.
- 06
Fix the chokepoints
Look for the edges that appear in many paths at once. One over-broad role, one stale trust relationship, one wildcard policy can carry dozens of paths through it. Cut that single edge and every path through it dies. You fix far less and reduce far more risk than working a flat list top to bottom.
- 07
Re-check continuously
Cloud changes every day. A new role, a new bucket, a new pipeline, and yesterday’s clean graph grows a fresh path overnight. A one-time map is a photograph of a moving thing. Re-run the analysis on every meaningful change so the path picture stays current.
What CSPM is genuinely good at.
None of this means throw the tool away. CSPM does real work, and path analysis sits on top of it rather than replacing it. Keep it for these.
- Configuration hygiene CSPM is genuinely good at catching drift from a known-good baseline: a bucket flipped public, encryption switched off, logging disabled, an open security group. Keep it for exactly that.
- Compliance evidence It maps your estate against CIS, frameworks, and regulatory baselines, and produces the evidence auditors want. That has real value, and path analysis does not replace it.
- Breadth of coverage It watches everything, all the time, cheaply. No human can eyeball every resource in a large multi-account estate. The dashboard sees the whole field.
What it misses, and why it hurts.
The gap is not a bug in any one product. It is structural. Posture tools were built to check configuration, and the things that actually get you breached live one level up, in how findings connect. Here is what falls through.
- Reachability A severity score rates a finding in isolation. It has no idea whether anything actually reaches it from the internet, so it cannot tell a live exposure from a buried one.
- Chaining It scores findings one at a time. It will not connect a harmless public asset to an over-permissioned role to a database three hops away, which is exactly how a real intrusion runs.
- Identity as the perimeter Most CSPM grew up checking resource config, not reasoning over the identity graph. The assume-role chain that is the actual attack path often does not even register as a finding.
- Prioritisation that matches reality Thousands of findings sorted by raw severity is a to-do list nobody can finish. It does not tell you which handful, if fixed first, collapse the most paths to your data.
The rule of thumb. Keep the dashboard for hygiene and compliance. Add path analysis for risk. One tells you what is untidy. The other tells you what can get you breached.
The checklist.
Ten questions. If you can answer all of them with a confident yes, you are reasoning about cloud risk the way an attacker does. Every no is a place where noise is hiding a path.
- Do you have an inventory of what is genuinely internet-reachable, verified from outside, not inferred from config?
- Have you mapped the full identity graph, with wildcards resolved into real permissions?
- Are your sensitive data stores explicitly tagged as the targets the rest of the graph is measured against?
- Can you produce, on demand, the list of complete paths from a public asset to a sensitive store?
- Is your remediation queue sorted by reachability and blast radius rather than raw CVSS?
- Have you identified the chokepoint edges that carry the most paths, and fixed those first?
- Do you re-run path analysis on every meaningful change, not once a quarter?
- Have you killed standing cross-account and cross-cloud trust that no longer earns its keep?
- Are secrets in code, images, and CI logs actively hunted, rotated, and prevented at commit time?
- When the board asks “can someone reach our customer data, and how,” can you answer with a path, not a number?
Worth your time.
A short, vetted reading list. Each of these informs how we think about cloud exposure, and none of it is filler.
- MITRE ATT&CK Cloud Matrix →
The adversary’s playbook for cloud, by tactic and technique. Read it as the moves an attacker makes once they have a foothold. It is the vocabulary your path analysis should speak.
- CIS Benchmarks →
The configuration baselines your CSPM almost certainly measures against. Useful for hygiene, and worth knowing well so you can tell which findings are baseline drift versus real exposure.
- CISA SCuBA →
CISA’s Secure Cloud Business Applications project: concrete, opinionated baselines for securing cloud business apps, from an agency that responds to the breaches.
- Gartner on CTEM →
Continuous Threat Exposure Management: the program model for treating exposure as an ongoing loop rather than a periodic scan. The strategic frame around everything in this guide.