CSPM Explained: Catching Cloud Misconfigurations Before Attackers Do

The breach that starts with a checkbox

Most cloud incidents do not begin with a zero-day. They begin with a setting: a storage bucket left public, a security group that allows the whole internet on port 3389, an identity policy that grants far more than the workload needs, encryption quietly turned off on a database snapshot. Year after year, industry breach reporting attributes a large share of cloud incidents to misconfiguration and human error rather than sophisticated exploitation. The attacker did not break in. They logged in, or they read a file that was never meant to be readable.

Cloud Security Posture Management (CSPM) exists to close that gap. It is the discipline — and the tooling — that continuously inspects your cloud configuration against a known-good standard, flags the drift, ranks it by real risk, and helps you fix it before someone else finds it first. This post covers what CSPM actually does, how it fits alongside CIEM, CWPP, and CNAPP, why "toxic combinations" matter more than isolated findings, and how remediation should tie back into infrastructure as code.

What CSPM actually checks

At its core, CSPM reads the control plane of your cloud accounts through provider APIs and evaluates the configuration of every resource against a policy set. It is agentless for this part — it does not run inside your workloads, it queries the cloud provider's own description of what exists and how it is set up.

Typical checks fall into a few families:

• Public exposure. Storage buckets, blobs, snapshots, databases, and load balancers reachable from the open internet when they should not be.
• Identity and access. Over-permissive roles, unused credentials, root account usage, missing MFA, and access keys that have not rotated in years.
• Encryption. Data at rest without encryption, unmanaged keys, or keys without rotation policies.
• Network. Security groups and firewall rules that expose management ports (SSH, RDP, database engines) to broad CIDR ranges.
• Logging and monitoring. Disabled audit trails, unlogged regions, or flow logs turned off — the gaps that make an incident invisible after the fact.

The important word is continuous. A one-time cloud assessment is a photograph of a moving target. Cloud environments change hourly, and a temporary "let me just open this port to test" becomes a permanent hole nobody remembers. CSPM watches constantly, so drift is caught in minutes rather than at the next audit.

Benchmarks: CIS, vendor baselines, and compliance frameworks

CSPM is only as good as the standard it measures against. Three layers usually stack together:

1. CIS Benchmarks. The Center for Internet Security publishes prescriptive, consensus-built configuration baselines for AWS, Azure, and Google Cloud. These are the closest thing to a neutral industry default and a sensible floor for any program.
2. Cloud provider baselines. AWS Foundational Security Best Practices, Azure Security Benchmark, and Google's equivalents encode provider-specific guidance the CIS documents do not always cover.
3. Regulatory and framework mappings. The same underlying checks roll up into PCI DSS, HIPAA, SOC 2, NIST 800-53, and ISO 27001 reporting. One configuration scan can serve both the security team and the auditor.

Good CSPM practice is not "turn every rule on and drown in findings." It is selecting the baseline that fits your risk profile, tuning out the checks that do not apply to your architecture, and documenting the exceptions you accept on purpose. A tuned policy set that people trust beats an exhaustive one that everyone ignores.

CSPM, CIEM, CWPP, and CNAPP: where the acronyms fit

The cloud security tooling market has splintered into acronyms, and it helps to see them as layers of one picture rather than competing products.

• CSPM covers the configuration of cloud services — the control plane. Is this bucket public, is this database encrypted, is logging on.
• CWPP (Cloud Workload Protection Platform) covers what runs inside the workloads — vulnerabilities in VMs, containers, and functions, plus runtime threat detection. This is the data-plane counterpart to CSPM.
• CIEM (Cloud Infrastructure Entitlement Management) covers identity at scale — who and what can do what, with a focus on trimming excessive permissions toward least privilege across thousands of roles.
• CNAPP (Cloud-Native Application Protection Platform) is the umbrella that unifies all three, correlating configuration, workload, and identity signals into a single risk view instead of three siloed dashboards.

CSPM is usually where organizations start because it delivers fast, visible wins with no agents to deploy. But configuration findings gain enormous power when they are correlated with workload and identity context — which is exactly the argument for a CNAPP approach and the reason our cloud security practice treats these as one program rather than four tools.

Toxic combinations: why one finding hides the real risk

A flat list of thousands of "medium" findings is close to useless. The finding that matters is rarely dangerous in isolation — it becomes dangerous when it chains with two or three others. Security teams call these toxic combinations.

Consider a single virtual machine that is, individually, only mildly misconfigured on each axis:

• It is reachable from the internet.
• It carries a software vulnerability with a known exploit.
• It runs under an IAM role with permission to read a production data store.

No one of those is an emergency. Together they are a straight line from the public internet to your customer data. A mature posture program scores that attack path as a single critical issue and puts it at the top of the queue, while the ten thousand isolated "informational" findings wait. This path-based prioritization is what separates a modern CSPM program from a legacy compliance scanner that just counts violations. It is also why correlating configuration with vulnerability and identity data — the CNAPP idea — pays off: the toxic combination is invisible if you only look at one layer.

Remediation belongs in infrastructure as code

Finding misconfigurations is the easy half. The hard half is making fixes stick. If an engineer clicks into the console and toggles a setting back, the next Terraform or CloudFormation deployment will happily re-open the hole, because the code — the source of truth — still describes the insecure state. This is configuration drift, and it is why click-to-fix remediation quietly fails.

Durable remediation follows the pipeline, not the console:

1. Fix the code, not the resource. Correct the Terraform module, ARM/Bicep template, or CloudFormation stack so the desired state is secure.
2. Shift left with policy as code. Run tools such as Checkov, tfsec, or Open Policy Agent in CI so a misconfiguration is blocked at pull-request time, before it ever reaches production.
3. Guardrails at the platform. Use AWS Service Control Policies, Azure Policy, or GCP Organization Policy to make whole classes of mistake impossible — for example, denying public bucket ACLs org-wide.
4. Auto-remediation for the well-understood cases. For high-confidence, low-blast-radius issues (an unencrypted volume, public snapshot), an automated workflow can revert the change and open a ticket in seconds.

The goal is to push detection earlier every cycle, so the number of issues that reach a running environment keeps falling. CSPM in production becomes the safety net that catches what the pipeline missed, not the primary line of defense. Building that discipline into how infrastructure is provisioned is a core part of how we run cloud infrastructure for clients.

Multi-cloud coverage without four separate programs

Few organizations live in one cloud. Acquisitions, SaaS-adjacent workloads, and team-by-team decisions leave most enterprises spread across AWS, Azure, GCP, and often Oracle or Kubernetes on top. Each provider names things differently — a security group here is a network security group there — and each has its own console, its own audit log format, and its own idea of a sensible default.

The value of a unified CSPM layer is a single normalized model of risk across all of them: one severity scale, one prioritized queue, one compliance report. Without it, each cloud becomes a separate silo with its own blind spots, and the toxic combination that spans two providers never gets seen at all.

Getting started

If you are not sure what is public in your cloud right now, that uncertainty is the finding. A focused posture assessment across your accounts will surface the exposed resources, the over-privileged identities, and the toxic paths in days, and give you a prioritized, IaC-ready remediation plan rather than a ten-thousand-line spreadsheet.

intSignal runs Cloud Security Posture Management as a continuous service: baseline selection and tuning, attack-path prioritization, compliance mapping, and remediation wired into your CI/CD pipeline across every cloud you operate. Talk to our cloud team and we will help you find the misconfigurations before an attacker does.