CWPP vs CSPM: Workload Protection or Posture First?

Cloud teams without a CNAPP usually have budget for one cloud security tool first, and buying the wrong one leaves either a public storage bucket or a crypto-miner running in a container unseen for months. Cloud workload protection platforms (CWPP) and cloud security posture management (CSPM) look similar on a product sheet, but they defend different things: CWPP protects what runs inside virtual machines, containers and functions, while CSPM checks how the cloud control plane around them is configured. This guide compares the two by threat model, architecture, failure modes and controls, then gives a buying sequence, the agent versus agentless trade-off for each, and a worked scenario. It is for cloud security leads, architects and buyers in organisations that are building their first cloud security stack or deciding whether to consolidate. For the converged platform view, see the CNAPP Guide; for CSPM operations in depth, see the Cloud Security Posture Management (CSPM) Guide.

Key takeaways

The short answer is inside versus around. CWPP watches and hardens the workload (packages, processes, files, network connections); CSPM checks the cloud resources and settings around it (storage policies, security groups, IAM, logging).
Most cloud breaches start around the workload. Exposed storage, open management ports, leaked keys and over-permissioned roles are posture problems, which is why CSPM is usually the right first purchase for a cloud-native estate.
Workload-heavy estates change the order. Large fleets of long-lived VMs, internet-facing containers or regulated hosts that need malware protection and file integrity monitoring can justify CWPP first.
Agentless is breadth, agents are depth. Snapshot and API scanning covers every account in days but is point-in-time; runtime sensors see live attacks but only where deployed.
Consolidation is a later decision. Providers and vendors now bundle both into CNAPP offerings; buy for the risk you have first and check that the second capability can join the same inventory later.

What each category covers

CSPM: continuously reads cloud provider APIs and configuration records, compares resources against policies (provider best practice, CIS Benchmarks, PCI DSS, internal rules) and raises findings for drift such as a public bucket, an unencrypted database, a security group open to 0.0.0.0/0 on port 22 or 3389, a user-managed service account key or missing audit logging. It never needs to log in to a workload.
CWPP: protects the compute itself across VMs, containers, Kubernetes nodes and serverless functions. Capabilities typically include vulnerability assessment of installed packages, malware scanning, file integrity monitoring, application allowlisting, host and container hardening checks, and runtime threat detection from process, file and network events.
The overlap: both now claim "vulnerability management". CSPM-led platforms often add agentless workload scanning; CWPP-led platforms often add some configuration checks. The difference that remains is runtime: posture tools see what is configured and installed, workload tools see what is executing.

Side-by-side comparison

Dimension	CWPP	CSPM
Object protected	VMs, containers, Kubernetes nodes, functions	Cloud accounts, subscriptions, projects and their resources
Data source	Host or node sensor, disk snapshots, image registries, hypervisor introspection	Provider control plane APIs and configuration recorders
Question answered	Is this workload vulnerable, compromised or behaving abnormally?	Is this cloud resource configured safely and compliantly?
Time model	Continuous with agents; daily or similar with snapshots	Near real time on change events plus scheduled full scans
Typical findings	Exploitable package, web shell, reverse shell, crypto-miner process, unexpected binary, modified system file	Public storage, open management ports, disabled logging, unencrypted volumes, wildcard IAM policies
Response actions	Kill process, quarantine file, isolate host or pod, block by allowlist	Ticket, auto-remediate setting, preventive guardrail in policy or pipeline
Deployment effort	Agent or sensor rollout, kernel compatibility, change windows	Read-only cross-account role per account or organisation
Main owner	Platform, server and container operations teams	Cloud platform and governance teams
Compliance evidence	Malware protection, integrity monitoring, host hardening	Benchmark and framework conformance across accounts

Threat model: what each defends against

The clearest way to choose is to list the attacks you most need to stop and see which tool sees them first. ATT&CK references below are from ATT&CK v20.

Threat	CSPM view	CWPP view
Public storage exposing data, then T1530 Data from Cloud Storage	Primary: flags the public policy or ACL before access	Not visible: no workload involved
Exploit of an internet-facing application, T1190 Exploit Public-Facing Application	Partial: shows the exposure path and open ports	Primary: finds the vulnerable package and detects post-exploit behaviour
Web shell persistence, T1505.003 Web Shell	Not visible	Primary: new file in web root, unexpected child process
Credential theft from metadata, T1552.005 Cloud Instance Metadata API	Primary for prevention: flags token-optional metadata settings and over-broad instance roles	Detection: unexpected process calling the metadata endpoint
Container escape, T1611 Escape to Host	Partial: privileged pod or host path settings if Kubernetes posture is in scope	Primary: syscall and namespace anomalies at runtime
Crypto-mining, T1496 Resource Hijacking	Indirect: new resources in unusual regions if inventory is watched	Primary: miner process, pool connections, CPU anomalies
Backdoored image, T1525 Implant Internal Image	Not visible beyond registry settings	Primary: image scanning and drift from image at runtime
Stolen cloud keys, T1078.004 Cloud Accounts	Indirect: old or unused keys, excessive permissions	Not visible: activity happens in the control plane

The last row matters: neither category detects misuse of valid cloud credentials well. That job belongs to cloud detection and response on audit logs, covered in the Cloud Detection and Response Guide.

Architecture in words

CSPM

The CSPM service is granted a read-only role in each account, or one organisation-level role that can enumerate member accounts. It pulls inventory from provider APIs and, where available, subscribes to configuration change events. A policy engine evaluates each resource against rules and writes findings to a console, a findings bus or a ticketing system. Mature deployments add a preventive layer: the same rules run against infrastructure as code in pipelines and as organisation policies, so drift is blocked rather than reported. See the Checkov and IaC Scanners Guide.

CWPP

CWPP has up to three collection paths. Agentless scanning snapshots disks or reads registries and analyses them out of band for packages, malware and secrets at rest. A host or node sensor, today often eBPF-based on Linux, streams process, file and network events and can block actions. Hypervisor-level introspection reads memory from outside the guest. Findings flow to the same kind of console, but the response actions reach into the workload. See the Container Runtime Security Guide for sensor design.

How the three major providers package it

Providers are listed alphabetically; the order is not a ranking. Plan and tier availability changes, so confirm against each provider's current documentation.

Provider	Posture service and capability	Workload service and capability
Amazon Web Services	AWS Security Hub CSPM: runs control checks against standards including AWS Foundational Security Best Practices and the CIS AWS Foundations Benchmark, using AWS Config service-linked rules, with findings in the AWS Security Finding Format	Amazon Inspector EC2 scanning in agent-based or hybrid scan mode (SSM Agent continuous scanning plus EBS snapshot agentless scanning every 24 hours); GuardDuty Runtime Monitoring security agent for EKS, ECS on Fargate and EC2
Google Cloud	Security Command Center Security Health Analytics: batch, real-time and mixed-mode detectors for misconfigurations such as public bucket ACLs, open SSH or RDP firewall rules and user-managed service account keys	Security Command Center VM Threat Detection: hypervisor-level memory scanning and short-lived disk clones to detect crypto-mining, Linux kernel-mode rootkits and malware without a guest agent
Microsoft Azure	Defender for Cloud Foundational CSPM (secure score, security recommendations) and the Defender CSPM plan (attack path analysis, cloud security explorer, agentless discovery for Kubernetes, sensitive data scanning)	Defender for Servers Plan 1 (Defender for Endpoint EDR integration) and Plan 2 (adds agentless scanning for vulnerabilities, secrets and malware, file integrity monitoring and just-in-time VM access)

Availability notes: AWS Security Hub CSPM needs AWS Config recording enabled and works per Region, so enable it in every Region in use. Google Cloud Security Command Center capabilities vary by tier, and the documentation describes VM Threat Detection scope by machine type and disk encryption. Microsoft Defender for Servers features are split between Plan 1 and Plan 2, and Defender CSPM is a separate paid plan from Foundational CSPM. See the AWS Security Guide, Google Cloud Security Guide and Microsoft Azure Security Guide.

Agent versus agentless, per category

The CNAPP Guide compares agent and agentless scanning in general. The buying question is narrower: which mode each category needs.

CSPM is agentless by nature. It only needs API access. The decision is scope (organisation-wide role versus per-account onboarding) and whether real-time change events are supported for the services you use.
CWPP vulnerability and malware scanning can be agentless. Snapshot scanning finds installed packages, malware and secrets at rest with no deployment, which suits large estates and hosts teams will not let you touch. Read the eligibility rules: Amazon Inspector agentless scanning, for example, documents file system, volume count and volume size limits.
CWPP runtime protection needs a sensor. Detecting a reverse shell, blocking a process or catching a container escape requires a sensor in the kernel or the hypervisor. Agentless snapshots taken every 24 hours cannot see an attack that starts and finishes between scans.
Serverless and managed containers shift the boundary. On function platforms and serverless container services you cannot install a host agent; protection comes from provider-managed sensors, sidecars or image and code scanning before deployment. See Containers vs Serverless Security.

Rule of thumb: agentless everywhere for inventory and vulnerabilities, sensors on the internet-facing, high-value and long-lived workloads where live detection and blocking pay for the operational cost.

Failure modes

When CSPM is the only tool

Clean posture, compromised host: every setting passes while a web shell sits on a VM. Posture tools do not watch processes.
Alert flood without owners: thousands of findings across accounts with no tagging or ownership model, so nothing is fixed. Prioritise by exposure and data sensitivity.
Detect without prevent: the same misconfiguration is recreated weekly by a pipeline because the rule never moved into infrastructure as code or organisation policy.

When CWPP is the only tool

Protected hosts, public data: a hardened fleet sits beside a storage bucket shared publicly by a console change no workload tool can see.
Agent coverage gaps: auto-scaling groups, new accounts and short-lived nodes launch without the sensor, and nobody measures coverage against inventory.
Kernel and performance friction: sensor upgrades lag behind kernel updates, teams disable enforcement to restore performance, and the tool quietly becomes detect-only.

Decision criteria: which to buy first

Your estate looks like	Buy first	Why	Then add
Cloud-native, many accounts, mostly managed services and short-lived compute	CSPM	Most exposure is in configuration and identity; little long-lived compute to protect	Agentless workload scanning, then sensors on exposed services
Lift-and-shift VM estate, few accounts, many long-lived servers	CWPP	Servers carry the vulnerabilities and malware risk; account count is small enough for native posture checks	CSPM when account count or services grow
Kubernetes-heavy platform with internet-facing services	CWPP with runtime sensors	Container escape, image drift and miners need runtime visibility	CSPM with Kubernetes posture
Regulated hosts requiring malware protection and file integrity monitoring	CWPP	Those controls are workload controls by definition	CSPM for benchmark evidence
Single cloud, small team, limited budget	Provider native posture and threat detection	Already integrated and often partly included; tune before buying more	A third-party tool when you go multi-cloud or outgrow native reporting
Multi-cloud with central security team	CSPM across all clouds	One policy set and inventory across providers is the first gain	CWPP or a CNAPP with runtime

Small organisations: enable the native posture and workload services in every account and Region before buying anything, and give findings an owner. Large organisations: buy for the first gap, but require the second capability to share inventory, tagging and ticketing so a later move to a CNAPP does not mean re-onboarding. The CNAPP Buyer's Guide lists evaluation criteria for the converged route.

Decision checklist

Count accounts, subscriptions and projects, and long-lived VMs, container nodes and functions. Whichever is larger points to the first category.
List your last three cloud incidents or near misses and map each to the threat table above.
Check what your providers already include and what is switched off.
Decide where you can deploy sensors and where you cannot (managed services, change-averse teams, third-party hosts).
Agree who owns posture findings and who owns workload alerts before buying either.
Run a two-week proof of value in one production account, measuring true positives and time to fix.

Worked scenario: one estate, two first purchases

A retailer runs 40 cloud accounts. Customer services run on a managed Kubernetes cluster, payments on 60 long-lived VMs, and analytics on managed storage and serverless functions. The security team can fund one tool this year.

If it buys CSPM first, the first week surfaces a storage bucket shared publicly for a supplier test, security groups open to SSH from the internet in four accounts, and instance roles allowed to read every bucket. These are fixed and the rules move into the pipeline. The payment VMs, however, still have no malware protection or integrity monitoring, which the card payment audit expects, and no one would see a miner on a Kubernetes node.

If it buys CWPP first, sensors on the cluster and payment VMs give runtime detection and the audit evidence, but the public bucket and open SSH remain until someone looks in the console. The Capital One breach is the reminder of what that gap costs: a request forgery weakness on a firewall instance yielded metadata credentials for a role that could read many storage buckets, and the bulk reads went unnoticed for about four months. Prevention there was a posture problem (role scope and metadata settings) as much as a workload one.

The sensible order for this estate is native posture services in every account immediately (low cost), a third-party or premium CSPM across all 40 accounts as the purchase, agentless workload scanning from the same platform for package vulnerabilities, and sensors on the cluster and payment VMs in the next budget cycle. The Amazon AWS Crypto-Mining Campaign 2025 shows why both halves matter eventually: miners ran on auto scaling groups and Fargate tasks launched with stolen credentials, a mix of control plane and workload activity.

Where identity fits

Both categories depend on privileged non-human identities. A CSPM's cross-account role can read every resource configuration, and agentless scanning needs permission to snapshot disks and use encryption keys. CWPP agents run with local root or SYSTEM and often hold registration tokens. Treat these as privileged NHIs: scope roles to read-only plus snapshot permissions, monitor their use in audit logs and review them like any other integration identity. See Securing the CNAPP and CSPM platform itself and Securing the container runtime security and CWPP itself.

Detection and measurement

Posture coverage: percentage of accounts, subscriptions and projects connected to CSPM, against the provider's organisation inventory. Target 100 percent.
Workload coverage: percentage of running VMs, nodes and functions with agentless scanning, and separately with a runtime sensor, against inventory. Report gaps by owner.
Critical exposure age: median days open for public storage, internet-open management ports and wildcard IAM findings.
Exploitable vulnerabilities on exposed workloads: count of KEV-listed or critical package findings on internet-facing hosts and containers, trended weekly.
Runtime alert quality: share of runtime alerts confirmed as true positives, and mean time from alert to containment.
Recurrence: misconfigurations reappearing after remediation, a signal that rules have not moved into pipelines or guardrails.

Framework mapping

Framework	CSPM	CWPP
NIST SP 800-53 Rev. 5	CM-2 Baseline Configuration; CM-6 Configuration Settings; CA-7 Continuous Monitoring; AC-6 Least Privilege	RA-5 Vulnerability Monitoring and Scanning; SI-3 Malicious Code Protection; SI-4 System Monitoring; SI-7 Software, Firmware, and Information Integrity; CM-7 Least Functionality
NIST CSF 2.0	PR.PS-01 configuration management practices; ID.AM-08 lifecycle management	ID.RA-01 vulnerability identification; DE.CM-09 monitoring of computing hardware, software and runtime environments
CIS Controls v8.1	Control 4 Secure Configuration of Enterprise Assets and Software	Control 7 Continuous Vulnerability Management; Control 10 Malware Defenses
ISO/IEC 27001:2022 Annex A	8.9 Configuration management	8.7 Protection against malware; 8.8 Management of technical vulnerabilities; 8.16 Monitoring activities
NIST SP 800-190	Orchestrator and registry configuration	Image, container and host risks and countermeasures

Practitioner checklist

Inventory accounts and workloads first; the ratio points to which category to buy first.
Switch on native posture and workload services in every account and Region before any purchase.
Map your recent incidents to the threat table and buy for the uncovered rows.
Run agentless workload scanning everywhere, and place runtime sensors on internet-facing, high-value and long-lived workloads.
Move the top posture rules into infrastructure as code checks and organisation policies so drift is blocked.
Measure sensor coverage against live inventory weekly, including auto-scaled and short-lived compute.
Scope and monitor the tool's own roles, snapshot permissions and agent tokens as privileged non-human identities.
Require shared inventory, tagging and ticketing between the two capabilities so later consolidation into a CNAPP is a configuration change.

CWPP vs CSPM: Which to Buy First and Why