CSPM

How it works

CSPM (Cloud Security Posture Management) continuously scans cloud accounts, via read-only API access, for misconfigurations: a public S3 bucket, a security group open to 0.0.0.0/0, a database without encryption at rest, an IAM policy with a wildcard resource. It checks live configuration against benchmarks like the CIS Foundations Benchmark or a cloud provider's own well-architected rules, then flags drift and, in more mature tools, auto-remediates it. Because it reads configuration rather than instrumenting workloads, a CSPM tool can cover an entire AWS, Azure, or GCP estate within hours of connecting it, no agents to install.

When it matters

CSPM matters the moment a team has more than one or two cloud accounts, because misconfiguration, not exploited zero-days, causes most cloud breaches: the Capital One breach and countless leaked-S3-bucket incidents trace back to a config error a scanner would have caught. It's the cheapest, fastest cloud security control to stand up and should predate almost everything else on this list, including CNAPP. Skip it and you're relying on manual review or nothing to catch a bucket someone made public for a five-minute test and forgot about.

Common misconceptions

• "CSPM catches runtime attacks." It catches configuration drift, not an attacker already inside a container; that's CWPP's job, and why CNAPP bundles both.
• "CSPM is enough cloud security on its own." It's necessary but not sufficient. It won't catch an over-permissioned IAM role being actively abused (CIEM) or a vulnerable dependency baked into a container image.
• "CSPM requires agents on every workload." Core CSPM is agentless, API-based configuration scanning; agents come into play only for the workload-level features some vendors bolt on.