Safeguard
Application Security•

What does a cloud workload protection platform (CWPP) actually cover?

A CWPP secures the workloads you run in the cloud: VMs, containers and functions. See the five jobs it does, what it skips and how to check coverage.

Safeguard Security Team
4 min read

A cloud workload protection platform, or CWPP, secures the things that run in your cloud: virtual machines, containers and serverless functions. It finds vulnerabilities and misconfigurations in those workloads, hardens them, watches them while they run and limits what they can reach. It does not secure your cloud account settings.

What counts as a workload?

NIST's definition of cloud computing describes a shared pool of configurable resources provisioned on demand. A workload is whatever you place on that pool and run: a VM, a container, a function, sometimes a managed database instance. Workloads are short lived, copied often and spread across providers, which is why host by host agents and quarterly scans struggle.

What are the five jobs?

  1. Know what is running. Discover workloads and what is inside them: operating system, packages, libraries, open ports.
  2. Find weaknesses before and after deploy. Scan images in the registry and running instances for known vulnerabilities and unsafe configuration.
  3. Harden. Remove unused packages, drop privileges, use read only file systems, restrict system calls.
  4. Watch at runtime. Look for unexpected processes, file changes, outbound connections and privilege changes.
  5. Limit blast radius. Segment workloads so a compromised one cannot talk to everything.

NIST SP 800-190, the container security guide, covers many of these concerns for containers specifically: image vulnerabilities, registry risks, orchestrator weaknesses, runtime behavior and host OS risks.

How is it different from cloud posture tools?

Think of two layers. Posture tooling asks whether the cloud account is configured safely: public storage buckets, open security groups, overly broad roles. Workload protection asks whether the software running inside the account is safe and behaving. A public bucket is a posture finding. A container running a vulnerable library that is being exploited is a workload finding. You usually want both, and the findings feed each other.

Where does it fall short?

  • Serverless. There is no host to install an agent on, so protection moves to code scanning, permission review and the function's event inputs. The OWASP Serverless Top 10 notes that even without a server to manage, the code still executes and can still be attacked at the application level.
  • Noise. A long list of vulnerabilities in a base image is hard to act on. Reachability, meaning whether the vulnerable code is ever called, is what sorts fix now from fix later.
  • Agent overhead. Runtime agents consume CPU and need updating. Check the cost on latency sensitive services.
  • Supply chain. Runtime protection sees a malicious dependency only when it misbehaves. Catching it at build time is cheaper.

Constructed example: a team runs 200 containers from a shared base image. A scan flags 40 vulnerable packages. Only 3 are loaded by the application, and one of those sits on a request path that handles public input. The team patches that one first and schedules the rest with the next base image rebuild.

Safeguard does not sell a workload protection platform. What it does cover on the build side is dependency scanning, SBOMs and reachability analysis, which shrink the list a runtime tool then has to guard.

How to check or apply this

  1. Count your workload types and where each runs. List the ones with no agent or scan coverage.
  2. Scan images at build, again in the registry and again on a schedule for running workloads.
  3. Decide per type what protection fits: agent for VMs, admission control and runtime sensors for containers, code and permission review for functions.
  4. Give each workload the least privilege it needs, including its cloud role.
  5. Test detection with a harmless simulated event, such as an unexpected shell in a test container, and confirm someone is alerted.
  6. Track time from a vulnerable image being published to being replaced.

Quick check

Do I need a CWPP if I only use serverless?

You still need to protect function code, dependencies and permissions, but the host agent part of a classic CWPP does not apply. Focus on code scanning and tight roles.

Is CWPP the same as CNAPP?

No. CNAPP is a broader category that usually combines workload protection with posture management and other checks. CWPP is one component.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.