What is Cloud Security Posture Management?
Most cloud breaches do not start with a clever exploit. They start with a setting.
Cloud Security Posture Management (CSPM) is the practice of continuously checking cloud infrastructure for misconfigurations and policy violations. A CSPM tool reads your cloud provider's configuration through read-only APIs and reports what differs from a secure baseline.
That is a different question from the one a vulnerability scanner asks. A scanner asks "what software is running, and does it have known flaws?" CSPM asks "regardless of the software, is this account set up in a way that lets someone in?"
What CSPM actually looks at
A CSPM tool connects to your provider's own APIs, usually with a read-only role, and lists the resources in the account along with their settings. Then it evaluates those settings against a rule pack. The categories that matter most in practice:
- NETWORK EXPOSURE
- Security groups open to
0.0.0.0/0, public load balancers in front of internal services, storage buckets with public ACLs, databases reachable from subnets that have no business reaching them. - IDENTITY AND PERMISSIONS
- Roles with wildcard policies, users without MFA, access keys that have not been rotated, service accounts that can assume roles far outside their job. This overlaps with CIEM, covered in its own article on over-permissioned identities.
- DATA PROTECTION
- Unencrypted volumes and snapshots, missing customer-managed keys, backups written to buckets with weaker access rules than the source.
- LOGGING AND AUDITABILITY
- Trails disabled in a region nobody watches, log buckets that the same compromised role could delete, retention set below what an investigation would need.
Most rule packs map each check to one or more frameworks, such as the CIS Benchmarks for AWS, Azure and GCP, NIST CSF, SOC 2 or ISO 27001. The mapping is useful for audits. It does not change what the check itself looks at.
Why it exists as a separate category
On-premises, the boundary was largely physical and shaped by the network: a firewall, a DMZ, a set of hosts you patched. In cloud, the boundary is an API-defined configuration. A single JSON policy document can expose a data store to the internet, and no agent on any host will ever notice, because nothing on the host changed.
That is the structural reason CSPM works without agents. The thing being checked does not live on your machines. It lives in the provider's control plane, and the only place to read it is the provider's API.
What CSPM does not do
Vendors bundle so much into one product now that the boundaries blur. It helps to know where plain posture checking stops.
- It is not a vulnerability scanner. CSPM will not tell you that a container image ships a vulnerable OpenSSL. That is vulnerability management, which asks about software versions rather than settings.
- It is not runtime protection. CSPM reads state. It does not watch a process spawn a shell at 2am. That is the job of a workload protection agent.
- It does not see code before it ships. A misconfiguration written into Terraform is invisible to CSPM until someone applies it. Catching it earlier is infrastructure-as-code scanning.
- It does not, on its own, rank by consequence. A rule fires the same way on a test account and on production. Ranking needs context about what the resource connects to.
- It is not a compliance report. Mapping results to SOC 2 or CIS is a presentation layer over the same checks. An auditor still wants evidence of process, not just a dashboard.
- It rarely covers trust coming in from outside. OIDC providers, SAML federation and cross-account roles are configuration, but many rule packs only check that they exist, not who they admit.
CSPM vs CWPP vs CNAPP vs CIEM
The acronyms describe what a tool inspects and how it collects data. The useful distinction is not the label. It is whether the tool reads configuration, workloads, identities or code.
| Aspect | CSPM | CWPP | CNAPP | CIEM |
|---|---|---|---|---|
| Full name | Cloud Security Posture Management | Cloud Workload Protection Platform | Cloud-Native Application Protection Platform | Cloud Infrastructure Entitlement Management |
| What it inspects | Account and resource configuration | Running workloads: VMs, containers, serverless functions | All of the left, plus code and pipelines, in one product | Who and what can perform which actions |
| How it collects data | Read-only provider APIs, no agent | Usually an agent or sensor, sometimes disk snapshots | A mix of API, agent, snapshot and repository access | Provider APIs and access logs |
| Typical question | Is this bucket public? | Is this process doing something it should not? | Where is the riskiest thing across code, cloud and runtime? | Can this role become admin? |
| Example result | Security group allows SSH from anywhere | Container spawned a reverse shell | Vulnerable image, running with a wildcard role, exposed to the internet | Role holds 400 permissions and has used 12 |
| When it acts | On each scan of the account | Continuously, while the workload runs | Depends on the module | On each scan, informed by usage history |
CNAPP is the newest of the four and the broadest. It is less a separate technique than a packaging decision: the vendor sells posture, workload, identity and code scanning together and links their results. Whether that linking is real or just a shared login screen is the thing to test in an evaluation.
Common misconceptions
"CSPM needs an agent on every host." It does not. Posture lives in the control plane. Agents belong to workload protection.
"A clean CSPM dashboard means the account is secure." It means the account matches the rules that were checked. Unknown trust relationships, leaked keys and vulnerable software can all sit behind a perfect posture score.
"CSPM is only for regulated companies." The most common cloud incidents (a public bucket, an exposed database, an over-broad role) happen in startups at least as often as in banks.
"Severity labels from the rule pack are a priority list." They are the rule author's guess, made before they ever saw your account. More on that below.
Where first-generation CSPM falls down
The common failure is not missing results. It is producing too many and ranking them badly. A rule pack applied across a few hundred resources will return hundreds of results, each carrying a severity label assigned by the rule author with no knowledge of your environment.
So a public S3 bucket holding a marketing image and a public S3 bucket holding database exports both come back as "Critical, public bucket". They are not remotely the same risk, and a queue sorted by severity puts them side by side.
Fixing that requires the tool to know what a resource is connected to: what can reach it, what it can reach next, and whether any of that ends somewhere that matters. That is a graph problem, not a list problem. It is what attack path analysis exists to solve, and what blast radius measures from the other direction.
What good looks like
- Read-only by default. A posture tool needs to read configuration. It does not need permission to change your infrastructure.
- Frequent enough to matter. A quarterly snapshot tells you about a cloud that no longer exists. Daily is the floor for an active account.
- Multi-account and multi-cloud in one model. An attacker crossing from one provider to another does not care that you bought two separate tools.
- Ranked by reachability. If everything is critical, nothing is.
- Honest about coverage. A scan that could not read half an account should say so, not report a clean result.
If you are choosing between products, our side-by-side comparisons of CSPM vendors cover pricing, status models and where each one is strongest. The Wiz comparison is the one most teams start with.
FAQ
Is CSPM agentless?
Yes. CSPM reads configuration from the cloud provider's APIs, usually through a read-only role or service principal, so nothing is installed on your hosts. Products that also need an agent are adding workload protection on top.
What is the difference between CSPM and a vulnerability scanner?
A vulnerability scanner looks at software versions and matches them against known CVEs. CSPM looks at how the account is configured, such as network rules, encryption settings and permissions. You need both, and they rarely overlap.
Does CSPM cover Kubernetes?
Partly. CSPM checks the managed cluster settings exposed through the provider API, such as a public control plane endpoint. Workload settings inside the cluster usually need a separate Kubernetes posture check with access to the cluster itself.
How often should a CSPM scan run?
At least daily for accounts that change often. Resources created and misconfigured between weekly scans can be exposed for days before anyone sees them.
Is CSPM enough for SOC 2 or ISO 27001?
It helps with the technical controls and produces evidence, but neither standard is satisfied by a tool alone. Auditors also look at access reviews, change management and incident response, which are processes rather than settings.
What does CNAPP add on top of CSPM?
CNAPP bundles posture checks with workload protection, identity analysis and code scanning, and tries to connect their results. The value depends on whether the product actually links a vulnerable image to the role it runs as and the network path that exposes it.
Secorvia is a CSPM that ranks these results on one security graph across AWS, Azure, GCP and DigitalOcean.