Comparison
CSPM severity vs attack-path prioritization
A CSPM severity score ranks a finding by its signature (a CVSS number, a posture rule) in isolation. Attack-path prioritization ranks it by whether an attacker can actually reach it and what they gain if they do — entry point, the identity it exposes, and the blast radius from there. The first is a sortable column; the second is a graph. Only the second tells you what to fix first.
A cloud finding has two very different kinds of importance, and most tools only surface one of them.
| CSPM severity | Attack-path prioritization | |
|---|---|---|
| Ranks by | CVSS / posture-rule severity, per finding | Reachability + identity blast radius, across findings |
| Unit | a row in a table | a graph: entry → identity → impact |
| “Critical” means | the signature is bad in the abstract | an attacker can reach it and gain something real |
| Blind to | whether anything can actually get to it | nothing reachable, by construction |
| Output | a list you sort by a number | a ranked set of paths to cut |
A severity column is not a risk ranking
A CSPM tells you a security group allows 0.0.0.0/0 on port 22, rates it High, and moves on. It does not know whether that host is in a public subnet, whether anything is listening, what IAM role the instance can assume, or what that role can reach. Two findings with identical CVSS can differ by orders of magnitude in real risk — one is a dead end, the other is the first hop to your data. Sorting by severity puts them next to each other and asks your team to guess.
The result is the failure every platform team knows: hundreds of “criticals,” alert fatigue, and a genuine breach path sitting at rank 240 because its individual signature scored Medium.
What an attack path models that a score can’t
Reachability is a property of the graph, not the finding. To prioritize honestly you have to model three things together:
- Entry — what an unauthenticated or low-privilege attacker can actually touch (public exposure, weak auth, an over-shared bucket).
- Identity — what credential or role that entry yields, and what that identity can assume next. In cloud, lateral movement is mostly an IAM problem, not a network one.
- Blast radius — what the reachable identities can read, write, or destroy, and which trust boundaries they cross.
A Medium-severity SSRF on an instance with a role that can read every S3 bucket in the account is not Medium. The score never had the context to know that.
How to re-rank your own findings
You don’t need a new product to start. You need to overlay the data you already have:
- Map each High/Critical finding to its resource, and the resource to the IAM role it carries.
- For each role, compute (or read from Access Analyzer / policy simulator) what it can actually do and reach.
- Mark which findings are reachable from an untrusted entry point at all. Demote everything that isn’t to a backlog.
- Rank the reachable set by the impact of the identity at the end of the path, not the severity of the entry.
That ordering usually inverts the scanner’s top 20. The findings that move to the top are the ones worth an engineer’s week; the rest is hygiene you schedule.
A Cloud Security Review does exactly this re-ranking, and hands back the Terraform that cuts the top paths — not a re-sorted spreadsheet.