CWPP is complementary to CSPM, not a substitute. CSPM assesses how the environment is configured (IAM policies, security groups, encryption); CWPP assesses what runs inside and how it behaves. A serious cloud programme combines both in a single governance model.
What CWPP is
CWPP (Cloud Workload Protection Platform) is the category of platforms that protect the workloads deployed in cloud and on-premise environments: virtual machines, containers, Kubernetes clusters, serverless functions and, in some implementations, bare-metal instances. Unlike CSPM, which assesses the cloud provider's configuration, CWPP focuses on what runs inside each workload: operating system and dependency vulnerabilities, runtime anomalous behaviour, file integrity, process telemetry and, in many platforms, automated response to threats detected on the host or container.
Why it matters
As soon as an organisation moves workloads to the cloud, it discovers that the shared responsibility model leaves it in charge of everything that runs inside the machine or container. The provider covers the physical infrastructure and the control plane; the security of the operating system, libraries, running processes and incident response remains the customer's responsibility. CWPP exists to cover that plane. Without it, a vulnerability exploited in a base container image or a malicious process launched inside a machine can remain invisible to the provider's console and to CSPM. For frameworks like NIS2, DORA or ENS that require control over the asset lifecycle, CWPP is one of the most direct technical controls available.
Key points
Modern CWPP platforms are agentless where the technology allows (reading snapshots, hypervisor-level instrumentation) and keep lightweight agents for cases where runtime visibility is needed (processes, connections, file reads). The hybrid model is the norm.
For containers, CWPP's strength is covering the whole lifecycle: image analysis in the registry, validation in CI/CD before deployment, runtime observation in the cluster and automated blocking of anomalous behaviour at runtime.
Runtime detection usually relies on expected behaviour profiles and rules in the style of MITRE ATT&CK adapted to cloud (containers, Kubernetes, serverless). A container that suddenly opens a port it never had in its profile or runs an unexpected binary triggers an alert or is contained.
CWPP works well when the base image is built with discipline: few dependencies, no unnecessary binaries, no hardcoded credentials and a published SBOM. The cleaner the image, the less noise the platform generates and the more useful each alert becomes.
Integration with the SIEM and the SOC is key to prevent CWPP becoming yet another console. CWPP telemetry must feed the central detection and response flow, not stay isolated in its own dashboard.
Example: CWPP in a cloud architecture with Kubernetes and serverless
A company with a SaaS product deployed on Kubernetes and several serverless functions in public cloud rolls out a CWPP platform. In the first week the tool analyses every image in use and detects that three base images contain critical CVEs with KEV entries and proposes updated versions. It also configures a gatekeeper in CI/CD that blocks deployment of any image with critical vulnerabilities or that imports binaries outside the expected profile.
Once in runtime, the lightweight agent on each cluster node establishes behaviour profiles for the main pods. Three weeks later it detects that a container in the payments platform has launched a crypto-mining process: the behaviour deviates from the expected profile (sudden CPU consumption, connections to IPs known as mining pool) and is automatically contained while the SOC is notified. The subsequent investigation confirms that the image had been compromised through a transitive dependency infected in the supply chain. The incident is closed before any customer impact and is published as an internal case to reinforce SBOM discipline and image validation.
Common mistakes
- Thinking that CSPM covers the whole cloud. CSPM assesses provider configuration; what happens inside the machine or container falls outside its radar. Without CWPP, a vulnerability exploited in a base image remains invisible.
- Deploying CWPP without prior discipline in images and SBOM. If base images are huge, without SBOM published and with unnecessary binaries, the platform generates so much noise the team ends up ignoring it.
- Skipping the gatekeeper in CI/CD. Most of CWPP's value in containers lies in preventing a vulnerable image from reaching production, not in chasing it afterwards. Without automated blocking in the pipeline, the control becomes reactive.
- Treating CWPP as an isolated tool. Telemetry must feed the SIEM, response playbooks and SOC dashboard. If it lives in its own dashboard, alerts get lost and investigations duplicated.
- Not reviewing behaviour profiles at the right cadence. Workloads change: new versions, new endpoints, new integrations. A static profile generates chronic false positives and ends up disabled.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between CWPP and CSPM?
CSPM assesses how the cloud environment is configured: IAM policies, security groups, encryption, logging. CWPP assesses what runs inside workloads and how they behave: operating system and dependency vulnerabilities, file integrity, anomalous processes, unexpected connections. They are complementary disciplines and a mature cloud programme uses them together.
Does CWPP work on-premise too?
Yes. Although the category started focused on cloud, most modern platforms also cover virtual machines and containers in on-premise datacenters. It is common to use the same platform for hybrid environments and consolidate visibility into a single dashboard.
Does CWPP replace traditional EDR?
On user endpoints, no. On servers and cloud workloads, the functions overlap partially: many modern CWPP platforms include behaviour detection, integrity and automated response at the workload level. The line between CWPP and server EDR is blurring; what matters is avoiding coverage gaps and overlapping agents that affect performance.
What precaution should be taken with CWPP agents in containers?
Agents have a performance impact and, badly tuned, can introduce latency or extra resource consumption. It is best to deploy first in test environments with realistic load, measure the impact and tune the profiles. In serverless, the agentless mode is usually preferred because the very short lifecycle makes a persistent agent impractical.