Incident write-ups make for exciting reading — novel techniques, patient adversaries, clever chains of exploitation. The reality of most cloud incidents is duller. Somebody made a change that was reasonable at the time, nobody revisited it, and eighteen months later it was the way in.
Across the assessments we run, the same handful of issues account for the overwhelming majority of genuinely serious findings. None of them are sophisticated. All of them are findable in an afternoon if you know where to look.
1. Roles that accumulated permissions nobody removed
This is the single most common serious finding, and it almost never looks like a mistake when it happens. An engineer is debugging a failing deployment at the end of a long week. The permission model is unclear. They attach a broader policy to unblock the pipeline, intending to narrow it once the release is out. The release ships and the ticket to narrow it is never written.
Repeat that a few dozen times across a few years and you have a set of roles with permissions far beyond anything the workload uses. The damage shows up later: a single compromised credential that should have granted read access to one bucket instead grants administrative control over the account.
How to find it: every major cloud provider can report the permissions a principal was actually granted against the permissions it has used over the last ninety days. The gap between those two numbers is your exposure. Start with the roles attached to anything internet-facing, and with any principal whose name contains "temp", "test", or a person's initials.
2. Storage exposed through a path nobody traced
Direct public buckets have become rare — the providers now make them hard to create by accident and loud when you do. What remains common is indirect exposure: a bucket that is correctly private but is fronted by a CDN distribution with no origin restriction, or one shared with a partner account that was itself later compromised.
The bucket-level configuration looks correct in every dashboard you check. The data is still reachable, just not by the path anyone thought to audit.
Worth checking today For each storage bucket holding sensitive data, list every principal, service, and network path that can reach it — not just the bucket policy. Most teams find at least one route they had forgotten existed.
3. Long-lived access keys in places they should never be
Static credentials that never expire are the most reliable foothold an attacker can hope for. They turn up committed to repositories, baked into container images, pasted into CI variables that predate a proper secrets store, and living in the home directory of a laptop that left the company with its owner.
The frustrating part is that nearly every use of a long-lived key has a modern alternative — workload identity federation, instance roles, short-lived tokens issued per session. The keys persist mostly because rotating them means finding every consumer, and nobody is confident they can find every consumer.
How to find it: scan your repository history, not just the current tree — a key removed in a later commit is still in the history and still valid unless it was rotated. Then pull the last-used timestamp for every access key in your accounts. Keys unused for ninety days should be disabled; keys older than a year that are still in use need a migration plan.
4. Logging that is enabled but not reaching anyone
This one does not cause the breach. It determines how bad the breach becomes.
Most organizations enable cloud audit logging early, because it is a compliance checkbox and it is cheap. Far fewer confirm that the logs are aggregated somewhere durable, retained long enough to cover a slow intrusion, and actually connected to something that would notice an anomaly.
The result is a familiar and painful conversation during incident response: we can see that something happened, but the logs from the relevant window rolled off thirty days ago, so we cannot tell you what was taken. That uncertainty is expensive. In most breach-notification regimes, being unable to prove what was not accessed means disclosing as though everything was.
5. Network rules that were temporary a year ago
Every environment has at least one security group opened to the world for a vendor integration, a load test, or an urgent debugging session. The comment field, if anyone filled it in, says something like "temp — remove after migration".
These are trivially discoverable from the outside. Automated scanning of cloud provider address ranges is continuous and cheap, and an exposed management port typically attracts connection attempts within minutes of being opened.
How to find it: enumerate every rule permitting inbound traffic from 0.0.0.0/0 and confirm each one is deliberate. Then check what those rules protect — an open port on a workload with an over-permissioned role is the combination that turns a scan into an incident.
The pattern underneath all five
None of these are exotic and none require an advanced adversary. What they share is that each was a sensible decision under time pressure, made irreversible by the absence of any process that revisits it.
That is why we push clients toward guardrails rather than audits. An audit finds the problems that exist today. A guardrail — policy as code, enforced at deploy time — stops tomorrow's version from being created in the first place. The audit still matters, but it should be shrinking each time you run it, not resetting to the same number.
If your findings count is roughly the same every quarter, you are treating symptoms. Something upstream is generating them faster than you can close them.
If you want a second opinion on where your own estate stands, that is essentially what our cloud security posture engagement is: find what is genuinely reachable, rank it honestly, and fix the mechanism rather than the symptom.