Malicious packages

Malicious Packages detection identifies known-malicious open-source dependencies, including typosquatting, backdoored libraries, hijacked versions, and packages published for credential theft or remote code execution, during SCA scans. Detection matches each SBOM component against the malicious packages dataset published by OSV.dev, Google's open-source vulnerability database, and raises a dedicated, Critical-severity issue for every confirmed match, covering both direct and transitive dependencies and detecting packages that have no associated CVE. These issues are displayed across the platform, including the Console, dashboards, IDE, pull request comments, the CLI, and the public API,and can be governed with policies that block a malicious package before it reaches a protected branch.

Core capabilities

• Detect threats without CVEs: Identify malicious packages that lack a CVE, which traditional vulnerability scanning often misses
• Separate malicious findings: Present malicious packages as a distinct, Critical-severity issue type, kept separate from standard vulnerabilities
• Block malicious dependencies: Create policies to block malicious packages at the pull request or earlier stages, rather than just detecting them after the fact
• Keep data current: Continuously refreshes malicious package data from the OSV.dev dataset, returning a warning instead of stale results if the feed falls behind

Available workflows

The Package Explorer is a read-only discovery and inventory surface. You can interact with and govern malicious package findings through the following primary interfaces:

• Tenant (UI): The primary channel for reviewing, prioritizing, governing, and tracking malicious packages
• API: The channel for external consumers and automation to check package status or query full advisory details outside the Console
• CLI: The interface for integrating detection into CI scans and executing on-demand checks for a package's malicious status
• Pull request: The primary shift-left enforcement point that provides feedback and blocks a malicious package before it reaches CI or deployment
• IDE: The earliest enforcement point, providing real-time warnings to help developers avoid committing unsafe dependencies

For more information about the workflows and workflow capabilities, refer to Reference A: Workflows.

RBAC permission levels by capability

The permission level for each capability (such as findings, issues, policies and so on) is derived from what the action does: actions that only display data require view (read) access; actions that create or change state require view/edit (read/write) access. For more information, refer to Reference B: RBAC permission levels by capability.

Prerequisites

Prerequisite	Description
Cortex Cloud license	Active Cortex Cloud license with the Application Security add-on
RBAC permissions	AppSec Admin role or equivalent custom role. The required permission depends on the action — refer to RBAC permission levels by capability below
SCA scanning	SCA scanning enabled for the target repositories. Malicious package detection runs as part of the SCA scan
VCS integration	At least one VCS integration active with repositories onboarded. Required for PR scan detection and pull request comments
IDE extension (optional)	The Cortex Cloud IDE extension, for in-IDE malicious package warnings
API key (optional)	A valid Cortex Cloud API key with AppSec Admin permissions. Required only for the public API

Core concepts

How detection works

Malicious package detection runs automatically as part of the SCA scan, after SBOM generation (SBOM generation itself is unchanged). Detection matches each SBOM component against the OSV.dev malicious packages dataset, considering the package name, the ecosystem, and the affected version ranges when available. Detection works for both direct and transitive dependencies, and a finding is created even when no CVE exists.

NOTE: For supported ecosystems and their package managers, see Reference C: Supported ecosystems.

The malicious package finding

Each confirmed malicious dependency produces a distinct finding type separate from vulnerability findings. Because malicious packages are always Critical, every such finding is promoted to an issue for you to triage. The finding and its issue share the name Malicious Package in <PackageName> version <PackageVersion>, so you can identify and search for the affected dependency directly in the issues view.

NOTE: For the complete list of finding fields, see Reference D: Malicious package finding and issue fields.

Withdrawn advisories

A package whose OSV.dev advisory has been withdrawn is treated as not malicious and does not produce a finding. A withdrawn advisory indicates the package is no longer considered malicious, for example, the advisory was issued in error or the malicious behavior was remediated.

Intelligence freshness

Malicious package intelligence is refreshed continuously from the OSV.dev dataset, so newly published malicious packages become detectable in subsequent scans without a manual rescan.

If the intelligence becomes stale beyond the configured freshness threshold (default 20 minutes), the scan surfaces a stale-intelligence warning instead of returning outdated results, so a scan is never silently evaluated against out-of-date data.

Urgency classification

Each malicious package issue receives an Urgency level that incorporates Code-to-Cloud deployment context and business criticality. Although malicious packages default to Critical severity, Urgency distinguishes a malicious package deployed in an internet-facing production service from one present only in a development branch.

NOTE: Urgency signals such as Is Deployed and Internet Exposed are derived from the Code-to-Cloud trace; without traceability they display as Not Applicable.

For more information on Urgency, refer to Urgency.