Solving the SBOM crisis with WebAssembly components

Recent reports have thrown the spotlight back on the thorny issue of inherited software vulnerabilities. Many don’t realize how widespread the problem is within the software supply chain, and how many businesses are at risk. Here, we’ll dive into this increasingly damaging problem, and explain how WebAssembly’s component model will offer a progressive path forward.

SBOM: Recognizing the cost of free

We’re all familiar with infamous vulnerabilities such as the Log4shell vulnerability in Log4j. To put the damage it did into context, operations ground to a halt within 40% of global businesses when a security flaw gave cybercriminals a pass to infect critical systems with a single dose of malicious code. Given the average cost to fix a single Log4j breach is $4.62 million, according to IBM, and requires 12% of operational resources to resolve it, the impact is huge.

[ Also on InfoWorld: Building the component model for Wasm ]

Despite industry-wide efforts to develop policies, practices, tooling, and education around open source security, spearheaded by the Open Source Software Security Foundation (OpenSSF), research shows more than 70% of companies remain vulnerable to Log4shell. This shows just how pervasive and difficult to eradicate vulnerabilities can be.

Even in a “normal” operating state developers are crushed by the compliance and operational burdens of application development. A recent internal study from Deloitte found that developers spend 80% of their time managing application operations and maintenance. And just what are they maintaining? The common open source code that composes 95% or more of a typical application. While bootstrapping our applications with open source libraries accelerates and simplifies application development, it comes at the cost of maintaining these components.

New compute is not immune

Newer compute paradigms—containers, for example—are not immune. Sysdig’s 2023 Cloud-Native Security and Usage Report reveals the lack of proper security policies is fueling a rise in misconfiguration-related vulnerabilities. The report claims 87% of container images running in production have critical or high-severity vulnerabilities—a 13% increase on last year.

Even in Rust (a safety and security-postured language), there are vulnerabilities in popular libraries like Hyper, which underpins a host of Rust frameworks. According to JFrog, 2,579 projects listed in Rust’s package repository, crates.io, depend on Hyper, which has been downloaded over 67 million times. The Hyper vulnerability converts the incoming HTTP body into a myriad of bytes, which crashes microservices and applications. As developers, we might be completely unaware of it. If the same code is running across 20,000 applications, it becomes a logistical nightmare for enterprises to maintain at scale.

NFRs, an inconvenient truth

90% of all inherited vulnerabilities reside in non-functional requirements (NFRs), which in turn account for 95% of the contents of most applications. NFRs are the set of specifications that define an application’s operating capabilities, attributes, and constraints. They are sometimes referred to as “boilerplate” code—the standard stuff that gets imported again and again. The problem is that applications inherit the vulnerabilities of their imported libraries.

NFRs are also a huge drain on resources. Organizations spend 60% to 70% of development time on application maintenance and operations, not enough time on core feature delivery. As modern enterprises become more distributed—think mobile-first, native web apps, multiple clouds and edges—we’re re-factoring apps to run further outside the core (where the data and users are). As we service and onboard these new platforms, we couple our existing business logic with more NFRs—and our NFR burden keeps growing.

NFRs quickly become standardized across enterprises and often become part of golden application templates. When you create a new application, all libraries are, theoretically, up-to-date and patched. Vulnerabilities are inevitably discovered, however, and the application may now be at risk of compromise.

Although some vulnerabilities can be patched systematically, most are maintained on an application by application basis. What’s the solution? We can’t go back and rewrite every library. The answer is to find a way to abstract NFRs completely from the development experience. If we reduce the tight coupling of specific NFRs to specific applications, we simplify the management of the vulnerabilities. The WebAssembly (Wasm) component model is designed to do just this.

Abstracting vulnerabilities with WebAssembly

Cosmonic

Figure 1: Epochs of tech on the journey to abstraction.

Over the last 20 years, we’ve seen bottom-up innovation that has pulled much of the application maintenance burden out of specific applications. Historically, applications were designed and built alongside hardware—a specific named server on a rack. Gradually, we continue to abstract away from those underlying layers, pulling away complexity, removing and consolidating tasks traditionally done on an application-by-application basis. We have modularized virtual machines, data centers, operating systems, and orchestration platforms.

Embracing the security principle of minimal footprints, the ongoing goal is to minimize the amount of application-specific configuration and maintenance imposed upon each development team. When we consider the applications that we load into a container, there remains one final abstraction to make—the NFRs.

The lives of enterprise developers are full of frustrating compliance tasks. Maintaining the application layer on an application by application basis is a tremendous burden. WebAssembly finally brings much-needed relief to developers struggling with the ongoing complexities of application maintenance. Check out Kevin Hoffman’s recent blog post on Zero Trust Computing in Wasm and wasmCloud for more.

The WebAssembly component model finally brings relief to developers by providing abstractions for common NFRs—web servers, databases, logging, and message queues. Rather than being embedded into each application at compile time, the most up-to-date version of these abstractions can be attached at runtime. This simple abstraction offloads a tremendous amount of ongoing maintenance to the platform where it can be automated.

What this means to enterprises is that we free developers from the overwhelming task of maintaining their application boilerplate on an application-by-application basis. This allows developers to spend their time focusing on innovating and delivering new features to delight their customers. Furthermore, standardization allows enterprises to automate these time-consuming tasks and ensures that they happen in near real time.

This is a huge leap forward from the manual processes we find in maintenance today. Catch Brooks Townsend and Bailey Hayes describing the ways wasmCloud and the Cosmonic platform remove vulnerabilities at the component level.

Finalization of the WebAssembly component model

Containers opened the way to split up the monolith into microservices, so that we could work on an individual microservice without affecting everything else. Wasm takes this model to the next level—splitting the application into individual components. The component model is a real-world method to extract, change, and refactor individual components within an application without affecting the rest of the components around it.

Why is this important? The Component Model will remove tightly coupled NFRs where vulnerabilities commonly reside - eradicating the tight coupling of applications to specific applications. In her recent article for InfoWorld, Bailey Hayes (director of the Bytecode Alliance Technical Steering Committee and Cosmonic) describes a world where developers can “pick and choose pieces of their application, implemented in different languages, as different value propositions.” As Wasm component libraries start to take shape, developers of all kinds will see them as the world’s largest crate of “Legos.”

What remains are small pieces of business logic that don’t suffer from the sort of embedded vulnerabilities that we tend to find in the huge amounts of code that underlie most applications. The value to developers is that they only write the right code, and applications become 95% smaller than early cloud-native applications, translating to 95% fewer inherited vulnerabilities.

CNCF wasmCloud is the first application runtime to support the WebAssembly component model. It brings the kind of Zero Trust, secure-by-default approach that stands to eradicate supply chain vulnerabilities and consign this common issue to history.

Liam Randall is CEO of Cosmonic and chair of CNCF Cloud Native Wasm Day.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to [email protected].