Ranking six cloud findings by attack path
Sorted by how each finding looks on its own, the six findings in our fictional Cloud Security Review sample put internet exposure first and two of the three high-severity findings last, because the checks they resemble pass. Ranked by entry, identity and blast radius, the build server that can deploy to production stays first, and the WorkloadAdmin role’s power to stop audit logs and delete backup copies rises to second and third. The exposure findings drop, because each needs another control to fail first.
Orivane Industrial Group is a fictional company. We invented it, its people and its 48-account AWS estate for our sample reports; no client data is involved. Here we take the six findings from our illustrative Cloud Security Review sample and rank them twice: first by how each one looks on its own, then by the method in CSPM severity vs attack-path prioritization — entry, identity, blast radius.
Two orders for the same six findings
The signature order is our reconstruction for this note, not output from any product and not part of the report. It sorts by the loudest thing each finding shows when you read one resource at a time: internet exposure, then segmentation, then hygiene, then checks that pass. The path order is the report’s remediation sequence, from 13 to 24 July. Its severity key already weighs “reachability, required privilege, potential impact and how easily an attack could be detected.”
| Finding | What a one-resource check sees | Signature | Path | Report severity |
|---|---|---|---|---|
| SEC-01 Build server can deploy to production | A build server reachable from the internet | 1 | 1 | High |
| SEC-03 Exceptions survive account moves | An exception that still permits a public endpoint | 2 | 5 (tied) | Medium |
| SEC-05 Shared routes connect environments that should be separate | One route table importing production and non-production attachments | 3 | 4 | Medium |
| SEC-06 A successful deployment does not prove readiness | A blank cost owner and a missing audit probe | 4 | 5 (tied) | Medium |
| SEC-02 Application administrators can stop audit logs | Logs arriving in orv-log: the check passes | 5 (tied) | 2 | High |
| SEC-04 Backup and workload administration overlap | Backup schedules on all 24 production workloads: the check passes | 5 (tied) | 3 | High |
SEC-01 stays first, for a different reason
A signature check ranks SEC-01 first because nacre-build-03 is reachable from the internet. The risk is the identity edge behind it. Nine of the 24 production roles trust orv-ci/BuildRunner, and in probe ID-17 nacre-build-03 assumed LedgerFlow’s ReleaseDeploy role and was authorized to update the orders-api artifact, without changing anything in production. After a runner compromise, no user sign-in is required.
That edge spans two accounts: ReleaseDeploy’s trust policy sits in orv-ledgerflow-prod, the caller’s permission in orv-ci. AWS allows a cross-account request only when the policies in both accounts allow it, so a rule that reads one resource at a time sees half an edge in each. An IAM Access Analyzer external access analyzer scoped to the organization stays quiet too: it treats every principal inside its zone of trust as trusted, and orv-ci is one of Orivane’s own accounts.
The test is simple. Take the runner off the internet, and the signature finding closes while the path stays open, because a compromised runner can still use the role. The report names the decisive evidence: “the combination of trust policy, caller permission and an allowed release action, not the existence of a public runner alone.”
SEC-02 and SEC-04 climb from “passes” to second and third
Both start from one identity, WorkloadAdmin. In six production accounts it can stop the local delivery trail (AUD-12 recorded an allowed StopLogging decision for orv-dockline-prod), and it can assume RecoveryAdmin for 18 of the 24 production workloads, LedgerFlow and Dockline among them. A logging check passes because logs arrive in orv-log; a backup check passes because every production workload has a schedule. Neither asks who can switch the control off.
Their entry is a privileged workload session, not the internet, so they sit below SEC-01. Blast radius lifts them above the rest. SEC-02 lets an attacker interrupt records before acting. SEC-04 lets them delete the copies Orivane would recover from; a successful backup job proves that a copy was created, not that it survives a compromise.
The report draws two limits worth copying. Deployment permission does not imply audit or backup administration, so these are separate paths (P2 and P3 in the report), not a continuation of SEC-01. And retained archive objects stay protected: what SEC-02 lets an attacker stop is future collection. The fix moves collection authority into the security boundary. On AWS, an organization trail is one way to do that, since users in member accounts cannot turn its logging on or off.
SEC-05 and SEC-03 drop: each needs another failure first
SEC-05 looks severe on paper. In ca-central-1, the transit route table nacre-tgw-shared imports 12 non-production and eight production attachments, and probe NET-31 reached LedgerFlow’s application subnet from orv-partsdesk-test. The endpoint firewall denied TCP 5432. The environment boundary is missing from routing, so the finding is real, but turning it into access takes another failure, such as a later firewall change. That is the report’s definition of Medium.
SEC-03 looks the most alarming after SEC-01. Exception EX-014 still permits a public endpoint: orv-partsdesk-test moved from Sandbox to NonProduction on 2 July, and the exception’s 30 June expiry triggered no policy review. Seven of eleven exceptions have expired. As a graph, it joins SEC-05, because orv-partsdesk-test is the account NET-31 started from. An entry through that endpoint would start where SEC-05’s route starts, and would then depend on endpoint firewalls rather than an environment boundary. Two rows in a scanner list are one path in the graph, and that path is still a second failure away.
SEC-06 stays low, but it guards the next account
SEC-06 reads like hygiene: factory run ACF-218 marked orv-cartonspec-prod ready with a blank cost owner and a missing audit probe. It has no entry of its own. What it controls is the next production account, because the nacre-1.3.2 workflow has no independent admission step. Hence its shared last window with SEC-03, and the report’s advice to hold expansion until the required controls pass their tests.
What to take from it
- Rank the edge, not the resource: trust policy, caller permission and allowed action, read together.
- Treat a passing check as a question: who can turn this control off?
- Group findings by shared identity or account: WorkloadAdmin links SEC-02 and SEC-04; orv-partsdesk-test links SEC-03 and SEC-05.
- A denied hop demotes a finding; it never deletes it.
A Cloud Security Review produces this kind of order: the paths first, each finding tied to the test that proves it closed — a build token that fails, an approved release that still succeeds. The sample report shows what that looks like across Orivane’s 48 accounts.