CSPM and posture management
IaC scanning stops bad config before apply, but consoles, runtime, and 10 other teams keep drifting prod. CSPM is the read-only API sweep across every account that finds the public bucket nobody filed a ticket for.
Your IaC gate is green. Every Terraform plan is scanned, nothing public ships through the pipeline, and you sleep well. Then a developer hits a deadline, opens the AWS console, and clicks “make public” on a bucket to share a demo asset — no PR, no plan, no scan. Three weeks later an on-call from your DR account (the one nobody owns, spun up by hand in 2022) pages you: a security group is open to 0.0.0.0/0 on port 5432, and Postgres is answering. Neither change went through your beautiful gate, because neither change was code. This is the gap CSPM exists to close: the pipeline guards what flows through it, but production is mutated by consoles, SDK scripts, runtime auto-scaling, and forty other accounts you’ve never logged into. Posture management is the read-only sweep that asks, continuously, “regardless of how it got this way — is the live cloud actually safe right now?”
By the end of this lesson you’ll know how CSPM reads cloud state across many accounts to find misconfig at scale, why it complements rather than replaces the IaC gate, and where its blind spots and noise will bite you.
What CSPM actually does
Cloud Security Posture Management is, mechanically, an unglamorous thing: it assumes a read-only IAM role in each of your cloud accounts, calls the describe/list APIs (DescribeSecurityGroups, GetBucketPolicy, ListAttachedRolePolicies, and hundreds more), normalizes the responses into a graph of resources and their relationships, and evaluates that graph against a library of rules. A rule is just a predicate over resource state — “an S3 bucket whose effective policy or ACL grants * read” or “a security group ingress with CIDR 0.0.0.0/0 on a database port.” When a resource matches, it’s a finding.
The single property that makes CSPM different from IaC scanning is where it looks. IaC scanning reads your intended config — the Terraform plan, before apply. CSPM reads the actual config — the resource as it exists in the cloud right now, after every console click, SDK call, auto-scaling event, and out-of-band change from teams that never touched your repo. The pipeline gate is a checkpoint on one road into production; CSPM is a satellite over the whole country, and most of the country was never paved by your pipeline.
This is why CSPM is fundamentally a continuous monitoring discipline, not a one-time audit. NIST’s continuous monitoring guidance frames the same idea for any system: security state decays the moment you stop watching it, so you re-assess on an ongoing cadence rather than at a point in time. A cloud account that was clean at 9am is a different security object at 3pm — someone deployed, someone clicked, someone’s Lambda assumed a broader role. CSPM’s job is to keep re-reading.
Two clocks: the sweep and the event stream
A serious CSPM runs on two cadences, and understanding the difference is what separates “we have a tool” from “we have coverage.” The periodic sweep re-reads every resource in every account on a fixed interval — say every few hours. It’s the completeness guarantee: even a resource created by a process you don’t know about will eventually be enumerated and checked, because the sweep doesn’t depend on being told about anything. Its weakness is latency. If your sweep runs every 6 hours, a bucket made public at 12:05 might not be flagged until 18:00 — a six-hour exposure window that a scanner-as-a-service crawling cloud ranges is more than happy to use.
The event-driven path closes that window. The cloud provider emits a config-change event (AWS Config rules, EventBridge on a ModifyDB/PutBucketAcl call, GCP Asset Inventory feeds), and CSPM re-evaluates just that one changed resource within seconds. It’s fast and cheap because it’s incremental. Its weakness is the inverse of the sweep’s: it only sees changes it’s subscribed to, in regions and accounts where the event plumbing is actually wired up — and that plumbing breaks silently. You need both. The sweep is your floor (everything is eventually seen); the event stream is your ceiling (the things you are watching are seen fast).
| Dimension | IaC scanning (pre-deploy) | CSPM (post-deploy) |
|---|---|---|
| What it reads | Intended config: the Terraform plan | Actual config: live cloud state via APIs |
| When | Before apply, in the pipeline | Continuously, after resources exist |
| Catches console / SDK / drift | No — only what flows through CI | Yes — that’s the entire point |
| Catches it before exposure | Yes — bad config never ships | No — it’s already live when found |
| Covers legacy / clickops accounts | No — those have no IaC | Yes — reads state regardless of origin |
| Failure mode | Missed surface (drift, out-of-band change) | Alert fatigue (thousands of findings) |
Drift, scale, and why a “finding” is not a “risk”
Two forces turn CSPM from a tidy linter into a hard engineering problem: drift and scale.
Drift is the slow divergence between what your IaC says and what’s actually deployed. Even in a disciplined shop, someone hotfixes a security group at 2am during an incident and forgets to backport it to Terraform; the next apply either reverts their fix (breaking prod) or someone adds an ignore and the resource is now permanently outside the gate. CSPM is how you see drift — it reports the live state your code no longer describes — but seeing it is only half the loop. The other half is reconciling: either pull the change back into IaC, or formally accept it. Drift you can see but never resolve just becomes a permanent finding everyone learns to scroll past.
Scale is the killer in the enterprise. A CSPM pointed at 300 accounts with a default rule pack will, on day one, return tens of thousands of findings. Most are real-but-irrelevant: an “S3 bucket has no access logging” on a bucket that holds public marketing images, a “security group allows all ICMP” inside a private subnet. If you route all of them, you’ve built an alert firehose nobody reads, and the one finding that matters — the production database open to the internet — drowns. The senior skill in CSPM is not running the scan; it’s triage: rank by blast radius (is the resource internet-reachable? does it hold sensitive data? does it grant privilege?), suppress with a recorded reason rather than ignore silently, and route only the top tier to a human with the context to fix it. A finding is a fact; a risk is a finding scored against reachability and impact. Conflating the two is how teams drown.
▸Why this works
Why not just point CSPM at production and turn on every rule? Because two of CSPM’s own properties fight you. First, the read-only role itself is a target: it can enumerate every resource in every account, so an over-scoped or leaked CSPM role is a recon goldmine — keep it strictly read-only, per-account, and ideally with no ability to read object contents, only metadata. Second, “every rule on” maximizes findings, and findings have a cost: each one consumes triage attention, and attention is the actual bottleneck. The teams that get value from CSPM start with a small, high-signal rule set (internet-exposed + sensitive + privileged), prove they can drive those to zero, and only then widen. Coverage you can’t act on is theater.
How a senior wires it in
CSPM doesn’t replace the IaC gate — it sits behind it as defense in depth. The gate stops the misconfig you author in code from ever shipping; CSPM catches the misconfig that arrives by every other path. A senior wires both, then connects CSPM’s output to a real workflow: dedupe findings so one root cause isn’t 400 alerts, score by blast radius, auto-route the critical tier to the owning team’s tracker with enough context to act, suppress the rest with an audit trail, and feed recurring patterns back into IaC policy-as-code so the same class of misconfig gets caught pre-apply next time. The end state isn’t “we run a scanner.” It’s a closed loop: prevent in the pipeline, detect what slips past in the cloud, reconcile drift into code, and shrink the recurring categories over time.
Your CSPM, pointed at 300 accounts, returns 40,000 findings on its first run. The security team has 3 engineers. What do you do?
Your IaC pipeline scan is green on every deploy. Why do you still need CSPM?
A bucket is made public via the console at 12:05. Your CSPM does a full sweep every 6 hours and also subscribes to config-change events. What's the realistic detection time, and why run both clocks?
Order the CSPM pipeline from raw access to actionable outcome:
- 1 Assume a read-only role in each account
- 2 Poll describe/list APIs into a normalized resource graph
- 3 Evaluate rules to produce findings
- 4 Dedupe and rank by blast radius (reachability + sensitivity + privilege)
- 5 Route the top tier to an owner; suppress the rest with a recorded reason
- 01Explain how CSPM finds misconfiguration across many accounts at scale, and why it complements rather than replaces IaC scanning.
- 02Why are 'drift', the two-clock model, and the finding-vs-risk distinction the hard parts of operating CSPM?
CSPM is the read-only sweep that asks, continuously, whether the live cloud is actually safe — regardless of how each resource got that way. Mechanically it assumes a read-only role per account, polls describe/list APIs into a normalized resource graph, and evaluates that graph against rules to produce findings. Its defining difference from IaC scanning is that it reads the actual config (after every console click, script, and runtime event) rather than the intended Terraform plan, so it’s the only thing that catches console drift, out-of-band changes, and legacy clickops accounts. It runs on two clocks: a periodic sweep for completeness (everything is eventually seen) and an event-driven path for speed (a changed resource is re-checked in seconds). The two hard problems are drift — which CSPM lets you see but which you still have to reconcile back into code — and scale, where a default rule pack across hundreds of accounts produces tens of thousands of findings and the real skill is triage: a finding is a fact, a risk is a finding scored by blast radius, and only the top tier earns a human. CSPM doesn’t replace the IaC gate; it sits behind it as defense in depth, and the recurring categories it surfaces should flow back into policy-as-code. Now when your pipeline scan is green, your next question is: what’s changing my production cloud that never went through the pipeline at all?
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.