---
title: "Malicious Package Detection in Cloudsmith"
description: "Malicious package detection in Cloudsmith — powered by OSV.dev and the OpenSSF Malicious Packages project — lets you see, stop, and govern malware-laced packages before they reach your builds or customers."
canonical_url: "https://cloudsmith.com/blog/malicious-package-detection-in-cloudsmith"
last_updated: "2025-08-14T19:11:59.141Z"
---
# Malicious Package Detection in Cloudsmith

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](https://help.cloudsmith.io/docs/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](https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident) 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](https://socket.dev/blog/contagious-interview-campaign-escalates-67-malicious-npm-packages) 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](https://github.com/ossf/malicious-packages) project, run by the [Open Source Security Foundation](https://openssf.org/) (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](https://osv.dev/) into [Continuous Security](https://help.cloudsmith.io/docs/continuous-security), providing hourly checks against the OpenSSF database. When a malicious package is found, Continuous Security works with [Enterprise Policy Management](https://help.cloudsmith.io/docs/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**](https://help.cloudsmith.io/docs/continuous-security) and **[Enterprise Policy Managemen](https://help.cloudsmith.io/docs/enterprise-policy-management)t **in our documentation. Interested in learning more?   
**[Contact us](https://cloudsmith.com/company/contact-us).**