Risk detection

Vulnerability detection

Vulnerability detection automatically matches supported package formats against known vulnerabilities aggregated by OSV.dev, both at upload and every 5 minutes thereafter. Detection results feed into observability via the Cloudsmith web app and the Cloudsmith API, and into control via Cloudsmith’s policy management.

Vulnerability detection surfaces unintentional flaws (CVEs and equivalent advisories). For intentionally harmful packages, see Malicious package detection. Both types of detection draw from OSV.dev but use different advisory types.

OSV.dev is our primary data source for vulnerability intelligence. TrivyDB is also available as a secondary source of vulnerabilities. Access to TrivyDB vulnerability intelligence is available today only for policy management.

OSV

OSV.dev is an open-source vulnerability database for open-source software, launched by Google in 2021 and maintained by Google's Open Source Security Team.

Rather than producing vulnerability data directly, OSV.dev aggregates records from multiple authoritative upstream databases that publish to the OSV Schema, a JSON format developed by the OpenSSF which maps precisely to package names, versions, and commit hashes.

Upstream sources include GitHub Security Advisories, PyPA, RustSec, the Global Security Database, and others, alongside conversion pipelines maintained by the OSV.dev team for sources like Debian Security Advisories, Alpine SecDB, and NVD CVEs. The result is a single normalized feed covering more than two dozen ecosystems, refreshed continuously as upstream advisories are published.

TrivyDB

TrivyDB is the open-source vulnerability database maintained by Aqua Security as part of the open-source Trivy project. Like OSV, it collects vulnerability information from multiple upstream databases, for example, GitHub Security Advisories and language-specific vulnerability databases.

How it works

Vulnerability detection runs automatically for all supported package formats in your workspace, with no configuration required.

Cloudsmith checks every supported package against trusted threat intelligence at upload and every five minutes thereafter. This continuous package enrichment loop matches newly identified vulnerabilities against your existing artifacts in near real time, eliminating the need for manual rescans.

Packages are matched to malicious package advisories on a shared package URL (PURL). Cloudsmith extracts the PURL at sync (for Docker, component PURLs come from the SBOM), and OSV.dev advisories carry the PURLs of affected packages and versions. The match happens wherever the two share a PURL.

Supported formats

* Supported package formats only

Reviewing vulnerability detections

You can view vulnerability detections via the Cloudsmith web app and API.

Via the Cloudsmith web app

If a package is detected as vulnerable, it will show with the Issues status alongside a count of detected vulnerabilities on the package Overview tab. To see more information about the detected vulnerabilities, click the Vulnerabilities found card or the Compliance tab for the package:

Any packages detected as vulnerable are also listed on the workspace and repository Compliance tabs:

You can filter and search for packages detected as vulnerable using the package search syntax with the search term vulnerabilities:>1. You can also search for packages impacted by a specific CVE record using the vulnerability_id search term and a specific CVE ID.

Via the Cloudsmith API

You can use the Cloudsmith vulnerabilities API endpoints to return the details of any package detected as malicious for an entire workspace, a specific repository, or an individual package. For details, see:

• Workspaces Vulnerabilities Package List
• Workspaces Vulnerabilities Repo Packages List
• Packages Vulnerabilities Count List

Understanding vulnerability records

Cloudsmith uses a primary record selection algorithm to reduce duplicate vulnerability records and return the most authoritative result for each underlying vulnerability.

Benefits of primary record selection

OSV.dev aggregates vulnerability records from many upstream public databases and lists each upstream record separately, without designating one as canonical. The same underlying vulnerability often appears in multiple databases. A vulnerability in a Python package, for example, can have one record in the GitHub Advisory Database and a separate record in the PyPA advisory database (PYSEC), both describing the same issue.

Without deduplication, this would inflate the number of vulnerabilities reported against a package and add noise to compliance reviews. Primary record selection collapses these duplicates so that each unique vulnerability is represented once, with metadata drawn from the most authoritative source available.

How records are grouped

OSV.dev links records that describe the same vulnerability through its aliases and upstream relationships. Cloudsmith uses these links to group such records together, and identifies each group by its CVE where one exists (otherwise by its GHSA, or failing that, the record's own identifier). The CVE is used as the group's stable identity even when a more descriptive record is chosen for display.

A single advisory that addresses several distinct vulnerabilities (for example, a distribution advisory that fixes multiple CVEs) joins each of those vulnerabilities' groups, so genuinely separate issues are never merged into a single advisory.

The record Cloudsmith displays for a group is always one that actually applies to the package. Deduplication never hides the only applicable record in favor of one that does not apply.

How the priority order works

For each group, Cloudsmith shows the primary record: The most authoritative record present in the package, in the following priority order, from highest to lowest.

A group is identified by its CVE, but a richer source such as a GHSA is preferred over the bare CVE when deciding which record's details to display.

Tiebreakers within a priority level

When two or more records in a group share the same priority level, and both apply to your package, Cloudsmith picks the one with the lowest (alphabetically first) identifier as the primary record. This is deterministic and stable; for example, if RHSA and RHBA both apply and no higher-priority record is present, RHBA is chosen.

In practice, these ties only arise between records from the same ecosystem, because vulnerability matching is scoped to the package's ecosystem. A Red Hat package can match several Red Hat advisories at once (for example, RHSA, RHBA, and RHEA), so the lowest ID is chosen; but a PyPI package only ever matches its PYSEC record, and a Rust crate only its RUSTSEC record. Even though PYSEC and RUSTSEC share a priority level, they never appear on the same package, so they never tie. Each group is represented by a single record on any given package.

What primary records drive

The primary record is used to determine:

• Threat level: The threat level displayed for the vulnerability in the package. If the same vulnerability has different severities across upstream records, Cloudsmith uses the severity from the primary record.
• Metadata: The metadata displayed alongside the vulnerability includes affected version ranges and fix information.

Displayed advisory identifier

The advisory identifier displayed in the web app and Cloudsmith API is determined separately from primary record selection. When a CVE identifier is available for a vulnerability, Cloudsmith displays it as the top-level ID, as CVE is the industry-standard identifier for vulnerabilities.

If no CVE identifier exists (for example, for a GHSA record that has not been assigned a CVE, or for distribution-specific identifiers that OSV.dev synthesizes, such as DEBIAN-CVE), Cloudsmith displays the identifier from the primary record instead.

Threat level ordering

By default, packages are sorted by severity (highest first) in the workspace and repository Compliance tabs. The severity, or threat level, is calculated as follows:

1. Identify the package's records: Threat level is calculated across all malicious packages and vulnerability records currently associated with the package.

2. Determine the maximum severity: Cloudsmith takes the highest severity reported across the package's records as the primary ordering value. Severity tiers, from highest to lowest, are: Malware, Critical, High, Medium, Low, and Unknown.

   Malicious package records are treated as the Malware tier and sorted above all CVE-based severities, regardless of how the source advisory categorizes them.

3. Apply tiebreakers tier by tier: Where two packages share the same maximum severity, Cloudsmith compares the count of records at that tier. If those counts are also equal, it drops to the next tier down and compares again, continuing until a difference is found.

Example

Given the following packages:

• Package A: 1 Critical, 3 High
• Package B: 0 Critical, 5 High
• Package C: 1 Critical, 1 High
• Package D: 1 Malware record

The expected sort order is D, A, C, B:

• D is first because Malware is the highest tier.
• A and C both have 1 Critical (tied at the maximum tier). The comparison drops to High, where A has 3, and C has 1, so A is sorted above C.
• B is last because its maximum severity is High, below the Critical tier that A and C share.

Updated 55 seconds ago