Adversaries Are Publishing at Scale. Speed Is Now the Only Defence.

The views expressed in this piece are those of the author.

Something shifted in the threat landscape quietly and most organisations have not yet noticed.

A corpus of roughly 1,000 malicious packages impersonating TanStack libraries was identified recently through jsDelivr CDN telemetry. Researchers cross-referenced download patterns on jsDelivr's public CDN with npm registry data and found a coordinated campaign: packages named to look like legitimate TanStack modules, published in bulk, designed to slip past automated scans and land in real codebases before anyone noticed.

You can browse the data yourself. The scale is not subtle.

This was not a sophisticated, targeted attack against a single enterprise. It was industrialised. Publish enough packages, with plausible enough names, and statistics do the rest. Some percentage of developers will install them. Some percentage of those installs will make it into production. The attackers do not need a high hit rate. They just need volume.

This Is Not Noise. It Is the New Baseline.

The security community has spent years preparing for sophisticated, bespoke supply chain attacks. SolarWinds. XZ Utils. Event-stream. These were carefully constructed, patient campaigns. We built detection tooling, invested in SBOM generation, improved code signing. And we should have.

But industrialised mass-publishing is a different threat model. It is not patient. It is not targeted. It is statistical. Attackers are automating package creation, typosquatting at scale, and relying on the sheer noise of the npm registry to provide cover. The registry publishes hundreds of thousands of packages per month. Hiding a thousand malicious ones is not hard.

Detection gets you partway there. You can flag suspicious packages, scan manifests, monitor for known-bad hashes. But between the moment a malicious package enters your ecosystem and the moment your team acts on the signal, time passes. And in supply chain security, time is the variable that determines whether an incident becomes a breach.

The Real Problem Is Dwell Time

When a malicious dependency lands in a codebase, the clock starts. Every hour it sits there is another hour of potential exfiltration, credential exposure, or pipeline compromise. Every sprint it goes unaddressed is another sprint where it might get promoted to production, copied into a downstream service, or checked into a container image that gets deployed to a customer environment.

Most organisations I speak to have no clear answer to the question: if a malicious package is confirmed in one of our repositories today, how long does it take to be fully removed across our estate?

The honest answer is usually measured in weeks. Sometimes months. Because the remediation workflow is manual. Someone has to find every affected repository. Someone has to create tickets. Someone has to assign ownership. Someone has to open pull requests. Someone has to chase engineers to merge them. Someone has to verify the fix took. That is a lot of someones, doing a lot of manual coordination, against a threat that spreads in minutes.

Reducing Attack Surface Has to Be Continuous

The other half of the answer is reducing the surface area that adversaries can reach in the first place.

Every dependency your codebase carries is a potential vector. Dependencies that are end-of-life, unmaintained, or sourced from registries without provenance controls are the easiest targets for impersonation and typosquatting attacks. A codebase with tight, current, well-governed dependencies is a significantly harder target than one carrying years of accumulated packages that nobody is actively reviewing.

Dependency hygiene is not glamorous work. It does not generate CVE headlines. But it is the structural work that determines how large your attack surface is when the next mass-publishing campaign runs.

Where Verifi Fits

This is exactly the problem Verifi is built to address.

Detection is not the bottleneck. jsDelivr data, npm audit, software composition analysis tools: the signal exists. What is missing is the operational layer that converts signal into action, quickly, across an entire estate, without requiring an army of engineers to coordinate it manually.

Verifi maps every dependency to the repositories, teams and pipelines that consume it. When a package is flagged, whether by your existing scanner, a threat feed, or a public corpus like the TanStack incident, Verifi immediately knows which repositories are affected, who owns them, and what the remediation path looks like. It creates the pull requests. It routes them to the right owners. It tracks completion. It verifies the fix. It prevents the same package being re-introduced next sprint.

Time to contain drops from weeks to hours. Time to remediation drops from months to days.

That is not a product pitch. It is arithmetic. The adversaries publishing 1,000 packages at a time are counting on your remediation workflow being slow. The only way to change the outcome is to make it faster.

What To Do Now

If your organisation does not have a clear, tested answer to "how quickly can we remove a confirmed malicious dependency from every codebase we own", that is the gap to close.

Not eventually. The TanStack corpus is not the last campaign of its kind. It is a preview of the baseline.

The window between detection and remediation is where supply chain breaches happen. Closing it is the work.