Cloudsmith’s Enterprise Policy Management (EPM) now supports the Open Source Vulnerability (OSV) database as an additional data source, so users can define malicious package policies. OSV.dev is a distributed vulnerability database specifically for open source software (OSS) packages, including dependencies. The open, precise, and distributed vulnerability information for OSS projects from OSV complements EPM’s existing vulnerability data from Common Vulnerability Scoring System (CVSS) and Exploit Prediction Scoring System (EPSS) sources.

How does OSV work?

The OSV database was originally developed by Google, and is fully open source. It consolidates data from multiple vulnerability repositories that follow the OSV schema, such as GitHub Advisory database, Python Packaging Advisory Database (PyPA), RustSec Advisory database, and the Global Security (GSD) database. This includes the OpenSSF Malicious Packages data source.

OSV offers a straightforward API that allows clients to look up vulnerabilities based on either a specific commit hash or a package version. All records adhere to the OpenSSF OSV specification, which was created through collaboration with open-source communities. This schema provides a standard approach, for both human- and machine-readable format for detailing vulnerabilities, ensuring they can be accurately linked to exact package versions and commits.

Creating a Malicious Package policy in Cloudsmith

Let’s look at an example of Cloudsmith EPM policy. This one serves as a malware detection gate. EPM runs after the Cloudsmith security scan completes during package synchronisation, making scan results available as input.v0. In this case, the policy code loops over the input.v0.osv array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string MAL- ?” If yes, it adds that vulnerability.id to the malicious_packages list.

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-")
]

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "MAL-" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the defined actions for this policy, such as to quarantine, tag, or block package promotion.

Testing the policy

BleepingComputers published a blog post in July 2025 about a set of npm linter packages, including eslint-plugin-react_editor, that were hijacked via phishing to drop malware. Looking up eslint-plugin-react_editor within the OSV database we can see there’s already a matching entry with the ID MAL-2025-6812. Each malware ID comes with an associated Github source that provides all the surrounding context for policy decisions. We are using a free string search for “MAL-” to capture malware IDs.

For npm packages, you can use npm pack or npm view to get the tarball URL:

PACKAGE_NAME="eslint-plugin-react_editor"
PACKAGE_VERSION="71.71.72"
TARBALL_URL=$(npm view ${PACKAGE_NAME}@${PACKAGE_VERSION} dist.tarball)

In this scenario, we downloaded the tarball in a sandbox environment:

curl -O $TARBALL_URL
ls | grep eslint-plugin-react_editor-71.71.72.tgz

We pushed the .tgz tarball to Cloudsmith without installing it locally, which is safer when testing the malicious package.

cloudsmith push npm $CLOUDSMITH_ORG/$CLOUDSMITH_REPO eslint-plugin-react_editor-71.71.72.tgz

Remember: We are detecting based on malware, not on vulnerabilities. In this case there is no CVSS vulnerability data associated with the package, however, the package is still quarantined and tagged for Malware due to the malware findings from the Malicious Packages project.

EPM’s Decision Logs explain how the package was quarantined with the relevant malware information. Here’s a command you could use to return information specific to OSV findings:

curl -sS \
  -H "Accept: application/json" \
  -H "X-Api-Key: $CLOUDSMITH_API_KEY" \
  "https://api.cloudsmith.io/v2/workspaces/$CLOUDSMITH_ORG/policies/decision_logs/?policy=$SLUG_PERM" |
jq '
  .results[]
  | (.policy_input.v0.osv // [])
  | .[]
  | {
      id,
      summary,
      affected,
      source: ((.affected // []) | map(.database_specific.source?) | unique | join(", ")),
      details
    }
'

Removing the jq filter, you get the entire output of the Cloudsmith EPM decision logs. Within these logs, you’ll see:

• started_at/ended_at: Times the policy evaluation started and ended.
• policy_input: The exact data used to evaluate the policy.
• policy_output: The results (match or not, the partial rule states).
• actions: Which actions were actually invoked on the package.

Protect Yourself Against Malicious Packages!

By integrating OSV as a data source, Cloudsmith EPM gains access to vulnerability intelligence that directly maps to specific OSS package versions and commits. These malicious package policies complement the existing CVSS and EPSS coverage by filling critical gaps, particularly in cases where a package may not register a conventional CVSS vulnerability score but is still compromised, such as with malware-flagged releases.

With OSV’s standardised schema and rich ecosystem of upstream sources, EPM will detect and act on threats that might otherwise slip through traditional scoring-based detection, extending its ability to quarantine, block, or tag malicious packages before they impact production environments.