How Web Assembly Can Mitigate the Software Supply Chain Crisis

The definition of insanity, according to no less than the insightful mind of Albert Einstein, is doing the same thing over and over and expecting different results. Arguably, there is nothing more insane today than the current state of cybersecurity.

For the developer, the predominant method for building software continues to rely on the aggregation of software components that tend to lack distinct security boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application.

A case in point are the now infamous Log4jShell vulnerabilities that have impacted almost every Java application. It allows cybercriminals to take advantage of Log4j’s ability to use the Java Naming and Directory Interface (JNDI) to force a Java application to connect to an attacker-controlled LDAP server in a way that allows malicious code to be remotely executed, otherwise known as an RCE attack.

The vulnerability stems from a widely used method to construct applications that tightly couples enterprise business logic with specific libraries to implement supporting functionality. In enterprise architecture, these two layers are distinguished as the application functional requirements (AFRs) and the application non-functional requirements (NFRs).

Enterprise applications typically include dozens of NFRs such as web servers, web clients, database connections, message queues, and, of course, logging software such as Log4j. These NFRs, unfortunately, are often compiled into the same single binary as libraries with the business logic.

When a vulnerability such as Log4jShell occurs in one of these popular libraries, millions of updates are required to remediate a zero-day vulnerability. The need for a better way to build and deploy secure software has never been more apparent — Log4jShell is just one particularly nefarious example of why this is the case.

Worse yet, developers routinely copy and paste code to increase efficiency. When a zero-day vulnerability is discovered hundreds, perhaps even thousands, of components residing in multiple applications might be impacted. The remediation effort required is often nothing less than tremendous.

Adding insult to that original injury, organizations have to invest in a vast array of security platforms to protect applications that from an architectural perspective are deeply flawed. Each security platform employed, of course, also requires a security operations team to employ it. It’s little wonder that the cost of cybersecurity as a percentage of the overall IT budget has steadily increased. In fact, as more applications based on aggregated components are deployed the downstream cost of cybersecurity only rises. It is, in effect, a vicious cycle.

Fortunately, a mechanism through which truly secure applications can be created could be at hand: WebAssembly (Wasm) is a portable binary-code format and a corresponding text format for building applications in a sandboxed execution environment that runs in memory.

That approach replaces the current method for building software that relies on the aggregation of software components that tend to lack distinct security boundaries between them. That lack of a boundary is today, in fact, at the root of most of our cybersecurity woes.

Wasm was designed to break that cycle by virtualizing particular binary formats and libraries in a way that eliminates the need to continuously update vulnerable application components. Cyber security professionals should encourage developers to abandon legacy approaches to building applications in favor of a new approach that creates secure applications by default.

The Rise of Wasm

Compatible with any programming language, Wasm is an open standard defined by the World Wide Web Consortium (W3C). The effort to create an application-development platform based on Wasm is now being led by the Cloud Native Computing Foundation (CNCF), an arm of the Linux Foundation. At the core of that effort is wasmCloud, a distributed application runtime for WebAssembly created by Cosmonic that is now being advanced under the auspices of the CNCF.

That platform makes it possible to securely create and run applications on any platform using a universal application runtime for building cloud native applications. The goal is to move beyond the deeply flawed architectures that have created a cybersecurity nightmare that only grows worse with each new application deployed.

Shopify and Fastly are both using Web Assembly to execute untrusted third-party code.

Arguably, the best part of wasmCloud is that it can be easily deployed on top of existing IT environments to run applications in a sandboxed execution environment where there are NFRs employed. As a fellow CNCF project to Kubernetes, wasmCloud ships with robust support for and integration with the modern cloud native ecosystem.

That approach sharply reduces the overall size of the attack surface that needs to be defended within those applications in a way that provides the added benefit of driving down the cost of cybersecurity. As a result, cybersecurity teams now have a vested interest in encouraging developers to embrace Wasm as a methodology for building applications as quickly as possible.

Already in Use

As a universal runtime, wasmCloud is already being used to provide a secure foundation for running applications in a sandboxed environment that can be deployed on everything from mobile and Internet of Things (IoT) devices to local servers and public clouds based on virtual machines and cloud native platforms such as Kubernetes.

Wasm, meanwhile, is gaining traction. Microsoft, for example, is already making available Krustlet, an extension that makes it possible to run Wasm workloads on Kubernetes that is compatible with wasmCloud. Open source projects such as Envoy, a proxy server, and Open Policy Agent (OPA), a tool for enforcing compliance policies as code, have incorporated Wasm to execute untrusted third-party plugins.

Shopify, a provider of an e-commerce platform and Fastly, a provider of a content delivery network (CDN), are similarly using Wasm to execute untrusted third-party code. There are, of course, thanks to the efforts of the W3C, already thousands of examples of Wasm already being used to run applications in browsers.

Nor is the CNCF the only consortium promoting the adoption of WebAssembly technologies. The Bytecode Alliance has launched WebAssembly (Wasm) and WebAssembly System Interface (WASI) initiatives as part of an effort to promote standards that would make it easier to run Wasm applications anywhere.

Originally founded by Fastly, Intel, Mozilla and Microsoft, the Bytecode Alliance now also includes Arm, Google, Shopify, Cosmonic, DFINITY Foundation, Embark Studios, and the University of California at San Diego.

Collectively, these efforts could very likely forever change the way developers build, deploy, and manage distributed applications running both at the network edge, in the cloud, and everywhere in between.

A Brave New World of Secure Applications

When it comes to making any substantive change the biggest obstacle is always simple inertia. If developers only know one way to build an application, that is always going to be the methodology employed. In the wake of a recent series of high-profile breaches of software supply chains — the Log4j attacks notwithstanding — there is now more attention being paid to how applications are constructed than ever. Organizations of all sizes are starting to realize that all code can’t be trusted simply because no one can say with absolute certainty that it isn’t vulnerable. As the number of zero-day vulnerabilities being discovered continues to increase, it’s clear that software that was considered secure today might not be tomorrow.

Wasm, coupled with the wasmCloud universal runtime, was designed with the ambition of laying the foundation for a new era of application development. The days when developers needed to distinguish between what should be an AFR versus an NFR to build a secure application could thankfully be coming to an end. In its place will likely be a long-overdue architecture that enables developers to build and deploy applications that are secure by default.

There is, of course, no such thing as perfect security. However, we are potentially on the cusp of a major advance in how applications are both constructed and deployed that comes along but once in a generation. As the individuals most often held accountable for application security it behooves security professionals to not just encourage developers to embrace Wasm but rather, starting today for the sake of the sanity of everyone involved, to insist upon it.