Skip to content
sec/atlas
back to the map
practice
stage: detectar
4 min read

CSPM - cloud posture

Cloud Security Posture Management scans each account's configuration against baselines (CIS, PCI, NIST) and flags drift before it becomes an incident.

WizLaceworkPrisma CloudOrca Security

What it is

CSPM () is your cloud's continuous auditor. It connects to the accounts (via a read-only role) and compares the real configuration against published baselines (CIS, PCI, NIST 800-53, your team's internal benchmark). The difference between the current state and the baseline is the finding: unencrypted storage, an SG with 0.0.0.0/0, an IAM user without MFA, a log group without retention.

The idea is simple: most incidents do not start with a sophisticated attack, they start with a bucket that stayed open for three months. CSPM exists to close that window automatically.

How it works: rules and benchmarks

The rule engine is declarative. For each control, an expression evaluates the configuration: if the resource matches the dangerous pattern, a finding. Public frameworks become reusable rule packs.

The more rules, the more noise. Most teams turn on the whole benchmark in the first month and spend the rest of the year turning off rules that do not apply (Kubernetes 1.22 on a legacy service, RDS without CMK in dev). The practical filter is to separate the global baseline (applies to every account) from the per-environment baseline (dev gets weaker controls, prod gets everything).

  • CIS Foundations: general hygiene baseline (root MFA, CloudTrail on, S3 without public access)
  • PCI DSS: payment controls (encryption at rest, segmentation, audit log)
  • NIST 800-53 / 800-171: federal controls, requires programmatic compliance in US government orgs
  • Trust Services Criteria: security, availability, confidentiality, privacy

Drift: the finding that comes back every week

Drift is when infrastructure goes back to an insecure state without anyone asking for it. It happens through concurrent automation (Terraform apply and the console at the same time), through manual changes during an incident, or through another team touching what they should not. CSPM measures drift through configuration diffs between runs: the same account today and yesterday should be identical, barring approved changes.

The value of drift is not the alert itself, it is the signal that an unapproved change exists. Finding the origin (cloud console, outdated , another pipeline) is where the problem lives.

CSPM finding - drift detectedjson
{
  "rule_id": "S3-PUBLIC-READ-DRIFT",
  "framework": "CIS AWS Foundations 2.1.5",
  "severity": "high",
  "resource": "arn:aws:s3:::loja-customer-uploads",
  "account": "111122223333",
  "region": "us-east-1",
  "title": "Bucket that blocked public read access was reverted to public",
  "drift": {
    "previous_state": {
      "public_access_block": "all_true",
      "evaluated_at": "2026-09-29T08:00:00Z"
    },
    "current_state": {
      "public_access_block_configuration": {
        "block_public_acls": false,
        "ignore_public_acls": false,
        "block_public_policy": false,
        "restrict_public_buckets": false
      },
      "evaluated_at": "2026-10-09T14:22:11Z"
    }
  },
  "remediation": "aws s3api put-public-access-block --bucket loja-customer-uploads --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
}

Multi-cloud and the connector problem

Each provider has its own APIs, and each CSPM has to learn to talk to AWS, Azure, GCP, OCI, Alibaba. The best products do this natively; the worst look like a badly calibrated translator. Evaluating multi-cloud support is not checking the logo on the landing page, it is running the same CIS control on two identical accounts (one AWS, one Azure) and seeing whether the finding comes out the same.

The choice between agent-based and API-based matters. A purely API-based CSPM reads the configuration, not what runs inside it: it sees the , not the process listening on the port. For runtime workloads, (next topic) comes in.

Remediation: from finding to fix

Remediation has three levels. Manual: the finding becomes a Jira ticket, someone fixes it. Assisted: the CSPM generates the command (terraform plan, aws cli) and a human approves it in a PR. Automatic: the CSPM applies the fix by itself, with rollback if something breaks (an S3 Public Block that wipes an active policy is the classic case).

The safe path is to start manual in all accounts, move to assisted in dev/staging environments, and turn on automatic for controls with a small (forcing logs, forcing encryption) and under monitored change. Auto-remediation on IAM with a production key is a recipe for an incident.

Where it fits

CSPM is continuous detection, so there is no single 'where it fits': it runs 24/7 against the provider's API. In the change flow, it appears at two points: in the IaC PR (evaluates before the apply) and in post-apply monitoring (evaluates the real state). The first catches the rule before the break; the second catches what drifted without anyone asking.

Strengths

  • immediate visibility: within an hour you have a list of open buckets, unused keys and security groups that turned into Swiss cheese
  • programmatic compliance: CIS/PCI/NIST stops being an annual audit and becomes a daily dashboard
  • drift detection closes the gap between IaC (what is applied) and runtime (what runs)

Limitations

  • CSPM sees configuration, not behavior: a container running a crypto miner with an apparently OK SG passes the benchmark
  • noise is the Achilles' heel: the whole benchmark becomes 500 findings in the first week, and without triage it becomes an ignored dashboard
  • automatic remediation has a blast radius: fixing a bucket without understanding its use breaks an application in production, and a silent fix hides the bug that needed an architecture change
CSPMcloud security posture managementA tool that scans your cloud configuration against best practices and benchmarks (CIS, NIST), flagging public S3 buckets, overly broad IAM, exposed ports. It asks the question humans forget: 'what is misconfigured RIGHT NOW?'.see in glossary →IAMidentity and access managementThe set of policies, roles and credentials that says who every human, service or workload is, and what each one can do. In the cloud, IAM became the new perimeter: the network edge got porous, so identity carries the authorization.see in glossary →SOC 2An auditor's report on a service provider's controls for security and related criteria, commonly requested by customers.see in glossary →IaCinfrastructure as codeDescribing infrastructure in versioned files (Terraform, Ansible). It brings review, history and testing to configuration, but replicates mistakes at scale if it is not scanned.see in glossary →Security groupsecurity groupA stateful list of rules attached to an instance or network interface in the cloud: who can come in on which port, from which source. It works as a host firewall at the cloud level, and it fails open by default: if you forget to close a port, it stays open to 0.0.0.0/0.see in glossary →CWPPcloud workload protection platformMonitored protection for running workloads: VMs, containers, serverless functions. It combines visibility into what runs (processes, syscalls, network) with prevention (blocking execution, isolating anomalies). It is endpoint security reworked for the ephemeral reality of the cloud.see in glossary →Blast radiusblast radiusThe size of the damage when something breaks: one account, an entire region, a tenant. Good cloud design limits the radius through isolation (separate accounts, separate VPCs, narrow roles) so that a failure or an attack does not become a full-blown disaster.see in glossary →

connections on the map

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Study before

test what you learned

Loading questions…