Cloud security reviews often produce long lists of configuration findings: public storage, permissive security groups, unused keys, broad policies and missing logging. Those findings matter, but configuration alone does not explain how an attacker reaches a valuable resource.
Attack-path analysis connects the pieces. Instead of asking only whether a control is misconfigured, ask: who can reach it, through which identity, using which permission, and with what impact?
Start with identity
Map the identities that can enter the environment: users, CI/CD identities, workload roles, service accounts, federation roles and exposed access keys. For each identity, record the resources it can access and the roles it can assume.
Build the attack path
- Entry: establish the attacker-controlled or compromised identity.
- Reachability: enumerate resources and APIs available to that identity.
- Privilege: identify policy combinations that permit role assumption, secret access, policy modification or workload control.
- Resource: identify sensitive buckets, databases, secrets, queues, production workloads and control-plane actions.
- Impact: validate the path using a controlled resource and minimal permissions.
Interactive attack-path explorer
Move through the chain
Common connected-risk patterns
Over-permissioned workload identity
A production workload may only need to read one object store prefix but receives broad storage, secret or identity permissions. The security issue is not one policy line; it is the combination of workload compromise and excessive privilege.
Role chaining
An identity with limited permissions can become high impact if it can assume another role, modify a trust policy, or create credentials for a more privileged principal. Always inspect the “can assume” relationship, not only the permissions attached to the current role.
Secrets as pivot points
Secrets in CI/CD variables, metadata services, build logs or configuration stores can become stepping stones. Test whether a compromised workload can retrieve secrets that unlock a second identity or production resource.
Prioritize connected risk
| Finding | In isolation | Connected path |
|---|---|---|
| Broad read permission | Moderate | Potentially high if it exposes credentials or sensitive data |
| Role assumption | Context dependent | High when it reaches a privileged production role |
| Public storage | High if sensitive | Critical when combined with write/execute capability |
| Weak logging | Detection gap | Amplifies impact by delaying response |
Defensive design
Use least privilege, short-lived credentials, explicit trust relationships, workload identity controls, permission boundaries and continuous review of role assumptions. More importantly, test these controls as an interconnected graph rather than as isolated checklist items.
Further reading
For cloud assessments, pair provider-specific guidance with identity and privilege analysis. PocForge approaches cloud testing as an attack-path exercise rather than a configuration-only checklist.