What is CWPP (Cloud Workload Protection Platform)?

CWPP at a glance

The gap CWPP fills

CSPM looks at a virtual machine and sees a resource: its security group, its IAM role, whether its volume is encrypted. All of that can be correct while the machine itself is indefensible. It may be running a three-year-old kernel, an unpatched OpenSSL, an SSH key baked into the base image, and a service listening on a port nobody documented.

Configuration is the door. The workload is the room. CWPP is the category that opens the room.

What counts as a workload

CWPP is deliberately broad, because "compute" stopped meaning "server" a long time ago:

• Virtual machines: EC2, Azure VMs, Compute Engine, OCI Compute
• Containers: images in registries and containers running in EKS, AKS, GKE, OKE, ACK or self-managed Kubernetes
• Kubernetes nodes: the hosts underneath the pods, with their own OS, kubelet and packages
• Serverless: Lambda, Azure Functions, Cloud Functions, including runtime versions and execution roles
• Managed hosts: anything the provider runs on your behalf where you still own the configuration inside

A tool that covers containers but not serverless is not a CWPP; it is container security.

What CWPP checks

How CWPP works

1. Discover every workload through the cloud provider APIs, so nothing depends on someone remembering to register it.
2. Assess what is inside, either by agent, by scanning a snapshot of the disk, or by scanning images in the registry and pipeline.
3. Harden against OS and container benchmarks.
4. Prioritise with context: a critical CVE on an internet-facing VM with an admin role matters more than the same CVE on an isolated batch host.
5. Protect at runtime where needed. This means detecting suspicious processes and connections, and in agent-based products sometimes blocking them.
6. Shift left by scanning images before deploy, so fewer vulnerable workloads reach production.

CSPM vs CWPP

Do you need both? Yes, for most cloud estates. CSPM without CWPP misses the vulnerable software inside a well-configured VM; CWPP without CSPM misses the public storage bucket no workload touches. The useful question is whether their findings are correlated. An exploitable CVE (CWPP) on a VM that is internet-facing (CSPM) with an over-privileged role (CIEM) is one priority, not three unrelated tickets. That correlation is what a CNAPP is for.

CWPP vs CNAPP

CWPP is a component; CNAPP is the platform that contains it. A CNAPP combines CSPM, CWPP, CIEM, KSPM and usually data security and attack path analysis on one data model, so findings from each can be read together. Buying CWPP as a separate product is still common where a team already has strong posture tooling, but the findings then live in a second console. See What is CNAPP?.

CWPP vs EDR

EDR (endpoint detection and response) was built for long-lived endpoints and servers, with an agent watching processes on each machine. CWPP was built for cloud workloads, many of which are short-lived containers or serverless functions where an endpoint agent does not fit, and it adds cloud context, such as which role the workload runs as and whether it is exposed. On long-lived cloud VMs the two overlap, and many organisations run both.

CWPP vs KSPM and container security

• KSPM checks how Kubernetes clusters are configured: RBAC, pod security, network policy and admission control.
• Container security is the container-specific slice: images, registries, Kubernetes configuration and admission policy.
• CWPP is the umbrella for what runs inside every compute form factor, including the VMs and serverless functions that are not containers at all.

Agent vs agentless

This is the decision that most often determines whether a CWPP rollout succeeds.

Agent-based installs software on every workload. It gives continuous runtime telemetry (process execution, syscalls, live network connections) that snapshot scanning cannot replicate. The cost is real: a package to distribute, a version to maintain, a rollout plan, an exception list for machines that break, and a recurring negotiation with the platform team. Coverage commonly stalls short of every workload, and the uncovered remainder is often the legacy estate that most needs scanning.

Agentless takes a point-in-time snapshot of the workload's volume and analyses it out-of-band. Coverage does not depend on rolling software out to each machine, and the scan puts no load on the workload itself. The trade-off is that it is point-in-time: it will not show you a process that spawned and exited between scans, and it cannot block anything.

Many programmes use snapshot scanning as the coverage baseline, add detection from cloud-native audit and flow logs, and reserve agents for the workloads that genuinely need live process telemetry or prevention. More on the trade-off in What is agentless cloud security?

CWPP best practices

1. Inventory first. You cannot protect a workload you have not discovered; drive coverage from the cloud API rather than a list of hosts.
2. Prioritise by exploitability and exposure, not by CVSS score alone.
3. Scan images in the pipeline and the registry, so fixes happen in the build instead of on running containers.
4. Retire end-of-support runtimes: old OS images and Lambda runtimes stop receiving security fixes.
5. Keep secrets off disk and out of environment variables; use the provider's secrets manager.
6. Correlate with posture and identity findings so one exploitable workload is ranked by what it can reach.

How Onam approaches workload protection

Onam evaluates workloads as part of the same platform as its cloud posture, identity and data security checks, across AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud and Kubernetes. In its rule catalogue, 1,508 rule definitions are tagged to the container and Kubernetes domain and 219 to compute workloads. One honest limit: a rule catalogue describes configuration and package risk; it is not by itself a runtime prevention agent.

• How Onam approaches CWPP
• What is KSPM?
• What is CNAPP?