Cloudsmith now detects malicious packages using data from OSV.dev and the OpenSSF Malicious Packages project so you can see, stop, and govern packages designed to attack your supply chain before they reach your builds or customers.

Below is a quick primer on malicious packages, how Cloudsmith protects customers from malware with Enterprise Policy Management (EPM) policy-as-code, and what’s next.

What is a “malicious package”?

A malicious package is an artifact published to a public registry (npm, PyPI, RubyGems, etc.) that’s intentionally crafted to harm users or systems. Unlike a vulnerability (a flaw to be fixed), this is deliberate abuse: credential theft, data exfiltration, backdoors, cryptominers, or build-pipeline compromise — delivered as a normal-looking dependency.

It’s both:

• A subset of malware (it’s malicious software).
• A delivery vehicle for malware (it “rides” the OSS dependency graph via a compromised dependency into apps and CI/CD; more on that below).

Why it matters

While traditional malware often arrives via email attachments, web drive-bys, or exploit kits, malicious packages differ. Attackers publish them to registries (or compromise maintainers) so that developers and automation (CI, package managers) do the installation work for them, shifting the battleground to developer workflows and dependency resolution.

Software packages as delivery vehicles for malware isn’t a new thing. The 2018 event-stream incident was an early wake-up call: a trusted package was weaponized through a hidden dependency to target a cryptocurrency app. The threat has only grown. In mid-2025, researchers uncovered a coordinated malware campaign on npm attributed to North Korean threat actors, involving dozens of malicious packages disguised as developer tools. These packages, collectively downloaded thousands of times, deployed multi-stage payloads and backdoors like BeaverTail and InvisibleFerret. Even as registries introduce stronger security controls, attackers continue to adapt.

The OpenSSF malicious packages project

The OpenSSF Malicious Packages project, run by the Open Source Security Foundation (OpenSSF), maintains a public, comprehensive, cross-ecosystem database of reports on malicious software packages (e.g., from npm, PyPI, RubyGems). It collects detailed intelligence on malicious packages—such as account takeover attacks, dependency confusion, and malware embedded via post-install hooks—and makes this information openly available using the Open Source Vulnerability (OSV) format for easy integration.

As of August 2025, the database contains ~35,000 malicious package reports.

Malicious packages in Cloudsmith

Cloudsmith integrates this data feed via OSV.dev into Continuous Security, providing hourly checks against the OpenSSF database. When a malicious package is found, Continuous Security works with Enterprise Policy Management (EPM) to automatically flag and quarantine it, preventing the harmful software from entering your builds.

Why this helps

• Stop threats early: Blocking malicious packages at the source prevents them from ever reaching your systems.
• Protect your CI/CD pipelines: Prevent attackers from compromising builds or slipping backdoors into production.
• Empower developers to move fast, safely: Guardrails reduce risk without slowing teams down.
• Avoid costly incident response: Catching threats before they’re integrated saves time, effort, and reputational risk.
• Meet compliance and customer expectations: Support audits and build trust with security-conscious buyers.
• Use trusted data from OpenSSF: Tap into a community-maintained feed of verified malicious packages across major ecosystems.

What’s next?

As attacks adapt, so will Cloudsmith. We’ll continue to expand detection by adding more threat intelligence sources, richer context and deeper automation in EPM. Upcoming work includes incorporating deps.dev to surface package quality and maintainability data, and adding more community feeds like OSV.dev - a great example of the open source community working together to solve supply chain security challenges.

We’re also exploring ways for Enterprise customers to bring their own internal threat intelligence feeds into Continuous Security, further tailoring protection to their environment. Our goal is to broaden coverage and shorten the time it takes to detect and respond to threats. If there are specific feeds or heuristics you’d like us to prioritize, let us know.

Explore more about Continuous Security and Enterprise Policy Management in our documentation. Interested in learning more?
Contact us.