If you read security news headlines, every breach sounds like a Hollywood thriller. Inside the industry, the truth is more mundane: most cloud breaches aren't sophisticated attacks. They're configuration mistakes.
And once you know the pattern, you start seeing it everywhere.
The four patterns we keep finding
1. The bucket that's "internal" but public
Someone needs to share a CSV with a partner. They put it in an existing bucket. Someone else, three months later, accidentally toggles the bucket to public to fix a different issue. Now the CSV — and everything else in that bucket — is on the open web.
We've found buckets containing customer PII, internal financial reports, and backup database dumps simply by browsing the address space. No exploit required.
2. IAM roles with star permissions
A developer needs a service to "do a thing in S3." Under deadline, the role gets s3:*. The deploy ships. The role lives forever. A year later, that service is compromised through an unrelated bug — and the attacker has full control of your storage layer.
The principle of least privilege is boring but it's the single most effective thing you can do in cloud security.
3. The metadata service exposure
EC2 instances run a metadata service at a fixed internal IP. If your application has a server-side request forgery (SSRF) bug, an attacker can ask the metadata service for the instance's credentials and walk away with the keys to your environment.
The fix exists (IMDSv2) and has for years. Most fleets still have legacy instances running v1.
4. The forgotten resource
An engineer spins up a dev database, exposes it to test something, and gets pulled into a different task. The database stays running. It has weak credentials, no MFA, and it's in your production VPC. It sits there for months, indexed by Shodan and waiting to be discovered.
The most common piece of advice in cloud incident reviews is: "we forgot it existed."
Why this keeps happening
Cloud platforms have hundreds of services and thousands of toggleable settings. The defaults are usually safe — but the patterns engineers reach for under deadline are usually not. And once a configuration is wrong, it tends to stay wrong because nobody is reading it.
What actually moves the needle
Three things, in order of impact:
- Continuous config monitoring. Use the tools your provider gives you (AWS Config, Azure Defender, GCP Security Command Center) or a third-party CSPM. The point isn't to find every issue. It's to find the new ones the day they're introduced.
- Quarterly access reviews. Every role, every key, every user. If nobody can explain why a permission exists, remove it.
- An external review once a year. Inside teams normalize their environment. Outside reviewers don't. We routinely find resources our clients didn't know they had.
None of this is glamorous. None of it makes a great conference talk. But this is what stops most breaches.