Don't Feed the Worm: Helping Publishers Reduce Exposure To Supply Chain Risk

Fans of Frank Herbert’s sci-fi series Dune will recognize Shai-Hulud as the name of the giant sandworm species that prowls the desert planet of Arrakis, posing a constant threat of annihilation to the characters in the book. Starting in September 2025, "Shai-Hulud" also referred to a worm of the software kind: a self-replicating virus that managed to backdoor several hundred popular JavaScript packages and steal sensitive credentials such as GitHub Personal Access Tokens and API keys for major cloud platforms. 

This type of failure in the software supply chain—the set of third-party libraries/utilities developers use in the process of building their own products—is nothing new in the web development world. The Open Web Application Security Project (OWASP) started tracking a list of the top 10 critical web security risks in 2003. “Software Supply Chain Failures” first appeared on the list in 2013 and has only risen since then, sitting at position #3 in 2025. 

Data security itself is not a novel concept for publishers and membership businesses. These organizations routinely deal with large amounts of sensitive personal data, depend upon uninterrupted revenue operations (which data breaches can severely disrupt), and face growing expectations from regulators around customer data privacy and protection. 

While publishers may already be guarding against well-known threats such as phishing attacks, weak password habits, account takeovers, and social engineering, threats to the software supply chain are likely to remain a blind spot. It’s easy to see why: modern businesses rely on tens if not hundreds of software applications for their daily operations. Keeping an eye on all the potential attack vectors introduced by these programs is simply infeasible.  

JavaScript in particular amplifies this challenge. As the lingua franca of the web, its package ecosystem has only become increasingly interdependent over the years. One only needs to look at the current state of the npm registry (a public database of third-party JavaScript software libraries/utilities) to understand why the supply chain is such an appealing target to attackers.  

Just as the majority of internet activity occurs on a few large websites, the majority of npm registry downloads are concentrated in a few popular packages. This creates a dangerous leverage effect, as compromising a single popular dependency can have cascading effects across the entire web development ecosystem. Package A might be used in utility B, which is a dependency for project C that is, in turn, used by applications D, E, and F. A chain of dominoes is set up such that one package might indirectly affect the functioning of hundreds (or thousands) of dependents. 

The classic example of dependencies gone amok was the infamous 2016 incident involving the “left-pad” package. This package was indirectly used by thousands of projects, including the popular React front-end framework. When the author of left-pad deleted it without warning, all those dependent packages began to fail in a cascade effect, causing a massive disruption of applications across the internet, including major sites such as Facebook, Netflix, PayPal, and Spotify. 

OWASP’s main recommendation for protecting against supply chain failures is for developers to keep track of and closely monitor the list of dependencies for their project. Such a task, while sound in theory, tends to be unrealistic given the size and complexity of modern-day web projects.  

Modern websites are expected to provide a high degree of interactivity and typically use a “front-end framework” to organize the mountains of JavaScript code that must run behind the scenes. While these frameworks have made the process of coding websites easier than ever before, they come with the side effect of introducing a massive amount of dependencies to a project. 

Take, for example, the most popular front-end framework, React. Even a simple “Hello World” project making use of this framework can pull in hundreds to thousands of npm packages through transitive dependencies. Such a large dependency tree, right from the start of the project, makes monitoring the software supply chain nearly impossible. 

Fortunately, there are alternative solutions. Enter Blazor, the front-end framework upon which Advantage is built. By allowing developers to build interactive web UIs with C# and the .NET platform, Blazor helps reduce reliance on the JavaScript ecosystem and, thereby, the risk of npm supply chain attacks. 

The particular flavor of Blazor that Advantage uses, Blazor Server, goes one step further by moving the execution of most UI logic off the client’s browser onto a centrally managed server. This means that the browser only needs to be responsible for rendering UI updates sent by the server, eliminating the need to ship and execute copious amounts of third-party JavaScript on the client. 

It is important to note that Blazor is not a silver bullet, however. Blazor applications rely on their own network of third-party packages called NuGet. And while NuGet packages tend to be more centralized and authored by established organizations compared to npm, they are not  immune to supply chain attacks. Further, Blazor provides an interop service that allows developers to use npm packages in Blazor projects, a feature that Advantage utilizes. This means that teams can re-introduce most, if not all, npm supply chain risk to a project if they are liberal in their usage of the interop feature. 

No framework can eliminate supply chain risk entirely; such risk will always exist as long as we use third party libraries and tools when building software. That said, our team has found that Blazor offers a practical way to reduce the number of third-party JavaScript dependencies we end up shipping with Advantage. 

This is just one way the engineering team at AdvantageCS is doing our part to keep clients’ data safe. By choosing tools and frameworks that help facilitate dependency minimization, we’re helping ensure that the next time you encounter the name “Shai-Hulud,” it is safely within the pages of Dune.