We have read or written the postmortems for hundreds of cloud breaches. The single most common root cause is not a sophisticated attack. It is a misconfiguration that lived in production long enough for someone to find it.
The greatest hits
- A storage bucket with public read enabled
- A database that was supposed to be private accidentally exposed to the internet
- A debug endpoint left on with no authentication
- A cloud-native firewall rule with
0.0.0.0/0"for testing" that never came off - Backups stored in a separate account with weaker controls than production
Why this keeps happening
- Most teams ship faster than their review process can keep up
- Defaults are often permissive in the "let's get started" path of a new service
- Drift accumulates: a setting that was right in 2024 is wrong in 2026 and nobody changed it
- Different teams own different parts of the stack, and the overlap is where mistakes hide
What works
- Infrastructure as code. A configuration that is reviewed in pull request and applied by pipeline is harder to drift than one set in the console.
- Continuous configuration scanning. Detect known-bad patterns automatically. Treat them like code-quality findings.
- A "no console writes in production" rule. Strict, but it forces drift through review.
- Quarterly attack-path reviews. A friendly red-teamer asking "if I had this credential, where could I get?" surfaces gaps before adversaries do.
Takeaway
Sophisticated attackers exist. But before you defend against them, defend against the much more likely scenario: a small mistake left running for too long.
HS Academy
All HS Academy lessons are free to read. Create a free HorizonShield account to explore the platform itself.
Sign up free →