The breach that needs no exploit

The dramatic version of a cloud breach involves a zero-day and a nation-state. The common version is far more boring: a storage bucket set to public, a database security group open to the entire internet, an IAM role with administrator rights handed to a function that needed read access to one table. No exploit, no malware — just a setting that was wrong, found by an attacker who was scanning for exactly that. The shared-responsibility model is unforgiving here: the cloud provider secures the infrastructure, but the configuration is yours, and the configuration is where the breaches happen.

This is the cloud edition of the attack surface problem. The perimeter isn't a firewall anymore — it's thousands of resource settings, any one of which can quietly expose data to the world. Cloud security posture management (CSPM) is the discipline of continuously checking those settings against a known-good baseline and catching the wrong ones before someone else does.

The misconfigurations that actually cause breaches

A handful of categories account for the overwhelming share of cloud incidents:

  • Public storage. An object store bucket or blob container set to public-read, exposing customer data, backups, or logs to anyone with the URL. The single most reported cloud breach pattern, and almost always an accident.
  • Over-permissioned identities. A role, user, or service account granted far more than it needs — wildcard permissions, standing admin, a function that can delete what it only had to read. This is least privilege failing at the machine-identity layer, and it turns one compromised credential into total control.
  • Open network paths. A security group or firewall rule allowing 0.0.0.0/0 to a database port, an admin panel, or an SSH/RDP endpoint that should never face the internet.
  • Disabled guardrails. Logging turned off, encryption-at-rest not enabled on a new volume, MFA missing on the root account, public-access-block switched off "temporarily" to debug something.
  • Forgotten resources. A snapshot shared publicly, an old environment left running, a key that should have been rotated — the shadow cloud that's on nobody's inventory.

None of these require skill to exploit. They require only that someone notices before you do, and attackers run continuous scans precisely so they notice first.

Baselines: define "right" before you can detect "wrong"

You can't flag a misconfiguration without a definition of correct. That definition is a baseline — a documented set of expected configurations, usually built on a recognized hardening standard like the CIS Benchmarks for your cloud provider. The baseline answers, for every resource type: should this be public? Must this be encrypted? What's the maximum scope this role should hold?

  • Start from a published benchmark rather than inventing one; the CIS cloud benchmarks encode years of collective hard-won lessons.
  • Adapt it to reality. A handful of resources legitimately need to be public — your marketing site's assets, a public API. Those become documented exceptions, not silent ones, so the genuine "public bucket" finding doesn't drown under known-good noise.
  • Tier by data sensitivity. A bucket holding restricted customer data earns the strictest baseline; a static-asset bucket earns a lighter one. Classification and configuration reinforce each other.

Detection has to be continuous, because the cloud changes constantly

The defining trait of cloud infrastructure is velocity — resources are created, modified, and destroyed by automation and by people all day long. A configuration audit you run quarterly is a photograph of a river. A new bucket goes public an hour after your audit and stays exposed for three months until the next one. So CSPM has to be continuous: pull the actual state of your cloud accounts via their APIs, compare it against the baseline on an ongoing basis, and surface every deviation as it appears.

This is configuration drift detection applied to the cloud, and the discipline is the same as everywhere else in a mature program: a deviation isn't an email to ignore — it's a finding with an owner, a severity driven by reachability and what it exposes, and a deadline. A public bucket full of customer records is a 72-hour emergency; an unencrypted volume on an internal dev box can wait behind it.

Prioritize by exposure, not by raw count

A CSPM scan of a real environment returns hundreds of findings, and treating them as a flat list reproduces the alert fatigue that kills detection everywhere. Rank by the same exposure-first logic that governs the rest of the program:

  1. Is it reachable from the internet, unauthenticated? A public-facing misconfiguration outranks an internal one every time.
  2. What does it expose or grant? Customer data and admin-level permissions outrank a missing tag or a verbose log setting.
  3. Is it actively dangerous now? A publicly exposed database beats a theoretical hardening gap.

The point is the same as in vulnerability prioritization: a small team has finite hands, and the few misconfigurations that actually expose data have to float to the top while the cosmetic ones wait their turn.

What a platform does, and where the line is

A posture-management platform can connect to your cloud accounts, enumerate what's actually running, compare it against a hardened baseline, and keep the deviations ranked, owned, and tracked to closure — with the evidence archived for your next audit. It organizes the work and proves it was done. It does not, by itself, certify your environment as secure, grant or guarantee any compliance certification, or make the remediation for you; closing the security group, tightening the role, and locking the bucket remain your team's actions. What the platform guarantees is that you find the wrong setting fast — not that the setting is never wrong.

The cloud rarely gets breached by genius. It gets breached by a checkbox left in the wrong state and found by someone scanning for it. Define what "right" looks like, check it continuously, and fix the exposed ones first — because the misconfiguration you find on Tuesday is the breach you didn't have on Friday.