CNAPP & the Unified Cloud Security Stack
Cloud security posture covered CSPM as one tool doing one job: continuously checking live configuration against a benchmark. That page undersold how crowded this corner of the market actually got. Between roughly 2019 and 2023, cloud security tooling split into four distinct acronyms — CSPM, CWPP, CIEM, and DSPM — each with its own vendors, its own console, and its own alert queue. Then almost every major vendor spent the next few years buying, building, or merging their way into shipping all four under one name: CNAPP, Cloud-Native Application Protection Platform. This page is about why that consolidation happened, what actually changed under the hood to make it possible, and — the question that matters more than the acronym — how to tell whether your team needs the unified platform or whether the point tools this course already covers, Prowler and Trivy among them, cover your actual risk surface just fine.
Picture a patient seeing four specialists — a cardiologist, a radiologist, a pharmacist, a lab tech — and each one keeps the patient's chart in their own locked drawer. The cardiologist sees an irregular heartbeat and writes "monitor, low priority." The pharmacist sees a new prescription and writes "standard interaction, low priority." Neither one knows the other drawer exists, so neither one catches that the new prescription is exactly the drug that makes an irregular heartbeat dangerous. The fix isn't a fifth specialist — it's one shared chart all four of them read and write to, so the dangerous combination is visible to whoever looks, not just the two facts in isolation. CNAPP is cloud security's version of that shared chart.
Four categories, four separate consoles
☺ Like you're 10: Four different inspectors, four different notebooks, four different definitions of "urgent" — before anyone thought to put them in one room.
Each of the four letters names a real, distinct question, and each grew its own vendor lineage before anyone tried to sell them together. Getting the boundaries exactly right matters, because the entire rest of this page is about what happens when you stop treating them as four separate purchases.
| Category | The question it answers | What it actually reads | Notable pre-consolidation vendor |
|---|---|---|---|
| CSPM Cloud Security Posture Management | Is the cloud control plane configured safely right now — buckets, security groups, encryption settings, IAM policy documents? | Read-only cloud provider API calls (describe-*, list-*), checked against CIS Benchmarks or an internal baseline. | Dome9 (acquired by Check Point, 2018), RedLock (acquired by Palo Alto Networks, 2019 — became the core of Prisma Cloud); open source: Prowler, ScoutSuite. |
| CWPP Cloud Workload Protection Platform | Is the workload itself — the VM, container, or function actually running — vulnerable, malware-infected, or behaving abnormally right now? | An agent or eBPF sensor attached to the running workload, plus a build-time image scan. | Twistlock (acquired by Palo Alto Networks, 2019); Aqua Security, whose own open-source scanner is Trivy; Sysdig, built on the open-source Falco runtime sensor. |
| CIEM Cloud Infrastructure Entitlement Management | Given every identity policy, resource policy, and trust relationship stacked together, what can each identity actually reach — not what its own policy document claims? | IAM API calls (list policies, get role, list trust relationships) plus permission-usage logs (CloudTrail and equivalents). | CloudKnox (acquired by Microsoft, 2021 — folded into Defender for Cloud); Ermetic (acquired by Tenable, 2023). |
| DSPM Data Security Posture Management | Where does sensitive data actually live across every storage service in the account, how is it classified, and who or what can reach it? | Agentless, sampled access to storage snapshots and metadata, run through a data-classification engine (PII, PCI, PHI, secrets). | BigID, Cyera, Dig Security (acquired by Palo Alto Networks, 2024). |
Two things are worth noticing in that table before moving on. First, the acronym you already know best — CSPM — is the narrowest of the four: it reads control-plane configuration and nothing else. It has no idea what's running inside a workload, who can really reach a resource once every policy is stacked, or what data sits in the bucket it just flagged as public. Second, vendor names keep reappearing across rows under the same parent company — that's not a coincidence, it's the entire second half of this page. Names, valuations, and who-owns-whom in this market move fast enough that this table is a lineage sketch, not a current org chart; treat it as orientation.
Why the market consolidated: correlation, not just convenience
☺ Like you're 10: One tool says "this door is unlocked," a second says "someone standing near that door has a spare key," and neither one is loud enough alone — but together they're an alarm.
The simplest explanation for consolidation is procurement fatigue — nobody wants four separate vendor contracts, four separate SSO integrations, and four separate dashboards nobody fully trusts. That's real, but it's not the interesting reason, and it's not the reason engineering teams should care. The interesting reason is that a finding's real severity is often only visible in combination with findings from a different category, and four siloed tools structurally cannot make that combination for you.
The 2019 Capital One breach, already covered from the IAM side in cloud security posture, is the cleanest real-world case of exactly this gap. Reframe it across the four categories in this page and the shape becomes obvious: a CWPP-class finding (the misconfigured web application firewall was reachable and exploitable via SSRF) chained into a CIEM-class finding (the IAM role it could reach through the instance metadata service was scoped far beyond what the workload needed) to expose a DSPM-class asset (over 100 million customer records sitting in S3). In 2019, no commercial product connected those three dots automatically — a CWPP tool, if one had even been running, would have flagged the WAF misconfiguration as one alert among thousands; a CIEM-class review, if one had run, would have flagged the over-broad role as one finding among hundreds; nothing was correlating "this specific reachable weakness leads to this specific over-permissioned identity, which leads to this specific sensitive dataset" into one prioritized signal. That correlation — not any single finding — is what a modern CNAPP is built to compute automatically.
CNAPP is not "four dashboards in one browser tab." It's one data model — a graph of resources, identities, vulnerabilities, and data classifications — that four different scan types write into and one query engine reads from. The product being sold is the graph and its correlation logic. The four acronyms are just the inputs that feed it.
Under the hood: agentless collection and the security graph
☺ Like you're 10: Instead of installing a tiny spy on every single machine, the platform asks the cloud provider itself for a snapshot of everything, on a schedule, and reads that instead.
Two architectural shifts made this correlation practical to compute at cloud scale, and both trace back to a genuine technical innovation rather than pure marketing repackaging.
The first is agentless collection. Early CWPP tools required installing an agent inside every VM and every container — real coverage, real overhead, and a rollout that never quite reaches 100% of a large, ever-changing fleet, because someone always spins up a workload the agent never got installed on. Wiz, founded in 2020, popularized an alternative that most of the category has since adopted in some form: instead of an agent running inside the workload, the platform calls the cloud provider's own snapshot API to take a point-in-time, read-only copy of a disk volume, then scans that snapshot out-of-band for vulnerabilities, secrets, and malware signatures — no agent, no workload performance impact, and coverage that's a property of API access rather than a rollout campaign. The tradeoff is real too: an agentless snapshot is scanned on a schedule (commonly measured in hours), not continuously, so a CWPP agent watching live syscalls still catches an in-progress exploit an agentless scan would only see on its next pass. Most current platforms run both models and let you choose per workload.
The second shift is the graph data model itself. A relational or document database answers "what resources exist" well; it answers "what can reach what, transitively, across four different kinds of relationship" badly, because that question requires an unbounded number of joins that grows with path length. A graph database — nodes for resources, identities, vulnerabilities, and data classifications; edges for "can assume," "is exposed to," "runs on," "contains" — answers exactly that question natively, because graph traversal is the operation the database is built around. This is the same reason workload identity & pipeline IAM matters as much as it does: every "assumes" and "can access" edge in that graph is exactly the trust relationship that page is about, just computed at the scale of an entire cloud estate instead of one pipeline.
That diagram is the entire pitch for CNAPP, condensed. A siloed CWPP tool would rank the CVE against thousands of other CVEs across the fleet and probably rank it below "critical" on volume alone. A siloed CIEM tool would flag the role's broad grant, but a role named ci-deploy-role having broad S3 access doesn't look unusual in isolation — plenty of CI roles legitimately need it. A siloed DSPM tool would flag the unencrypted bucket, but "is this specific bucket reachable from the public internet through some chain of trust" isn't a question a data-classification engine is built to answer on its own. Only a query that spans all three — public-facing, has this specific vulnerability, whose blast radius includes an identity with a path to this specific sensitive dataset — produces the single, unambiguous "fix this one first" signal a security team actually needs on a Monday morning triage queue.
CIEM close-up: why least privilege needs a graph, not a policy review
☺ Like you're 10: A badge that says "Level 2 access" doesn't tell you every door it secretly still opens once you add up every other rule stacked on top of it.
Cloud security posture already introduced the core CIEM finding — that AWS IAM Access Analyzer and its equivalents consistently show most granted permissions going unexercised. What that page didn't cover is why reading a single IAM policy document is the wrong way to answer "what can this identity actually do." An identity's effective permission is the union of its own identity-based policy, every resource-based policy on anything it might touch, any permission boundary set on it, any Service Control Policy inherited from its AWS Organization, and — the part that breaks most manual reviews — every role it's allowed to assume, recursively. A role with a short, conservative-looking policy can still have sweeping effective access if it's allowed to assume a second role that isn't conservative at all. Reading one JSON document tells you nothing about that chain; you have to walk the graph.
# A single call answers "does this specific action succeed" for one identity —
# it does NOT show you the full effective-permission graph, which is the point.
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::111122223333:role/ci-deploy-role \
--action-names s3:DeleteBucket s3:PutBucketPolicy sts:AssumeRole \
--resource-arns arn:aws:s3:::prod-customer-exports
# Output (abridged) — "explicit deny" would be the answer you want and rarely get:
# EvalActionName: s3:DeleteBucket EvalDecision: allowed
# EvalActionName: sts:AssumeRole EvalDecision: allowed
# MatchedStatements: [ "AdministratorAccess-ci-legacy" ] # attached in 2021, never reviewed since
# A CIEM tool runs this kind of simulation across every identity, every resource,
# and every assumable role in the account — automatically, continuously, and graphed.CIEM tooling adds two capabilities a one-off policy simulator call doesn't give you. Shadow admin detection finds identities that are never explicitly named "Administrator" but that a permission chain quietly makes equivalent to one — a role that can assume a second role that can assume a third role with iam:*, for instance, none of which individually looks alarming. Usage-based right-sizing compares granted permissions against what's actually invoked in CloudTrail (or the Azure/GCP equivalent) over a trailing window — typically 90 days — and generates the exact narrower policy that would have covered every real call the identity made, turning "review this role" from an afternoon of manual JSON archaeology into a one-click diff you can approve or reject. GIAC's Cloud Security Automation (GCSA) certification covers this kind of automated entitlement remediation as an examinable skill if you want to go deeper than this page.
DSPM close-up: the data you don't know you have
☺ Like you're 10: You can't lock up a box of files sitting in a corner of the garage that you forgot was even there.
DSPM is the newest of the four letters, and it exists to answer a question neither CSPM nor CIEM can: not "is this specific, known bucket configured safely," but "where does sensitive data live across every storage service in this account, including the ones nobody remembers creating." A five-year-old RDS snapshot taken before a migration and never deleted, a forgotten data-warehouse export sitting in a bucket nobody labeled, a debug log stream that started capturing full request bodies including payment fields eighteen months ago and nobody noticed — none of these show up in a CSPM scan, because CSPM checks whether a known resource is configured correctly, not whether an unknown resource full of sensitive data exists at all. DSPM tools solve the discovery half agentlessly, the same way CWPP snapshot scanning does — sampling storage objects through the provider's own API rather than requiring a connector inside every database — then run a classification engine over what they find to tag PII, PCI cardholder data, PHI, and credentials by pattern and, increasingly, by machine-learning classifiers tuned per data type.
The payoff is the same correlation story as the rest of this page, applied to data specifically: a DSPM finding by itself ("this bucket contains data matching a credit-card number pattern") is useful but not urgent. The same finding joined with a CSPM fact ("this bucket has a public-read ACL") and a CIEM fact ("this role, assumable from a public-facing workload, can also read it") is the difference between a routine cleanup ticket and an active incident. This is also where DSPM output feeds directly into compliance work — compliance & governance covers how a regulator or auditor wants evidence that sensitive data is inventoried and access-controlled, and a DSPM's classification pass is frequently the only practical way to produce that inventory at cloud scale rather than by manual data-mapping exercise. See privacy engineering & data protection for how that inventory then feeds obligations like GDPR data-subject requests, which require knowing exactly where a given person's data lives — something no amount of careful code review answers if the data ended up in a forgotten snapshot nobody's scanner ever looked at.
A DSPM's sampling isn't exhaustive by design — scanning every byte of every object in a multi-petabyte estate on every cycle isn't economically viable for most vendors, so tools sample representative slices of large datasets and extrapolate a classification confidence. That's a reasonable engineering tradeoff, but it means "DSPM found nothing sensitive here" is a probabilistic statement, not a guarantee — for your single highest-sensitivity datastore (a primary customer database, a payments table), pair the DSPM finding with a targeted, deliberate manual review rather than trusting the sample alone.
Does your team actually need the unified platform?
☺ Like you're 10: Sometimes four cheap flashlights really do cover a small room better than one expensive floodlight you'd barely turn on.
Everything above explains why the correlation argument is real. It doesn't mean every team needs to buy it. Prowler, open source and CSPM-focused, and Trivy, open source and covering SCA, container image, IaC, and secrets scanning from one binary, already give a huge share of teams real coverage across most of this page's four categories — just without the cross-domain graph connecting their output together. The honest question isn't "is CNAPP better than point tools" — on raw capability, for a large enough estate, it usually is — it's "does the marginal correlation value clear the cost, in dollars and in operational overhead, for your environment specifically."
| Signal | Point tools are probably enough | A CNAPP probably earns its cost |
|---|---|---|
| Cloud footprint | Single account or single cloud, a few dozen workloads, one team owns all of it | Multi-cloud, hundreds to thousands of resources and identities, multiple teams provisioning independently |
| Primary need right now | A CIS Benchmark compliance percentage and a list of misconfigurations to fix | A prioritized, cross-domain risk ranking you can't reconstruct by eyeballing four separate tool outputs |
| Engineering capacity | A platform or security engineer can own wiring Prowler, Trivy, and a dedup layer into CI without it rotting | No spare capacity to babysit tool sprawl — sprawl becomes its own unmanaged risk |
| What's actually gone wrong before | Isolated misconfigurations — an open bucket, a stale security group — caught and fixed independently | Incidents (or near-misses) that chained a vulnerability, an identity, and a dataset the way the schematic above shows |
| Budget model tolerance | $0 tool spend acceptable; cost is paid in engineering time instead | Can absorb a per-workload or per-asset SaaS contract, usually priced in the tens of thousands of dollars upward annually even for a mid-size estate |
| Compliance audience | Internal reviews, a small customer-security-questionnaire load | External auditors or enterprise customers expecting continuous, vendor-attested evidence, not a point-in-time export |
A useful middle path exists between "run four disconnected open-source tools" and "buy a CNAPP": DefectDojo, also open source, ingests and deduplicates findings from Prowler, Trivy, and most of the other scanners this course covers into one dashboard and one triage queue. That solves the "four browser tabs" problem completely — but it's worth being precise about what it doesn't solve: DefectDojo aggregates findings that other tools already produced, one severity score per finding. It doesn't hold a live, queryable graph of your cloud estate and can't answer "does a reachable path exist from this vulnerability to that dataset" the way a CNAPP's graph engine can, because no individual scanner it's ingesting from computed that path in the first place. If cross-domain path-finding is the specific capability you're missing, aggregation alone won't produce it — that gap is what you're actually paying for when you buy a CNAPP.
Piloting a CNAPP without getting burned
☺ Like you're 10: Try it on your own stuff before you sign anything, and read carefully what you're handing over to try it.
If the table above points toward "yes, evaluate one," run the pilot against a short, specific checklist rather than a vendor's own demo environment:
- Test against your real environment, not their sandbox. A vendor's canned demo is built to showcase a toxic combination they already know is there. Point the trial at your actual accounts and see what surfaces — including how many findings are simply noise you'll need to tune out.
- Measure the false-positive rate deliberately. Pull a sample of findings and have an engineer who knows the environment adjudicate each one. A platform that looks impressive on finding volume and terrible on precision will get muted within a quarter, which defeats the entire point of buying it.
- Feed it a known toxic combination on purpose. If you know of a real (even if already-remediated) case where a vulnerability, an over-broad role, and sensitive data lined up, check whether the graph actually surfaces that exact path. This is the single most direct test of whether you're buying real correlation or a repackaged dashboard.
- Get the pricing model in writing before the pilot ends. Per-workload, per-asset, and per-identity pricing all scale differently against a fleet that autoscales or churns ephemeral compute constantly — a price that looked reasonable against a steady-state estimate can balloon against a workload that spins up and down all day.
- Check the exit cost. Can you export your findings, your custom policies, and your suppression/triage history if you switch vendors or go back to point tools? A platform that locks your triage history inside a proprietary format is a much bigger commitment than the sticker price suggests.
A CNAPP's own security graph is, by construction, a live map of every vulnerability, every over-permissioned identity, and every sensitive-data location across your entire cloud estate — read-only access to it is close to the highest-value target an attacker could ask for. Vet the vendor's own security posture (their SOC 2 report, their own breach history, how tightly they scope the cross-account role you grant them) with the same rigor you'd apply to any third party you were about to hand read access to everything you own — because that is exactly what you're about to do.
Pick one real IAM role in an account you control and manually reconstruct its effective permissions by hand: list its own attached policies, any permission boundary, any SCP inherited from its OU, and every role it's allowed to assume — then repeat that walk one level deeper for each assumable role. Time yourself. Now compare that against what aws iam simulate-principal-policy (shown above) tells you for a handful of specific actions. The gap between "how long the manual graph walk took" and "how instantly the simulator answered one narrow question" is, at cloud scale across thousands of identities, exactly the gap a CIEM tool — and by extension a CNAPP — is built to close.
Sol: Used to be just me, slowly working through buckets and IAM policies. Now the vendor's demo shows workload vulnerabilities, entitlements, and data classification all lighting up on the same screen.
Foxy: So why not just keep four separate scanners, each one good at exactly one job? Isn't that simpler?
Professor Owl: Simpler for the vendor's org chart. Harder for whoever has to manually notice that a Medium in one tool and a Low in another tool are actually the same attack path.
Rocky the Raccoon: I don't attack one layer at a time. I use whatever's reachable to get in, whatever role I land in to move sideways, and whatever bucket that role can touch to walk out with something. Four separate scanners see four separate low scores. I see one path.
Timmy: We already gate the pipeline with Prowler and Trivy, and neither one's failed us yet. Before I sign off on a platform that costs what a small team's salary does, prove the graph catches something those two structurally can't.
Nutty: And if it does catch something — I want the audit trail it generates archived too, not just the alert. An auditor asking "how do you know" a year from now won't accept "the dashboard said so."
Sol: Slow review, fast correlation — I don't mind sharing the desk with a graph, as long as it earns the seat the same way I did: by actually finding something a quick glance would've missed.
1. Define CSPM, CWPP, CIEM, and DSPM precisely — what does each one actually read, and what question does each answer that the others can't? 2. Reframe the Capital One breach across these four categories: which category-shaped finding fed into which, and why did no single siloed tool at the time connect all three? 3. What are the two architectural shifts that made CNAPP-style correlation practical, and what's the real tradeoff agentless snapshot scanning makes against a live in-workload agent? 4. Why is an IAM policy simulator call, on its own, not the same thing as a CIEM tool — what does "effective permissions" include that a single policy document doesn't show you? 5. Give three concrete signals from the decision framework that would push a team toward point tools instead of a CNAPP, and explain what DefectDojo does and doesn't solve if a team is trying to stay on point tools longer.
Check your answers
- CSPM (Cloud Security Posture Management) reads live cloud control-plane configuration via read-only API calls and checks it against a benchmark — is the account configured safely. CWPP (Cloud Workload Protection Platform) reads the running workload itself, via an agent, eBPF sensor, or snapshot scan — is this specific VM/container/function vulnerable or compromised right now. CIEM (Cloud Infrastructure Entitlement Management) reads IAM policies, trust relationships, and usage logs to compute effective permissions — what can this identity actually reach, not just what its own policy claims. DSPM (Data Security Posture Management) reads storage snapshots and metadata through a classification engine — where does sensitive data actually live and who can reach it.
- The SSRF against the misconfigured web application firewall is a CWPP-shaped finding (a reachable, exploitable weakness in a running workload); the over-scoped IAM role reachable through the instance metadata service is a CIEM-shaped finding (an identity's effective permissions far exceeding its need); the 100+ million exposed customer records in S3 is a DSPM-shaped finding (sensitive data reachable through that identity). In 2019, these would have been three separate findings in three separate tools (if all three tools even existed and were deployed) — nothing was correlating "this specific reachable weakness leads to this specific over-permissioned identity, which leads to this specific sensitive dataset" into one prioritized signal, which is exactly the gap a CNAPP's graph is built to close.
- The two shifts are agentless collection (calling the cloud provider's snapshot API to scan a point-in-time copy of a workload instead of requiring an installed agent) and a graph-native data model (nodes for resources/identities/vulnerabilities/data, edges for relationships like "can assume" or "is exposed to," which makes multi-hop reachability queries a native operation instead of an expensive series of joins). The tradeoff: agentless scanning runs on a schedule (hours, not real time), so it can miss an in-progress exploit that a live in-workload agent watching syscalls continuously would catch — most platforms now run both models and let you choose per workload.
- A policy simulator call answers one narrow question — does this one action succeed for this one identity against this one resource, given policy as it stands right now. "Effective permissions" is the union of the identity's own policy, every resource-based policy on anything it might touch, any permission boundary, any inherited Service Control Policy, and every role it's allowed to assume, recursively. A CIEM tool computes and graphs that whole union continuously across every identity in the account — including "shadow admin" chains where no single role looks alarming but an assumable chain of roles adds up to admin-equivalent access — which a one-off simulator call for a handful of actions doesn't show you.
- Any three of: a small, single-cloud footprint with one team owning it; the actual need being a compliance percentage rather than cross-domain prioritization; no spare engineering capacity to own a CNAPP's ongoing tuning; a history of only isolated (not chained) misconfigurations; inability to absorb per-workload/per-asset SaaS pricing; or a compliance audience that doesn't demand continuous vendor-attested evidence. DefectDojo solves the "four separate dashboards" problem by ingesting and deduplicating findings from tools like Prowler and Trivy into one triage queue — but it aggregates findings other scanners already produced one at a time; it doesn't hold a live, queryable graph of the cloud estate and can't answer a cross-domain reachability question like "does a path exist from this vulnerability to that dataset," because none of the tools feeding it computed that path in the first place.