> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/malicious-packages.md).

# 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](https://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)**](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/tenant-ui-workflow.md)**:** The primary channel for reviewing, prioritizing, governing, and tracking malicious packages
* [**API**](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/api-workflow.md)**:** The channel for external consumers and automation to check package status or query full advisory details outside the Console
* [**CLI**](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/cli-workflow.md)**:** The interface for integrating detection into CI scans and executing on-demand checks for a package's malicious status
* [**Pull request**](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/pull-request-workflow.md)**:** The primary shift-left enforcement point that provides feedback and blocks a malicious package before it reaches CI or deployment
* [**IDE**](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/ide-workflow.md)**:** 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](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/reference-a-workflows.md).

#### RBAC permission levels by capability <a href="#rbac-permission-levels-by-capability" id="rbac-permission-levels-by-capability"></a>

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](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/reference-b-rbac-permission-levels-by-capability.md).

### 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](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/reference-c-supported-ecosystems.md). &#x20;

#### 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](/application-security/software-supply-chain-security/risk-and-remediation/malicious-packages/reference-d-malicious-package-finding-and-issue-fields.md).

#### 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](/application-security/application-security-posture-management-aspm/urgency.md).&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/malicious-packages.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.