A Cloud Workload Protection Platform (CWPP) is a security product category that provides visibility and runtime protection for workloads running in cloud infrastructure: virtual machines, containers, Kubernetes pods, and serverless functions. The key word is "runtime." CWPP does not primarily concern itself with whether a cloud account is configured correctly (that is the job of Cloud Security Posture Management, or CSPM). CWPP concerns itself with what is happening inside a workload that is actively executing.
The Gartner definition, which coined the category name, characterizes CWPP as protecting the workload itself regardless of where it runs: on-premises, in a private cloud, in a public cloud, or in hybrid environments. That portability is the point. As organizations have moved from static servers to dynamically scheduled containers and ephemeral serverless functions, the traditional endpoint security model (install an agent, monitor the agent, alert on agent telemetry) has had to evolve. A serverless function may execute for 200 milliseconds and terminate. A container may live for 30 minutes and be replaced by an identical image. CWPP tooling is built around the assumption that workloads are short-lived, dynamic, and may run on infrastructure the organization does not own or control at the hypervisor level.
Understanding CWPP requires understanding what it is not. It is not a firewall. It is not a CASB. It is not CSPM. Each of those categories solves a different layer of the cloud security problem. CWPP is the layer closest to the running code: it watches what processes are executing, what files are being read or written, what network connections are being made, and what memory addresses are being accessed.
---
CWPP platforms deploy using one or more of three approaches: kernel-level agents, eBPF-based instrumentation, or sidecar containers.
Kernel-level agents (traditional) install a software module on the host operating system that intercepts system calls. When a process attempts to open a file, fork a child process, make a network connection, or allocate executable memory, the kernel module can inspect, allow, or block the operation. This approach provides deep visibility but requires installation on every host and adds per-host overhead. It also requires the agent to be updated when the OS kernel is updated, which creates operational complexity in large environments.
eBPF (extended Berkeley Packet Filter) is a newer approach that allows security code to run in the Linux kernel without writing a kernel module. eBPF programs are loaded by a privileged process, verified by the kernel for safety, and executed in a sandboxed environment. This provides similar depth of visibility to kernel agents with lower overhead and greater stability across kernel versions. Sysdig, Falco (the open-source runtime security tool that Sysdig created), and newer versions of CrowdStrike Falcon all use eBPF-based approaches.
Sidecar containers deploy a security container alongside each application container within a Kubernetes pod. The sidecar shares the network namespace and can observe network traffic, but it does not have the same depth of host-level visibility as kernel agents or eBPF. Sidecar approaches are useful for organizations that cannot modify host-level configurations (managed Kubernetes services where the node OS is not customer-controlled).
Unlike CSPM, which evaluates configuration, CWPP performs package-level vulnerability scanning of running workloads. The scanner inventories every OS package, every library, every runtime installed in a container image or VM, maps those packages to the CVE database, and prioritizes findings by exploitability in context.
The key differentiator is contextual prioritization. A vulnerable version of OpenSSL in a container that is not network-accessible and not executing as root is a different risk than the same vulnerable OpenSSL in a container that is exposed to the internet and processing untrusted input. CWPP tools like Wiz and Aqua Security apply runtime context to CVE scores, producing a smaller set of truly critical findings rather than thousands of unfiltered CVEs.
Container image scanning at build time (in CI/CD pipelines) is a complement to runtime scanning, not a replacement. Images that pass build-time scans can have vulnerabilities introduced through package manager updates, configuration changes made after deployment, or zero-days disclosed after the image was built. Runtime scanning catches what build-time scanning misses.
Runtime behavioral protection detects anomalous activity inside a running workload. The baseline model is: this workload, running this container image, normally makes these system calls, accesses these files, communicates with these IP addresses. Deviations from that baseline are anomalies worth investigating.
Common anomaly categories include: process execution (a web server process should not be spawning shell processes; if it does, that is likely command injection), file access (a Node.js application should not be reading /etc/shadow; if it does, that is likely credential theft), network connections (a database container should not be making outbound connections to external IP addresses; if it does, that is likely data exfiltration), and privilege escalation (a process running as a normal user should not be gaining root privileges at runtime).
Behavioral rules can be signature-based (block any process that matches this known-malicious command pattern) or ML-based (flag any behavior that deviates significantly from the learned baseline for this workload). Most enterprise CWPP platforms use both in combination.
File Integrity Monitoring (FIM) tracks changes to critical files and directories on running workloads. For VMs, this means monitoring OS binaries, configuration files, and application binaries. For containers, this means monitoring changes to the container's writeable layer (since the base image should be immutable).
FIM is required by compliance frameworks including PCI DSS (Requirement 11.5: detect unauthorized modification of critical system files) and by CIS Benchmarks for Linux servers. CWPP platforms provide FIM as a built-in capability, with alerting on any modification to a monitored path and audit logs suitable for compliance reporting.
CWPP platforms can enforce network micro-segmentation at the workload level by defining policy rules that specify which containers or processes are allowed to communicate with each other. In a Kubernetes environment, this is complementary to Kubernetes Network Policies, which operate at the IP and port level. CWPP-level segmentation can operate at the process level: only allow the billing-service process to make outbound connections to port 5432 on the database-service; block all other outbound connections from that process.
Tools like Aqua Security and Illumio provide workload-level micro-segmentation that is independent of the underlying network infrastructure, making it applicable in multi-cloud environments where network-level segmentation policies vary by provider.
Memory-based attacks (heap spray, buffer overflow exploitation, return-oriented programming) are difficult to detect without visibility into process memory at runtime. CWPP platforms with memory protection capabilities use techniques like canary values, page permission enforcement, and control flow integrity checks to detect exploitation of memory vulnerabilities in running processes.
This capability is most relevant in environments running legacy applications with known memory safety issues, or in environments where zero-day vulnerability exploitation is a credible threat model (financial services, defense industrial base, healthcare).
---
The practical consequence of having CSPM without CWPP is knowing your cloud is configured correctly while being blind to what is happening inside it. Configuration correctness at rest does not guarantee security at runtime.
Consider a realistic attack scenario. An attacker finds a dependency confusion vulnerability in a Node.js application deployed in a Kubernetes cluster. The cluster's CSPM posture is clean: no public S3 buckets, MFA is enforced, security groups are tight. But the malicious package executes at runtime, establishes a reverse shell, and begins lateral movement. CSPM sees nothing. The CWPP would have flagged the anomalous process execution (the Node.js process spawning a shell), the outbound connection to an unexpected IP address, and the attempted file reads targeting credential files. Without CWPP, the first indication of compromise might be the attacker's ransom note.
The container-specific problem is image drift. Teams build a container image at a point in time, pass it through security scanning, mark it clean, and deploy it. But containers often run for days or weeks, and the runtime environment changes: environment variables are injected at runtime, mounted volumes bring in data and potentially code, and init scripts can pull external content. CWPP is the control that monitors what actually runs at runtime, not what was baked into the image at build time.
Serverless security deserves specific attention because the attack surface is different. In serverless functions (AWS Lambda, Azure Functions, GCP Cloud Functions), there is no persistent OS to monitor and no network perimeter to defend in the traditional sense. CWPP vendors have adapted by providing function-level behavioral monitoring: what does this function normally invoke? What environment variables does it read? What external services does it call? Deviations from that behavioral profile are alerts.
For CISOs, the business case for CWPP is fastest-to-value when the environment has high container churn (Kubernetes at scale), sensitive data processed in cloud workloads, or compliance requirements for FIM or runtime monitoring. For boards, the framing is simpler: CWPP is the control that detects active attacks on cloud infrastructure, not just configuration mistakes.
---
Kubernetes Integration: CWPP platforms integrate with Kubernetes at multiple layers. Admission controllers allow the CWPP to reject deployments that violate security policy (blocking an image from an untrusted registry, or blocking a pod that requests privileged mode). DaemonSets deploy the CWPP agent to every node automatically. Namespace-level policies allow different security profiles for different workloads (stricter policy for production namespaces, looser policy for dev/test).
Image Vulnerability Scoring: Most CWPP platforms use the Common Vulnerability Scoring System (CVSS) as a base score, then adjust for: whether the vulnerable package is actually loaded at runtime (not just installed), whether the workload is internet-facing, whether the workload processes sensitive data, and whether a public exploit exists. Wiz's CVSS Risk Factor adjustments and Aqua's vulnerability intelligence layer both do this contextual re-scoring.
Performance Overhead: The most common objection to CWPP is performance overhead from agent-based monitoring. eBPF-based agents add 1-3% CPU overhead on modern Linux kernels in typical workloads, which is acceptable for most production environments. Kernel module-based agents can add 3-7% overhead in I/O-intensive workloads. Agentless approaches (reading snapshots via cloud APIs) add zero runtime overhead but sacrifice real-time detection; they see the state of a workload at snapshot time, not continuously.
Serverless Coverage Comparison: AWS Lambda coverage varies significantly by vendor. CrowdStrike Falcon Cloud Security wraps Lambda functions using a Lambda extension (a sidecar process that runs within the Lambda execution environment). Aqua Security uses a similar wrapper approach. Sysdig provides Lambda monitoring through CloudTrail-based behavioral analysis rather than in-process instrumentation, which provides lower fidelity but broader coverage.
---
CWPP is a Security Posture and Hygiene (SPH) domain control. The SPH domain's methodology is Autonomous Posture Command (APC), with the tagline: "Your posture adapts. Your hygiene never sleeps."
The APC methodology applied to cloud runtime environments means three things specifically. First, posture assessment is continuous, not periodic. CWPP platforms provide real-time visibility into running workloads, not quarterly vulnerability scans. Second, hygiene is autonomous wherever possible: policy violations (a container running in privileged mode, a process attempting to read a credential file) trigger automated responses rather than queuing for human review. Third, the posture adapts to the workload: a production payment processing container has a stricter behavioral policy than a development environment container; CWPP enforces those different profiles automatically based on workload classification.
The SPH domain governs the health of the security posture at the workload level. A CSPM finding that a storage bucket is misconfigured is an SPH finding. A CWPP alert that a running container is exhibiting anomalous behavior is also an SPH finding. Both feed into the same domain, and both require the same operational discipline: continuous assessment, rapid remediation, and evidence of posture state for audit purposes.
Where CDA's approach differs from conventional thinking is in the framing of "runtime" as a posture problem, not purely a threat detection problem. Most organizations treat CWPP telemetry as threat intelligence feed and route it to the SOC. CDA treats CWPP findings as posture signals: evidence that a workload's current state deviates from its intended state. That framing changes the remediation priority and the ownership model. A misconfigured container policy is not just a SOC ticket; it is a posture gap owned by the team responsible for that workload, measured against the SPH domain scorecard, and tracked until resolved.
The practical implication is that CWPP tooling should be integrated into both the security operations workflow (for threat response) and the engineering workflow (for posture remediation). Engineers need visibility into CWPP findings for their workloads, presented in terms that are actionable at the code and deployment configuration level, not just at the security alert level. Platforms like Sysdig Secure and Wiz do this through developer-facing portals and pull request integrations that surface CWPP findings in the same workflow where code changes happen.
---
---
---