Cloud providers run infrastructure more securely than almost any customer could. That is not where the breaches come from. They come from the configuration layer, which is entirely the customer's responsibility and is where almost every incident we investigate begins.
The recurring five
1. Storage open to the internet
Still the most common. Usually set deliberately for a legitimate short-term reason, then never reversed. Enable account-level public access blocking and require an explicit, logged exception to override it.
2. Roles far broader than the workload needs
Wildcard permissions get granted during development to make something work, and nobody returns to narrow them. The result is a compromised container that can read every bucket in the account. Review effective permissions rather than intended ones — the gap is usually large.
3. Long-lived access keys
Static credentials end up in source control, CI configuration, shared documents and old laptops. Use short-lived, role-assumed credentials. Where a static key is genuinely unavoidable, rotate it on a schedule and scan your repositories for leaks — including history, because deleting a key from the current commit does not remove it from the past.
4. Logging off, or on but unread
Control-plane audit logging is sometimes disabled entirely, and often enabled but never ingested anywhere that alerts. When we arrive after an incident and the logs do not exist, the investigation is reduced to inference.
5. Nothing watching for drift
Infrastructure defined as code and reviewed properly can still be changed by hand in the console at 2am during an outage, and that change persists. Continuous posture monitoring that flags drift is the control that catches this.
Containers add their own layer
- Images built on bases that have not been rebuilt since the last round of CVEs.
- Containers running as root because it was easier than fixing permissions.
- Kubernetes secrets stored base64-encoded and treated as though that were encryption.
- Cluster networking left flat, so a compromised pod can reach every other pod.
Where to start
Run a posture assessment and fix by exploitability, not by the count of findings. A single over-privileged role reachable from the internet matters more than two hundred informational items. Then put guardrails in the pipeline so the same misconfiguration cannot be reintroduced next sprint — detection without prevention means you will be reading the same report every quarter.