Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / Why Security Teams Are Adopting Cloud Workload Protection Platforms
Transcript
- Lucas: Last month, a regional bank in the Midwest — roughly 30 billion in assets — discovered that one of their containerized payment processing workloads had been cryptomined for nearly six weeks before anyone noticed. Luna: Six weeks? That's not a stealth attack — that's a second tenant in their cloud. Lucas: Exactly. And the alarm didn't come from their endpoint detection tools or their SIEM. It came from the cloud provider's billing anomaly alert — the compute costs had spiked by 40 percent. Luna: So their security stack completely missed a workload being hijacked. That's the kind of failure that's driving interest in cloud workload protection platforms — CWPPs. Lucas: We're going to look at why traditional endpoint protection doesn't translate well to cloud-native environments, what a CWPP actually does differently, and how one financial services firm used it to close a gap that their EDR couldn't touch. Luna: And maybe why the market for these tools is growing at something like 25 percent compound annual growth rate right now. Lucas: Right. Gartner has been tracking this category for years — they actually coined the term back around 2017. But adoption really accelerated once organizations started running production workloads in multi-cloud architectures. Luna: Because an agent on a server doesn't help you if that server is ephemeral or if the workload is a serverless function. Lucas: That's the core problem. Traditional endpoint detection and response — EDR — is built for persistent operating systems with file systems and long-lived processes. But cloud workloads can be containers that exist for 90 seconds, or serverless functions that spin up, execute, and disappear in milliseconds. Luna: No place to install an agent, no persistent disk to scan. So you need a different approach. Lucas: A CWPP typically combines several capabilities: vulnerability scanning of container images before deployment, runtime protection that monitors system calls and network connections, and often file integrity monitoring. But the key shift is that it's workload-centric, not infrastructure-centric. Luna: Meaning it follows the workload regardless of where it runs — public cloud, private cloud, on-prem, edge. Lucas: Exactly. And there's a distinction that often confuses buyers: CWPP versus cloud security posture management, CSPM. CSPM looks at the configuration of the cloud environment itself — are S3 buckets public, are IAM roles over-permissioned. CWPP looks at what's running inside that environment. Luna: So CSPM catches the open door, CWPP catches the intruder already inside. Both are necessary, but they solve different problems. Lucas: Let me give you a concrete example. A large insurance company — I'll call them PacificGuard — ran a hybrid cloud environment with workloads on AWS and Azure. They had a standard EDR tool from a major vendor on their virtual machines. But they also had Kubernetes clusters running containerized microservices. Luna: And the EDR couldn't see inside those containers. Lucas: Correct. They had a security operations center with twelve analysts, and they were blind to a growing portion of their attack surface. So in late 2024, they deployed a CWPP from one of the leading vendors — I'll keep the name out of it, but it's a company that originally started in cloud security posture management and expanded into workload protection. Luna: Which is exactly the consolidation trend we're seeing. Most of the major players now offer both CSPM and CWPP in a single platform. Lucas: Right. Palo Alto Networks acquired Twistlock and then RedLock to build Prisma Cloud. CrowdStrike has Falcon Cloud Workload Protection. Trend Micro, Check Point, Aqua Security — they're all competing in this space. PacificGuard chose one that offered agentless scanning for their serverless functions and lightweight agents for their container hosts. Luna: And the agentless piece is important because some environments simply can't tolerate agents. Regulated workloads, legacy systems, third-party managed infrastructure. Lucas: What they found in the first week of scanning was telling. The CWPP's vulnerability assessment flagged a container image that had been in production for eight months. It was running a version of a web server library with a known remote code execution vulnerability — CVE-2024-21626, a high-severity one in the container runtime. Luna: And their EDR never caught it because the vulnerability existed in the image itself, not in a running process that could be behaviorally detected. Lucas: Exactly. The image was built before the vulnerability was publicly disclosed, and nobody had rebuilt it. That's a classic supply chain problem. The CWPP gave them visibility into image provenance and vulnerability age. They found over two hundred containers with critical or high-severity vulnerabilities that had been deployed for more than 30 days. Luna: So the tool shifted them from reactive detection to proactive hygiene. That's a huge operational change. Lucas: It is. But it also creates a new challenge — alert fatigue. A typical enterprise might get tens of thousands of vulnerability findings from a CWPP. PacificGuard had to build automation to triage those: mark internet-facing workloads as priority, ignore internal-only development clusters, and enforce a policy that any critical vulnerability in a production container triggers an automatic block on deployment. Luna: Which is essentially shifting left — catching issues before they reach production, not after. Lucas: Right. And that's where the CWPP integrates with the CI/CD pipeline. The tool can scan images as part of the build process and reject any that don't meet the vulnerability threshold. PacificGuard went from a mean time to remediation of 47 days down to 12 days within three months. Luna: I want to come back to the runtime protection piece, because that's the part that most people don't fully understand. How does a CWPP protect a running container without an endpoint agent? Lucas: It depends on the architecture. Some use eBPF — extended Berkeley Packet Filter — which is a Linux kernel technology that allows you to run sandboxed programs in the kernel space without modifying kernel source or loading kernel modules. eBPF can observe system calls, network connections, and process execution in real time with very low overhead. Luna: So it's like a sensor that lives inside the kernel itself, watching every interaction the workload makes. Lucas: Exactly. And it can enforce policies — for example, block any outbound traffic to known cryptocurrency mining pools, or prevent a container from executing a reverse shell. That's how that bank I mentioned earlier could have detected the cryptominer in hours instead of weeks. Luna: But eBPF requires a modern Linux kernel — 5.8 or later. That excludes older enterprise distributions still running on CentOS 7 or RHEL 7. Lucas: Good point. That's one of the trade-offs. Some vendors offer fallback mechanisms using traditional kernel modules or even userspace agents for those older environments. But the industry is clearly moving toward eBPF as the standard. Even Microsoft is investing in eBPF for Windows. Luna: And if these conversations are useful for what you're building or running — especially if you're in the thick of a cloud migration right now — I want to mention that the show stays ad-free because of listeners who find value in it and choose to chip in. Lucas: It's a small thing — honestly, if today's episode was worth a coffee to you, that's the link. Buy me a coffee dot com slash fexingo. We don't run ads, we don't track listeners, and that kind of direct support is what keeps the show independent. Luna: Yeah. And we really do read every message that comes through. So back to CWPP — you mentioned the consolidation trend. Where do you see the market heading over the next year or two? Lucas: I think we're going to see tighter integration between CWPP and identity security. Cloud workloads have identities — service accounts, IAM roles, instance profiles. If a workload is compromised, the attacker inherits that identity. So runtime protection needs to understand identity context: is this legitimate traffic from a workload that normally talks to the database, or is it anomalous? Luna: That's essentially combining workload protection with identity threat detection and response — ITDR, which we covered a few episodes back. Lucas: Exactly. And we're already seeing vendors like CrowdStrike and SentinelOne blurring those lines. The other big trend is agentless runtime protection becoming more capable. Right now, agentless scanning is mostly for vulnerability assessment, but companies like Wiz are pushing toward full runtime monitoring without any agent at all. Luna: Which would be a game-changer for environments where you can't install anything. But I wonder about the depth of visibility. Can agentless really match eBPF? Lucas: In my opinion, not yet. Agentless approaches typically rely on cloud APIs and log aggregation — they see what the cloud provider exposes, which is a lot, but not the raw system calls. For now, the best approach is a hybrid: agentless for broad visibility and asset inventory, plus lightweight agents or eBPF for deep runtime protection on critical workloads. Luna: So the takeaway for someone evaluating CWPP today: don't look for a single magic bullet. Look for a platform that covers both build-time and runtime, supports agentless and agent-based where needed, and integrates with your CI/CD and identity systems. Lucas: And start with the workloads that are most exposed — internet-facing containers and serverless functions. That's where the biggest blind spots usually are. The PacificGuard example shows that even a mature security team can miss something that's been sitting in plain sight for eight months. A CWPP is a way to close that gap.