> 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/tenant-ui-workflow.md). # Tenant (UI) workflow The tenant is the primary channel for reviewing, prioritizing, governing, and tracking malicious packages. #### View malicious package findings Malicious package findings appear in the dedicated **Malicious Packages** section of the Findings page. 1. Navigate to **Modules > Application Security > Issues > Malicious Packages**. 2. Click on the **Findings** tab. 3. Ensure the **Malicious Packages** section is selected. 4. Select a finding to open its side panel and review the package, version, Malware ID, and advisory link. #### View and manage malicious package issues Malicious package issues appear in a dedicated **Malicious Packages** view. 1. Navigate to **Modules > Application Security > Issues > Malicious Packages**. 2. Select an issue to review its description, impact, and resolution actions. 3. Set the **Backlog Status** to record your triage decision and assign ownership, and track the **SLA** to hold the remediation to a deadline (as a confirmed malicious package is an active supply-chain compromise that must not be left unaddressed). NOTE: For the issue description and impact, refer to [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). For Urgency prioritization, refer to the [Urgency documentation](/application-security/application-security-posture-management-aspm/urgency.md). #### Remediate a malicious package Remediation is the goal of the workflow: a confirmed malicious package is an active supply-chain compromise, so the affected dependency must be removed or replaced, not merely acknowledged. Each malicious package issue carries the resolution guidance below in its side panel; work through it in order. 1. **Remove the affected version** of the package from your project. This is the direct fix and is always correct — the flagged version is malicious. 2. **Move to a safe version, if one exists.** Change the package to a version outside the affected range, provided such a version exists and is appropriate for your application. Not every package has a safe version; a package published purely for malicious purposes may have none. 3. **Replace the package** with a trusted alternative if you cannot confidently identify a non-affected version. When the package itself is untrustworthy, substitution is the only durable fix. 4. **Verify no malicious code executed.** Review recent code and build activity to confirm the malicious package did not run in your pipeline or environment — installation alone can execute malicious install scripts, so removing the dependency is not sufficient assurance on its own. After remediating, update the issue's **Backlog Status** to reflect the resolution and confirm the package no longer appears in the next scan. #### Filter assets for malicious packages 1. Navigate to **Inventory > All Assets >** **Software Packages** (under Code). 2. Filter the table by the **Is Malicious** column to filter the display only malicious packages. 3. Select a malicious package to open its **Malicious Code** tab in the side panel, which lists the malware (`MAL-XXXX`) identified for that package and links to the corresponding Malicious Packages issues. The tab appears only when the asset has malicious findings.\ NOTE: The **Malicious Code** tab is also available on the **Repository** asset, where it lists the malware found across that repository's packages. Use the Repository view when you want to assess malicious-package exposure by repository rather than by individual package. #### Review malicious packages in dashboards Malicious package issues are included in the existing Application Security dashboard widgets: **Top Issues to Address**, **Open Issues by AppSec Scanner**, **Open Issues by Severity**, and **Top Repositories at Risk**. Filter these widgets by the **Malicious Packages** scanner. #### Review malicious packages per scan The **Branch Periodic Scans**, **Pull Request Scan**, and **CI Scan** pages in the Application Security module reflect malicious package discovery: 1. Navigate to **Modules > Application Security**. 2. Select the type of scan under **Scans**. 3. Open a scan. 4. Review the **Issues by Type** and **Findings by Type** breakdowns, which include a Malicious Packages indication. 5. Open the **Malicious Packages** tab in the scan side card to review the issues and findings discovered in that specific scan. #### Govern malicious packages with policies Convert detection into prevention by defining Application Security policies that act on malicious packages. Prevention is the primary value: blocking at the pull request stage stops a malicious package from reaching a protected branch. **Start with the out-of-the-box policy** You do not have to build a policy from scratch. Malicious package governance is active through a preconfigured policy: 1. Navigate to **Modules > Application Security > AppSec Policies**. 2. Filter the policies table by **Is Custom = No**. 3. Enable the **Create issues on findings of High and above severity** policy.\ Result: Issues are created for all Malicious package findings with high or critical severity, enabling you to mitigate these risks. **Create a custom policy (optional)** Create your own policy only when the out-of-the-box policy does not fit, for example, to enforce a narrower scope, target specific packages, or use a different trigger or action. 1. Navigate to **Modules > Application Security > AppSec Policies > +New Policy**. 2. Create a policy under **Code & Image Scanners** and select the **Malicious Package** finding type. 3. Optionally add conditions to narrow which malicious packages the policy acts on. Because every malicious package is Critical, most policies need no narrowing and act on all of them; use conditions only when you want a more targeted rule. The available conditions let you target: * **A specific package,** by **Package Name** and **Package Version**. * **The triage state,** by **Backlog Status** (for example, act only on packages that are not yet triaged). * **The package's risk profile,** by **Package Popularity**, **Package Operational Risk**, **Package Maintenance**, and **Package Deprecated**, so you can prioritize malicious packages that are also poorly maintained, unpopular, or deprecated. (**Severity** is also available but is always Critical for malicious packages.) 4. Configure triggers and actions. All triggers and actions available to Code Scanners are supported. Select triggers in shift-left order (PR scan first) so a malicious package is caught as early as possible. 5. Set the policy scope (the same scope model as other Code Scanners) and save. **Caution:** Deleting a policy that created malicious package issues affects the lifecycle of those issues during the next periodic scan. Disable a policy rather than deleting it to retain its existing issues. --- # 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/tenant-ui-workflow.md?ask=&goal= ``` `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.