The Trivy Supply Chain Attack and the Visibility Gap

Recent reports of a supply chain attack involving Trivy, a widely used open-source security scanner, reveal a concerning evolution in open-source threats: self-propagating malware spreading across npm packages.

npm is the default package manager for Node.js and the world’s largest software registry, hosting millions of JavaScript packages. It allows developers to install, manage, and share reusable code modules for both frontend and backend projects, so the irony is unfortunate: somebody’s turned a tool designed to detect vulnerabilities into a vector for distributing them.

The campaign, dubbed CanisterWorm, doesn’t just compromise a single dependency. It uses stolen credentials and automated publishing to infect multiple packages, establishing persistence and expanding its reach across the ecosystem. With 47 packages compromised and thousands of downloads affected, this represents a new scale of automated supply chain compromise.

The Client-Side Focus Shift

At first glance, this looks like a familiar supply chain story: with a compromise package pointing to the need for tighter dependency security. In this kind of situation, it’s reasonable to focus on security responses to upstream problems. Questions might include:

• Which packages were affected?
• How did the attacker gain access?
• How can we stop this from happening in the future?

All valid, of course, but they assume that the main risk lies at the entry point, and they focus on containment at the source. The problem with that approach is that sources are always going to be compromised eventually, and that being the case, the question for website owners must always be, “How are we going to detect compromised code when it’s running in production?”

That’s not being defeatist, just practical. The law of averages says that bad actors will always find a way to introduce malicious code, eventually, so it’s better to ask what systems you have in place to discover that code once it’s running in your users’ browsers, since this is where traditional security controls have limited visibility.

This new threat ramps up the urgency to respond. Bear in mind that malicious npm packages have already demonstrated their ability to:

• Intercept network requests (fetch, XHR)
• Access sensitive browser APIs
• Exfiltrate credentials, tokens, and user data in real time, including form hijacking, session token theft, and real-time credential harvesting

But CanisterWorm amplifies this risk further, in three ways:

• It scales distribution automatically
• It increases the likelihood of reaching production
• It reduces the time defenders have to react

What CanisterWorm Actually Does

• Steals npm authentication tokens from compromised developer environments
• Publishes malicious updates to packages the developer maintains
• Embeds itself in those packages to repeat the cycle
• Creates exponential spread across the npm ecosystem without human intervention

In the Trivy-linked campaign, this played out in a very practical way: attackers used stolen npm credentials to publish malicious updates to trusted packages, which could then be pulled into production during routine dependency updates.

Because CanisterWorm propagates automatically, this process can scale rapidly, infecting multiple packages before detection. The result: seemingly legitimate code executing in users’ browsers with access to sensitive data and session activity, long before traditional tools raise an alert.

From Polyfill.io to npm worms: same problem, new entry point

Incidents like Polyfill.io revealed a critical gap: the problem wasn’t just that a trusted library could be compromised, it was also that malicious code executing directly in users’ browsers was beyond the visibility of most security teams. It wasn’t just that the ‘well’ could be poisoned, it was that many of those ‘drinking’ from it (those without Reflectiz) had no way of knowing.

CanisterWorm poses the same fundamental risk, but it arrives through a different channel. Polyfill.io involved a compromised CDN script. CanisterWorm arrives through self-propagating npm packages.

Different entry points – same outcome: untrusted code running in trusted browser sessions.

The growing gap: supply chain entry vs. runtime impact

Modern security tooling is heavily focused on SBOMs, dependency scanning, and registry monitoring, but these controls stop at the point of ingestion.

They don’t answer:

• What scripts are actually executing client-side?
• What data are those scripts accessing?
• Has behavior changed after deployment?

This is the core problem: a package can pass all scans, but once deployed, it can be updated remotely via CDN and only trigger its malicious behavior after detecting that it’s being run in production environments. By the time your SBOM flags an issue, that code has already been executing in customer sessions for hours or days.

This creates a critical visibility gap between the point where malicious code enters and where it causes harm. This is the gap most security stacks leave open, and where Reflectiz operates.

Why prevention is no longer enough

Self-propagating attacks change the economics of defense. When malware can spread automatically across packages and maintainers, detection windows shrink, blast radius increases, and prevention becomes a roll of the dice rather than guaranteed.

What makes attacks like this especially challenging is their increasing level of automation. The propagation logic begins to resemble self-executing systems – triggering actions, updating packages, and maintaining persistence without ongoing human input. CanisterWorm uses an ICP canister, a tamperproof smart contract on the Internet Computer blockchain, as its command-and-control server, making it the first publicly documented malware to do so. Because the attacker can swap the C2 URL directly in the canister, the infrastructure is effectively resistant to conventional takedown. The result is an autonomous, scalable compromise that reduces defender response time and is significantly harder to neutralize than traditional C2 architectures.

Even well-secured organizations can end up shipping compromised code, and when that happens, a visibility gap is the last thing you can afford.

Closing the visibility gap

The supply chain security conversation has focused almost entirely on the entry point: scanning packages, monitoring registries, and validating dependencies before they enter your codebase.

But CanisterWorm and incidents like Polyfill.io amplify the fundamental truth that the damage doesn’t occur at the entry point, but at the browser. Malicious code executes in trusted user sessions, outside the visibility of traditional security controls.

That’s why it’s never been more important to understand what third-party code is getting up to in users’ browsers, and in real time. Knowing what’s in your supply chain is critical, but knowing how components are currently behaving in users’ sessions is even more so.

How Reflectiz Bridges the Visibility Gap

Reflectiz addresses this gap through remote monitoring: a proprietary browser environment that continuously simulates real user sessions across your web properties – without deploying a single line of code on your site. Every script that executes, every network request made, every data flow that occurs is observed and measured against an established behavioral baseline.

For an attack like CanisterWorm, this matters in a precise way. A compromised npm package that passes every pre-deployment scan will still deviate from its prior behavior the moment it begins harvesting credentials or exfiltrating session tokens. That behavioral shift: new outbound connections, unexpected data access, altered network request patterns – is what Reflectiz surfaces, in real time, before it becomes a breach.

When a threat is confirmed, Reflectiz’s on-demand blocking mechanism can isolate the malicious domain via CSP injection, with no developer involvement and no disruption to normal site operation. Detection and response at the browser layer, without touching your codebase.