How Web Assembly Can Ease the Software Supply Chain Crisis – The New Stack

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

For the developer, the predominant method of 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 easy for malware to infect all 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 execution at distance from malicious code, otherwise known as the RCE attack.

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

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 the libraries with the business logic.

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

Worse still, developers regularly copy and paste code to increase efficiency. When a zero-day vulnerability is discovered, hundreds or even thousands of components residing across multiple applications can be impacted. The remediation effort required is often simply enormous.

Adding insult to that initial injury, organizations need to invest in a wide range of security platforms to protect applications that are architecturally deeply flawed. Each security platform used, of course, also requires a security operations team to use it. It’s no wonder that the cost of cybersecurity as a percentage of the overall IT budget has been steadily rising. In fact, as more and more aggregate component-based applications are deployed, the downstream cost of cybersecurity only increases. It is, indeed, a vicious circle.

Fortunately, a mechanism by which truly secure applications can be built might be at hand: WebAssembly (Wasm) is a portable binary code format and corresponding text format for building applications in a binned execution environment. sand that runs in memory.

This approach replaces the current method of building software that relies on aggregating software components that tend to lack distinct security boundaries between them. This borderlessness is, in fact, the root of most of our cybersecurity problems today.

Wasm was designed to break this cycle by virtualizing particular binary formats and libraries in a way that eliminates the need to continually update vulnerable application components. Cybersecurity professionals should encourage developers to abandon old approaches to building apps in favor of a new approach that builds apps that are secure by default.

The Rise of Wasm

Compatible with all programming languages, 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 led by the Cloud Native Computing Foundation (CNCF), a branch of the Linux Foundation. At the heart of this effort is wasmCloud, a distributed application runtime environment for WebAssembly created by Cosmonic that is now being advanced under the auspices of the CNCF.

This platform makes it possible to securely build and run apps on any platform using a universal app runtime to build cloud-native apps. The goal is to move beyond deeply flawed architectures that have created a cybersecurity nightmare that only gets worse with each new application deployed.

Both Shopify and Fastly use Web Assembly to run untrusted third-party code.

Arguably the best part of wasmCloud is that it can be easily deployed on top of existing computing environments to run applications in a sandboxed execution environment where NFRs are used. As a CNCF project associated with Kubernetes, wasmCloud comes with robust support and integration of the modern cloud-native ecosystem.

This approach dramatically reduces the overall size of the attack surface that must be defended within these applications in a way that provides the added benefit of lowering the cost of cybersecurity. As a result, cybersecurity teams now have a vested interest in encouraging developers to adopt Wasm as a methodology to build applications as quickly as possible.

Already used

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

Wasm, meanwhile, is gaining ground. Microsoft, for example, already makes available Krustlet, an extension for running Wasm workloads on Kubernetes 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 integrated Wasm to run untrusted third-party plugins.

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

Nor is the CNCF the only consortium promoting the adoption of WebAssembly technologies. The Bytecode Alliance launched the 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 University of California San Diego.

Collectively, these efforts could quite possibly 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 new world of secure applications

When it comes to making a substantive change, the biggest obstacle is always simple inertia. If developers only know one way to create an application, it will always be the methodology used. Following a recent series of high-profile breaches of software supply chains – Log4j attacks notwithstanding – more attention than ever is now being paid to how applications are built. Organizations of all sizes are beginning to realize that all code cannot be trusted simply because no one can say with absolute certainty that it is not vulnerable. As the number of zero-day vulnerabilities discovered continues to rise, it is clear that software considered secure today may not be so tomorrow.

Wasm, together with the wasmCloud universal execution engine, was designed with the ambition to lay the foundations for a new era of application development. Fortunately, the days of developers having to distinguish between what should be an AFR and an NFR to create a secure application may be coming to an end. In its place, there will likely be a long-awaited architecture that will allow developers to build and deploy apps that are secure by default.

Of course, perfect security does not exist. However, we are potentially on the cusp of a major breakthrough in the way apps are both built and deployed, but one that only happens once in a generation. As the individuals most often held accountable for application security, it is incumbent upon security professionals not only to encourage developers to adopt Wasm, but rather, starting today for the sanity of everyone involved, to insist on it.

Feature image via Pixabay.