In July 2025, two of the npm ecosystem’s most widely used packages became unwitting carriers of malware. The first, eslint-config-prettier, was compromised after its maintainer was deceived by a phishing email disguised as a message from npm support. With stolen credentials, attackers published malicious versions that spread rapidly into developer environments worldwide, dragging related packages into the breach.

Shortly afterwards, the seemingly innocuous utility ‘is’ (a lightweight library downloaded more than 2.3 million times each week) was taken over in the same way. For roughly six hours, anyone installing the package, directly or through the countless tools that rely on it, was unknowingly pulling a version laced with a backdoor. What makes this striking is not the sophistication of the malware, but the ubiquity of its host. The ‘is’ Javascript testing library does little more than check whether a value is a number, a string, or empty, yet precisely because it is so simple, it is embedded everywhere. Its compromise meant that risk cascaded across the software ecosystem almost instantly.

These events were part of a broader wave of supply chain attacks in which malicious packages are deliberately seeded into public registries. Analysts now estimate that the OpenSSF’s Malicious Packages project tracks more than 35,000 confirmed cases across npm, PyPI and other ecosystems. What once seemed rare is now industrialised.

Why malicious packages matter

Traditional vulnerabilities are flaws to be patched. Malicious packages are different. They are intentional weapons that arrive through normal developer workflows; invisible, inherited deep in dependency trees, and executed automatically by build systems. When a package with millions of weekly downloads is compromised, six hours is enough to spread malware worldwide. By the time advisories are published or scanners raise alerts, the damage is already done.

Intelligence is only valuable if it is enforced

Open source intelligence has improved dramatically, and projects like OpenSSF Malicious Packages and OSV.dev provide vital, structured data. But feeds alone do not change outcomes. What matters is whether that intelligence is enforced at the moment a package attempts to enter your organisation. Otherwise it becomes background noise while builds continue to ingest whatever registries serve.

Cloudsmith’s approach to artifact security

This is why Cloudsmith has introduced malicious package detection within Enterprise Policy Management (EPM). Intelligence from OSV.dev and OpenSSF is now integrated directly into Cloudsmith repositories, so known hostile packages can be blocked, quarantined or tagged at the point of entry; before they touch developer machines, CI pipelines, or production builds.

Even with strong ingress enforcement, new vulnerabilities and threats can emerge after artifacts are already in your repositories. A package that was safe yesterday might later be linked to a newly disclosed CVE or malware signature.

That’s where Continuous Security steps in. This feature, available in EPM-enabled workspaces, performs hourly checks of your stored artifacts against up-to-date vulnerability and threat intelligence sources, such as CVE aggregators and EPSS databases. When a new threat is detected in a previously ingested artifact, Continuous Security flags it immediately without relying on manual re-scans or waiting for scheduled checks. This ensures that your repository remains secure not just at the moment of ingestion, but continuously over time, adapting to evolving risks.

The crucial difference between this approach and those of other legacy artifact management platforms is that Cloudsmith treats this as core to artifact management, not as an optional add-on. When security is sold separately, it is inconsistently applied and easy to bypass. In Cloudsmith it is inseparable from the platform itself, which means every package is subject to the same level of scrutiny the moment it arrives.

Policy makes this practical. Because EPM achieves policy-as-code through Open Policy Agent (OPA), organisations can tune enforcement to their own needs; strict blocking in production, tagging in development, quarantining for review in sensitive environments. Developers do not need to stop and think about dependency safety: those controls are enforced automatically, enabling development teams to move quickly without increasing risk.

Why a unified multi-format repository matters

Attackers are promiscuous in their choice of target. Today it is npm, tomorrow PyPI, RubyGems or Docker Hub. A fragmented security model (one tool for JavaScript, another for Python, another for containers) leaves seams. Seams are where gaps form, where integration fails, and where policy is not applied consistently.

Cloudsmith’s multi-format repositories eliminate those seams. Whether the artifact is npm, PyPI, Docker or NuGet, it traverses the same controlled gateway, subject to the same policies and the same intelligence sources, organised in a manner that makes sense to your organisation. Security and distribution are not separate concerns; they are two sides of the same process.

From artifact management to artifact trust

The compromise of ‘is’ demonstrated how quickly risk can propagate when even a trivial dependency is weaponised. Six hours, millions of downloads, and the possibility of global exposure. In that context, treating malware detection as an optional extra bolted onto artifact management is no longer defensible.

Cloudsmith brings intelligence, policy and artifact management together into one fully managed, cloud-native platform, where trust is enforced automatically at the point of entry across every format your teams use. Developers keep building at pace. Security teams know every package is vetted.

Trust is not inherited within the software supply chain. It has to be enforced.