CWPP for Containers and Serverless: A Practitioner's Guide

Kubernetes hardening defines the allowed state. CWPP detects deviations from it in real time. Consider a container that follows every best practice: non-root user, read-only root filesystem, dropped capabilities, restricted seccomp profile, network policy limiting egress. The application running inside it is still a piece of software with a vulnerable dependency. An exploit triggers, the attacker now has the application's privileges within the container, and they begin doing things the developer never authorized: spawning a shell, reading the service account token, calling out to a C2. None of this violates the pod security configuration; the pod is doing exactly what it is configured to allow. CWPP catches this because it monitors behavior against a baseline of expected activity. The category combines three capabilities. First, runtime behavioral monitoring at the syscall level, looking for shell execution, unexpected network connections, sensitive file reads, privilege escalation attempts. Second, drift detection: new binaries written to the filesystem after container startup, configuration changes, namespace modifications. Third, vulnerability and compliance scanning across the supply chain. The mature implementations pair these with response capability, ranging from alerting only to active prevention via syscall denial or pod termination.

Three architectures dominate the runtime monitoring space, each with distinct properties. eBPF-based agents, the approach taken by modern Falco deployments, Cilium Tetragon, and most cloud-native vendors, run probes attached to kernel events without requiring a custom kernel module or sidecar container. Overhead is low, typically 1 to 3 percent CPU at default rulesets, visibility extends across all containers on the host from a single agent per node, and updates do not require workload changes. The constraint is kernel version; production eBPF support requires kernel 4.18 or newer for full functionality, and some advanced features require 5.4 or newer. Sidecar injection, the Istio model extended to security, places a proxy container next to each application container. This works well for network policy enforcement and L7 visibility but does not see syscalls inside the application container, which means it misses most runtime behavioral detections. Use sidecars for service mesh and identity, not as your primary runtime detection layer. Kernel module agents, the older approach still used by some commercial vendors, run as loadable kernel modules with deep visibility but higher overhead, kernel compatibility risk, and vendor lock-in to specific kernel versions. The recommendation for new builds is eBPF, with sidecars layered for service mesh capabilities and kernel modules avoided unless a specific vendor capability requires them.

Falco rules combine a condition expression with output formatting and a priority level. The default ruleset is a starting point, not production-ready; expect to tune extensively. High-value rules to validate first include shell spawned in container, which catches a large fraction of post-exploitation behavior; unexpected network connection from container, particularly egress to non-allowlisted destinations; sensitive file read, covering /etc/shadow, service account tokens, and cloud metadata endpoints; container drift, defined as a new executable written and then executed after the container has started; and privilege escalation attempts via setuid binaries or capability changes. Rule authoring discipline matters. Start the condition with the most selective predicate to short-circuit evaluation; Falco evaluates left to right and a poorly ordered condition can multiply CPU cost. Use lists and macros to keep rules maintainable; redefining the same allowlist in 20 rules creates a tuning nightmare. Test every rule against the Falco event generator before deploying to production; the generator produces synthetic triggers for documented techniques and validates that your rules fire as expected. Tag rules with MITRE ATT&CK techniques in the output for downstream correlation. Treat the rule set as code: source control, code review, CI validation, staged rollout. Rules deployed by ad-hoc edit on a node will diverge and fail silently.

Falco detects; it alerts and surfaces but does not block by default. Tetragon, the Cilium project's runtime security component, adds enforcement. Its TracingPolicy CRD lets you define syscall-level policies that can not only detect but also kill the offending process or return an error to the syscall, effectively preventing the action. This is meaningful because detection time, even at seconds, is often longer than the attacker needs to complete an objective such as exfiltrating a token or writing a backdoor. Tetragon hooks at the kernel level via eBPF, with policies expressed declaratively and applied per-namespace or cluster-wide. Use cases that benefit from prevention rather than detection include blocking shell execution in production application containers, blocking writes to the container filesystem outside declared mount paths, blocking outbound connections to non-allowlisted destinations, and blocking specific syscalls like ptrace or process_vm_readv that have no legitimate use in most application containers. Prevention introduces operational risk; a poorly scoped policy can break legitimate workloads. Roll out in detection-only mode first, observe for at least two weeks, then enable enforcement for specific policies one at a time with explicit rollback procedures. The combination of Falco for broad detection and Tetragon for targeted prevention is increasingly the standard pattern.

Serverless functions are not containers in the runtime monitoring sense; you cannot install an agent. The protection model shifts to configuration controls, identity, and behavioral analytics on the platform's own telemetry. For AWS Lambda, the baseline includes function URLs with IAM auth or API Gateway in front, never public, VPC integration where the function needs access to private resources, execution roles scoped to the absolute minimum required actions, environment variables encrypted with KMS keys not the default AWS-owned key, and code signing via AWS Signer to prevent deployment of unsigned code. Behavioral monitoring relies on CloudTrail for API activity, GuardDuty for anomaly detection on function behavior, and Lambda extensions for in-runtime instrumentation if needed. Look for unusual invocation patterns, unexpected egress to public IPs, and execution role privilege expansion as the primary signals. For Google Cloud Run, binary authorization is the equivalent control to enforce that only signed and attested images deploy, VPC Service Controls constrain the network perimeter, and Cloud Audit Logs provide the equivalent of CloudTrail. The serverless gap relative to container CWPP is real; you have less runtime visibility and must compensate with stricter configuration and identity controls. Treat the function as a least-privilege component, not a flexible compute primitive, and most of the runtime risk reduces.

Image vulnerability scanning is a solved capability and an unsolved operational problem. Trivy, Grype, and commercial alternatives all produce accurate CVE inventories from container images; the question is what to do with the results. The strategic placement of scans matters. Scan in the developer's local environment via pre-commit or IDE plugins for fast feedback, in the CI pipeline as a gate before image push with policy enforcement on critical and high severity findings, in the registry continuously as new CVEs are disclosed against existing images, and at runtime via the CWPP agent to correlate detected behavior with known vulnerable packages. The fatigue problem is real: a typical base image will produce hundreds of findings, most of which are not exploitable in the application's actual usage. Prioritize by exploitability, not severity alone. The KEV catalog from CISA, the EPSS scoring system, and reachability analysis tools that determine whether vulnerable code paths are actually invoked all reduce the noise floor dramatically. A finding for a vulnerable function that the application never calls is informational at best; a finding for an internet-facing service with a published exploit is an incident. Integrate this prioritization into the scanner output so engineers see fix-this-first rather than a list of 400 CVEs sorted alphabetically.