Common Cloud Misconfigurations
Moving infrastructure to the cloud changes where mistakes get made, not whether they get made. The specific misconfigurations differ from traditional on-premises findings, but they are just as common, and often easier for an attacker to find at scale.
Publicly exposed storage
Object storage buckets left readable, or in worse cases writable, by anyone on the internet remain one of the most common cloud findings there is. The failure mode is almost always the same: a default or overly broad access policy that nobody revisited once the bucket started holding real data.
Infrastructure-as-code drift and defaults
Infrastructure-as-code templates make it easy to provision consistent environments, and just as easy to propagate an insecure default across every environment built from that same template. A security group rule that was fine for a quick test deployment has a way of quietly surviving into production, because nobody had a reason to look at it again once it worked the first time.
Overly permissive identity and access roles
Cloud environments make it easy to grant broad permissions quickly, and much harder to notice later that a role granted for one task now has far more access than it needs. A service account created for a single narrow job that ends up with account-wide administrative permissions is a recurring finding across nearly every cloud provider.
Container-level weaknesses
Containers introduce their own layer of configuration risk: images built from outdated base images with known vulnerabilities, containers running with more privileges than their workload requires, and secrets baked directly into an image layer instead of injected at runtime. Each of these is invisible from outside the container and easy to miss without deliberately looking for it.
Why this needs to be a distinct check, not an afterthought
Traditional network and application testing techniques do not automatically surface cloud configuration issues, since many of these misconfigurations never present as an open port or a web response at all. They live entirely in a provider's management plane. A thorough engagement treats cloud posture review as its own distinct phase rather than assuming traditional recon will happen to catch it.
These findings often overlap with supply chain security concerns, since a vulnerable base image is, functionally, a dependency problem wearing a cloud-shaped hat.
See it in an actual tool
Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.
Read the documentation