Three vendor categories claim the cloud security budget, and their acronyms get used interchangeably in sales calls even though they answer different questions. CSPM checks whether your cloud is configured the way it should be. CWPP checks whether the workloads running inside that cloud are compromised or carrying exploitable flaws. CNAPP tries to sit above both and tell you which combination of a bad configuration and a vulnerable workload actually adds up to an attack path worth fixing first. Picking the wrong layer, or paying twice for the same layer under two different names, is a common and avoidable mistake. This guide breaks down what each category actually does, where the marketing overlaps stop matching the engineering, and how to decide based on team size, cloud maturity, and compliance load rather than a vendor’s slide deck.
The three acronyms mapped to the three questions they answer
Cloud Security Posture Management (CSPM) answers one question: is this resource configured according to policy? It reads cloud provider APIs, not the workload itself, and compares what it finds against a rule set, CIS benchmarks, or a custom policy written in Rego or a similar language. A public S3 bucket, an IAM role with “iam:*” attached to a Lambda function, a security group open on 0.0.0.0/0 for port 22, an unencrypted RDS snapshot: all of these are CSPM findings, and none of them require an agent inside the resource to detect.
Cloud Workload Protection Platform (CWPP) answers a different question: is this specific running thing, a VM, a container, a serverless function, safe right now? That requires visibility into the workload’s internals: process trees, open sockets, loaded kernel modules, package manifests, and in the more mature products, syscall-level behavior. CWPP is where you find container image scanning, host-based intrusion detection, memory scraping for credential theft, and runtime application self-protection.
Cloud-Native Application Protection Platform (CNAPP) answers a third question that neither of the other two can answer alone: given everything you know about configuration and everything you know about the workload, what is the actual path an attacker would take, and what is the smallest number of fixes that breaks the most paths? A CNAPP is not a new detection technology. It is a correlation layer that ideally sits on top of CSPM and CWPP telemetry, plus identity data (CIEM) and sometimes data classification (DSPM), and produces a graph instead of three separate alert lists.
Configuration risk vs workload risk vs correlated risk
Configuration risk is static and provider-side. It exists whether or not anything is running, and it is usually cheap to detect and expensive to triage at scale because a single misconfigured Terraform module can produce the same finding across two hundred accounts. Common configuration risk categories: overly permissive IAM policies, missing encryption at rest, public network exposure, disabled logging (CloudTrail, VPC Flow Logs), and drift between the IaC definition and the live resource.
Workload risk is dynamic and runs on a clock. A container built from a base image with a fixed CVE last week is not a risk until it is deployed with the old image still cached in a registry. A process that opens an outbound connection to an unfamiliar IP at 3 a.m. is a workload risk signal that no configuration scan will ever produce, because the configuration was correct; the behavior was not. CWPP tools typically score this with an agent (kernel module, eBPF probe, or user-space daemon) or, for lighter coverage, an agentless snapshot scan of the disk and installed packages.
Correlated risk is the product of the two, and it is where most of the actual damage happens. An internet-facing EC2 instance with a public security group is a CSPM finding worth a medium severity on its own. A vulnerable OpenSSL version on that same instance is a CWPP finding, also medium on its own. The same instance holding an IAM instance profile with “sts:AssumeRole” rights into a role that can read the production database is an identity finding. None of the three alone justifies an emergency page. All three on the same asset is a critical, working exploit chain, and that is the specific value a correlation engine is supposed to add over three separate dashboards.
Where CNAPP claims overlap and where they are marketing veneer
Since 2021, most CSPM vendors have relabeled their product CNAPP by bolting on an agentless workload scanner, and most CWPP vendors have done the reverse by adding a configuration rule engine. The result is that “CNAPP” on a vendor’s homepage tells you almost nothing about depth. Two products can both claim the label while one does real-time syscall monitoring with an eBPF agent and the other does a nightly disk snapshot scan that misses anything that started and stopped between scans.
A concrete way to separate the two during a proof of concept: ask for the exact detection mechanism for a running process anomaly, not a vulnerable package. If the honest answer is “we don’t do that, we scan the filesystem for known-bad packages and configurations,” the product is CSPM plus a workload inventory, not CWPP. Ask whether the graph correlation actually changes severity scoring, or whether it is a UI feature that draws lines between findings that keep their original, uncorrelated severity. Ask how identity risk (CIEM) is priced: as included graph nodes or as a separate SKU, because “included” often means read-only IAM policy analysis rather than effective-permission calculation across resource policies, SCPs, and permission boundaries.
None of this means the consolidated products are bad. It means the acronym on the box is not a specification. The specification is the list of detection mechanisms, the agent architecture, and what the correlation engine actually recalculates versus what it just visualizes.
Coverage matrix: what each layer sees
Coverage differs sharply by compute type, and this is usually where a proof of concept surfaces gaps that a data sheet does not show.
| Compute type | CSPM alone | CWPP alone | CNAPP (real, not relabeled) |
|---|---|---|---|
| Virtual machines | Sees network exposure, disk encryption, attached IAM role | Sees running processes, installed packages, runtime behavior with an agent | Correlates exposure plus vulnerable package plus reachable privilege |
| Containers | Sees the orchestrator config: pod security context, exposed services | Sees image layers, base image CVEs, and with a node agent, container escape attempts | Links a vulnerable image to the specific running pods with external ingress |
| Serverless functions | Sees function IAM role, trigger configuration, environment variable exposure | Limited: short-lived execution makes traditional agents impractical; coverage depends on layer instrumentation | Maps function permissions to the data stores they can reach, often the strongest use case for correlation since manual analysis of function fan-out is impractical |
| Infrastructure as Code | Scans Terraform, CloudFormation, or Pulumi before apply; catches drift after apply | No visibility; IaC has no runtime | Ties a pre-deploy IaC finding to the live resource it produced, closing the loop from commit to runtime |
The serverless and IaC rows are worth reading twice. Serverless is the compute type where pure CWPP is weakest, because a function that runs for 400 milliseconds gives a traditional agent almost nothing to observe, which pushes serverless risk assessment back toward configuration and permission analysis. IaC is the compute type where CSPM should ideally happen before deployment rather than after, since a rejected pull request is cheaper than a remediation ticket against a resource that is already serving traffic.
Buying one platform vs assembling layers: integration cost compared
A single consolidated CNAPP reduces the number of agents per host, the number of vendor contracts, and the number of places an analyst has to check during an incident. It also creates a single point of failure in coverage: if the vendor’s container scanning is mediocre, you have no easy way to swap in a better one without replacing the whole platform. The unified risk score is only as good as the weakest input feeding it.
Assembling best-of-breed layers, a separate CSPM, a separate CWPP, and a separate identity tool, gives you the strongest individual capability in each category, but the integration cost is real and recurring, not a one-time setup task. Each tool needs its own agent lifecycle management, its own alert routing into the ticketing system, and its own normalization step before findings can be deduplicated against each other. Two scanners that both flag the same CVE on the same host under slightly different asset identifiers will produce duplicate tickets unless something downstream normalizes asset identity and merges the findings. Platforms that sit across multiple scanner integrations, such as SITEY, exist specifically to absorb that normalization step: matching CVE and asset identity across a CSPM export, a container scanner, and a network scanner into one deduplicated record inside the broader vulnerability lifecycle, rather than leaving three tickets open for the same underlying issue.
The practical break-even point is usually team size measured in FTEs dedicated to cloud security, not company headcount. Below roughly three dedicated FTEs, the ongoing integration tax of running separate best-of-breed tools tends to exceed the coverage benefit, because nobody has time to build and maintain the glue. Above that, a security engineering function can usually absorb the integration cost and capture the depth advantage of specialized tools in the categories that matter most to their specific risk profile, most often container and Kubernetes runtime protection.
Decision guide by team size, cloud maturity, and compliance pressure
Small team, single cloud, early maturity
Start with CSPM coverage against a recognized benchmark (CIS Foundations for the provider in use) and agentless workload scanning for known-vulnerable packages. Skip a full runtime CWPP agent deployment until there is a defined incident response process to consume its alerts; a behavioral detection engine that nobody triages within its detection window is a liability, not a control. Reassess after the first compliance audit, since audit findings are usually the first forcing function for expanded coverage.
Mid-size team, multi-cloud, growing maturity
This is where correlated risk scoring earns its cost, because manually cross-referencing AWS, Azure, and GCP findings by hand does not scale past a handful of accounts. Prioritize identity risk (CIEM) integration at this stage over additional workload detection depth, since multi-cloud environments accumulate cross-account trust relationships and stale service accounts faster than they accumulate new CVEs. Insist on seeing effective permissions, not raw IAM policy JSON, during evaluation.
Regulated environments under compliance pressure
PCI DSS requirement 11.3, ISO 27001 Annex A control A.8.8, SOC 2 CC7.1, and GDPR or KVKK data protection obligations all require continuous vulnerability identification and a documented remediation timeline, not a point-in-time scan. The forcing question for an auditor is rarely “do you have a tool”; it is “show me the finding, the owner, the fix, and the retest that closed it.” That last link, retest and closure evidence tied to a specific control mapping, is frequently the gap between a scanning tool and an audit-ready program. A platform that maps findings to ISO 27001, PCI DSS, SOC 2, GDPR, KVKK, and BDDK control language and keeps the retest evidence attached to the original finding, which is the model SITEY’s compliance mapping stage is built around, removes a meaningful amount of manual audit preparation compared to exporting scanner output into a spreadsheet by hand.
Whichever path fits, the decision should be driven by which of the three questions, configuration, workload, or correlated, currently has the least coverage on your environment, not by which acronym a vendor’s homepage uses this quarter.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.