Why WebAssembly is the Swiss Army Knife of Cloud Security (and eBPF is More Like a Really Good Hammer)

Ever tried to open a wine bottle with a hammer, or maybe a stick you found outside the basketball court during a conference (we eventually got it open)? While you might eventually get there, you'd probably prefer a corkscrew. That's a bit like the current state of cloud security tools - using the right tool for the right job matters more than you'd think.

In cloud security, we've been watching an interesting shift. The U.S. National Institute of Standards and Technology (NIST) recently published "A Data Protection Approach for Cloud-Native Applications" that's turning heads in the tech community. Their message? WebAssembly (WASM) could be the corkscrew we've been looking for when securing cloud-native applications.

If you're familiar with cloud security, you've probably heard plenty about eBPF (extended Berkeley Packet Filter). It's been the go-to tool for many security teams, and for good reason - it's excellent at what it was designed to do. But as Wesley Hales, co-author of the NIST report, puts it: "A lot of folks have the eBPF hammer, and everything looks like a nail to them — but it's not."

Why WASM Changes the Game

WASM gets you closer to the actual data. Instead of operating at the kernel level, it can see and understand the conversations between services - the HTTP traffic, the gRPC calls, the GraphQL queries - all the Layer 7 stuff that makes modern applications tick.

Think about it this way: As Hales explains, "You may have 10,000 containers sitting behind an Istio proxy, while all the logging traffic, all the web traffic, even the database traffic all has to go in the proxy and then to wherever the destination is. So we get to look at all that with WASM."

Security by Design, Not Afterthought

What makes WASM particularly interesting for security folks is that it was built with sandboxing in mind from day one. As Matt Butcher, Fermyon's co-founder and CEO, points out: "The most widely used sandboxed application environment is one I guarantee you are running right now: a web browser. The browser is an environment fundamentally built to run untrusted code. WebAssembly's browser-based heritage is the reason for its first-class sandboxing technology."

Think about what your web browser does for a moment - it's actually quite terrifying when you consider it. Every time you visit a website, your browser is downloading and executing unknown, potentially malicious code. Yet we trust our browsers to keep us safe, and they do this remarkably well. WebAssembly inherits this security-first DNA, bringing three critical security features to the table:

1. Sandboxing: Just like your browser protects your system from malicious websites, WebAssembly creates isolated environments for code execution. This means WebAssembly code can't access unauthorized data or even determine information about where it's running. It's like having each bit of code run in its own secure vault.
2. Deny-by-default Access: WebAssembly takes a strict "guilty until proven innocent" approach to system resources. Want to access the system time? Sorry, not allowed. Need to read a file? Not without explicit permission. This deny-by-default policy means that even the most basic system resources are off-limits unless specifically granted access.
3. Memory Boundaries: Each WebAssembly instance gets its own isolated memory space - think of it as having your own private workspace that nobody else can peek into. This memory isolation ensures that one instance can't interfere with or spy on another, making it perfect for handling sensitive data in cloud environments.

The eBPF Perspective

Now, this isn't about throwing eBPF under the bus. eBPF is brilliant at what it was designed for - protecting against kernel-level vulnerabilities and side-channel attacks. As Hales explains in the article, "eBPF was originally designed for protection against side-channel attacks, such as the Heartbleed vulnerability — which compromised the OpenSSL cryptographic library — and other kernel-level, related vulnerabilities."

The challenge comes when using eBPF beyond its intended purpose. According to Hales, "People are using it for everything because it's an easy insertion point. However, it cannot access Layer 7 human-readable text, as it operates in the kernel space."

A Practical Example

The NIST paper highlights how using eBPF for higher-level analysis creates what Hales describes as "a Frankenstein-like process that is not performant at all." He notes that his team "actually prototyped eBPF, and it simply wasn't going to work for us."

Looking Forward

Ben Hirschberg, CTO and co-founder of ARMO, provides a balanced perspective: "eBPF was never meant to be a generic computation platform and it has both algorithmic and memory constraints. From a security perspective, it is also a bad practice to push functionality to the kernel (where eBPF resides) when it can be accomplished in the user space like WASM. It thus makes much more sense to implement complex observability logic in WASM and leave the required minimal functionality in eBPF."

Matt Butcher adds an important point about WASM's versatility: "It is useful to think of WASM as a flexible core technology with well-defined extension methods. It is platform-neutral, meaning it can run on many operating systems and system architectures... To put it succinctly: WASM was built to be general-purpose while eBPF was not."

The Bottom Line

Just like you wouldn't want to rely solely on a hammer or a corkscrew in your toolbox, modern cloud security requires a thoughtful combination of tools. WebAssembly's emergence as a security tool doesn't diminish eBPF's importance - it complements it. Together, they provide a more complete security picture, from kernel-level protection to application-layer intelligence.

And who knows? Maybe the next time you're faced with a security challenge, you'll remember that stuck wine bottle at the conference and reach for the right tool first.