Malware Detection

Malicious Packages

Malicious packages are artifacts that have been intentionally crafted by an attacker to cause harm. When developers unwittingly include these packages in their applications, they open the door to data theft, ransomware, and other damaging attacks for anyone using the affected artifacts. Malicious packages are a subset of malware (it's malicious software) and a delivery vehicle for malware.

An example of a malicious package is the PyPI package django-log-tracker, which saw its first release in two years in 2024. This release propagated information stealer malware. The threat of malicious packages has grown in recent years, even as public registries introduce stronger security controls.

Software Vulnerabilities (CVE) vs. Malicious Packages

A software vulnerability, often identified by a Common Vulnerabilities and Exposures (CVE) ID, is an unintentional flaw in the code. It's a bug that, if exploited by an attacker, could lead to a security breach. These vulnerabilities are typically the result of errors in design or implementation.

For example, the Log4Shell vulnerability (CVE-2021-44228) was a flaw in the popular Log4j logging library for Java that allowed attackers to gain remote code execution over compromised systems. The library itself was not created with malicious intent.

How malicious packages are introduced in dependencies

Malicious actors attempt to breach the software supply chain by disguising harmful packages as legitimate, tricking developers into including them in their projects. Common techniques include:

• Typosquatting: A new package is published with a name that is a common misspelling of a popular one. For example, publishing reqeusts to trick developers who meant to install the legitimate requests library in Python. This type of attack has been recently extended to a complete new level: registry Typosquatting.
• Dependency Confusion: This technique targets corporate build systems. An attacker discovers the name of a private, internal package (e.g., acme-auth) and publishes a malicious package with the same name to a public registry, often with a higher version number, tricking automated tools into downloading it.
• Account Takeover: Attackers compromise the account of a legitimate package maintainer, then publish a new, malicious version of the trusted package. For instance, if the maintainer of super-utils gets their account stolen, an attacker could release version 1.2.4 containing code to steal credit card information.
• Protestware/Malicious Maintainers: Sometimes, the threat comes from the package maintainers themselves. As an act of protest or malice, they might add harmful code to their own popular library. For example, the maintainer of node-ipc added code that would delete files on systems with specific IP addresses as a form of protest.

OSV and OpenSSF Malicious Packages

Cloudsmith uses the OpenSSF Malicious Packages project - distributed through OSV.dev - as a trusted source for detecting malicious packages in open-source software. The OpenSSF Malicious Packages project is a community-driven effort to collect and document confirmed malicious packages found in the wild across multiple package registries.

OSV.dev, initiated by Google, provides a unified, open, and distributed database for vulnerability information, making it easy for developers and automated security tools to consume. By cataloging malicious packages within OSV.dev, the OpenSSF project centralizes intelligence that helps developers and organizations quickly identify threats and strengthen their software supply chains.

Malicious package detection in Cloudsmith

Plans

Malicious package detection via OSV.dev is available for Ultra and Enterprise customers.

The malicious packages dataset is integrated into Enterprise Policy Management and Continuous Security (both in Early Access). This allows you to define policies that automatically take action when a malicious package is detected.

Here is an EPM policy that matches any package which has been flagged as malicious by Continuous Security, quarantines it, and adds a MALICIOUS_PACKAGE tag:

Example Rego policy

To target malicious packages in policy-as-code, check whether thevulnerability.id field starts with the prefix MAL- - all malicious packages are identified with this string.

Here’s an example policy:

package cloudsmith

default match := false

match if count(malicious_packages) > 0

malicious_packages := [vulnerability.id |
	some vulnerability in input.v0.osv
	startswith(vulnerability.id, "MAL-")
]

Supported Formats

Below you can find the package formats supported by the OSSF Malicious Packages project:

Updated last week