> 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/software-supply-chain-security/supply-chain-attacks/tenant-ui-workflow.md).
# Tenant (UI) workflow
The Console workflow has two entry points that converge on the same assess-then-act path. Proactive alerts on the **ASPM** **Command Center**, the dashboard they already land on, and pivots into the attack from there. Alternatively, the practitioner opens the **Supply Chain Attacks page** directly to check the catalog on demand. Either way, the flow then converges: assess whether the organization is exposed, prevent reintroduction (Block in CI), and remediate the existing footprint.
## Start from a Command Center alert
The ASPM Command Center is the proactive entry point: it surfaces supply-chain attacks the moment the practitioner lands on the dashboard, without navigating to the Supply Chain Attacks page first. Two surfaces drive this entry:
* **Breach notification banner**
When a major supply-chain breach affects the environment, a breach **banner** appears on landing on the ASPM Command Center. The banner is prefixed **New Security Breach**, shows the breach name (for example, `Shai-Hulud v1 & v2`), and carries an **Immediate Action Required** indication. The banner appears only while the organization is exposed to a recent breach (discovered within the last 90 days) and until the user dismisses it.
1. Select **View Details** on the banner. Expected outcome: The attack sidecar opens for the breach, so you can assess exposure and act immediately — continue at Assess exposure to an attack.
2. Alternatively, select **Dismiss** to hide the banner. Expected outcome: The banner is hidden for the dismissing user only; dismissal is persisted per user and per attack, so other users continue to see the banner until they dismiss it themselves.
* **Latest Supply Chain Attacks widget**
The Command Center also includes a **Latest Supply Chain Attacks** widget that surfaces the most recent supply-chain attack by date, with its name, per-tenant exposure state (for example, **Not detected in your organization** when the tenant is not exposed), and open-issue counts by severity. Select **View all attacks** to open the Supply Chain Attacks page.
NOTE: When multiple attacks are active simultaneously, their banners stack, newest at the top. A banner remains as long as the organization is still exposed to the attack, while an unhandled CVE, compromised package, or compromised tool is present, and until the user dismisses it.
## Find an attack on the Supply Chain Attacks page
Use this entry point to check the catalog on demand, for example, to confirm whether the organization is affected by an attack reported elsewhere.
#### Step 1: Access the Supply Chain Attacks page
1. Navigate to **Modules** > **Supply Chain Security** > **Supply Chain Attacks**.\
Expected outcome: The Supply Chain Attacks page displays the curated attack catalog, ordered by discovery date, newest first.
2. Use the **search** bar to match against the attack **name** and **description**, or apply **filters** to narrow the catalog by attack attributes.\
\
**Example**\
Filter **Compromised** to **Yes** to show only the attacks your organization is exposed to, or filter **Attack Source** to **Malicious Package** to show only malicious-package incidents. Combine filters into logical groups — within a single group, filters use AND logic; between groups, OR logic applies. For example, one group of `Compromised = Yes` AND `Attack Source = Malicious Package`, combined with a second group of `Related CVE contains CVE-2025`, returns attacks that are either a compromising malicious package *or* linked to a 2025 CVE.
**What happens next**
The catalog shows the attacks that match the search and filter criteria, still ordered by discovery date, newest first. Each row answers, am I **affected?** at a glance through the **Compromised** indicator — **Compromised** (red) when the organization is exposed within the viewing user's SBAC scope, or **You are not compromised** (green) when it is not, alongside the attack name and description, **Attack Source** badge, **Open Issues** and **Issues resolved** counts, **Compromised packages** and **Compromised assets** counts (when compromised), **Detected** and **Updated** dates, and the **Open Blog Post** reference link.
NOTE: When an attack has no compromised packages, no compromised tools, and no related CVEs present in the environment, the row shows the **You are not compromised** indicator and presents a clear empty state rather than implying exposure. The empty state is a normal condition, not a defect. For the complete list of filters and their operators, see Reference A: Supply Chain Attacks filters.
#### Step 2: Assess exposure to an attack
Determine whether the organization is exposed, and where, before acting. The assessment happens in the attack sidecar and the asset surfaces it links to.
1. Select an attack row.\
The attack sidecar (the contextual panel for the selected attack) opens without navigating away from the page. When exposure data is available within the user's SBAC scope, the sidecar presents the impacted-asset counts; when no exposure is detected, the sidecar presents a **no exposure detected** state.
2. Read the sidecar to understand the attack and its blast radius.\
The sidecar is organized top to bottom into: the **Attack summary** (name, **Attack Source** badge, description, **Open Blog Post** link, and a metadata block with **First Detected**, **Updated on**, related **CVE** identifiers, and **Issues** and **Findings** counts by severity); **Compromised Packages** (the compromised OSS packages and supply-chain tools found in the org, with a **View compromised packages** link); **Impacted assets** (the exposure counts); and **Recommended actions** (prevention-first — Block in CI, then remediation).
3. In the **Impacted assets** section, select a count to pivot to the exact assets to investigate. Each count links to its asset surface, pre-filtered to the selected attack:
| Impacted asset count | Links to | Use it to |
| -------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Business Critical Apps** | The affected business-critical applications | Gauge blast radius against the organization's most important applications first |
| **CI/CD Pipelines** | The **CI/CD Pipelines** surface, filtered by the selected attack | Identify which pipelines build from an affected repository or run a compromised tool, and are candidates for Block in CI |
| **Repositories** | The **Repositories** surface, filtered by the selected attack | Identify which repositories contain the compromised package or tool and pivot to their findings |
| **Images** | The affected container/VM images | Confirm whether a compromised package reached a built image, and whether that image is deployed |
**What happens next**
With exposure confirmed and the affected assets identified, act on the attack, prevent reintroduction first (Block in CI), then remediate the existing footprint.
NOTE: All counts and links respect SBAC; they reflect only assets within the user's application scope. See SBAC. Affected assets deployed to a running environment carry a **deployed** indicator on the asset surface; prioritize remediation of deployed assets first.
NOTE: Enrichment cascades an attack across the full Code-to-Cloud asset graph. A **compromised package** traces to the **repositories** that own it and the **images** that contain it; a **compromised tool** traces to the **pipelines** that run it; repositories and images then trace to their **pipelines** and **business applications**. For an attack whose only affected component is a compromised **tool**, the attack produces **no findings** (tools do not generate findings in this release) and exposure surfaces through impacted **pipelines**. Refer to Reference B: Exposure determination matrix.
#### Step 3: Block a compromised package in CI
**Block in CI** converts the selected attack into an enforced Application Security policy that blocks the compromised package, by its exact name and version, at the CI stage. Blocking at CI stops the compromised package from re-entering the pipeline before it reaches a protected branch or a build artifact.
**Prerequisites:**
* A CI integration capable of receiving the block policy
* The AppSec role (policy-generation permission)
1. In the attack sidecar, locate the **Recommended actions** section and select **Block in CI** (also labeled **Block Now**) next to the compromised package.
* Failure: If the control is not visible, the signed-in role does not have policy-generation permission. A user with the **AppSec** role must perform the action. Refer to RBAC.
2. Review the **confirmation prompt**. Expected outcome: The prompt states which compromised package, by name and version, and which attack context will be enforced. The prompt opens before any policy is created, so no change is applied until the action is confirmed.
3. Select **Confirm**.\
Expected outcome: The action submits the block request with the attack context (attack identifier and the affected package). The control enters a loading state while the request is processed.
* Expected outcome (success): Cortex Cloud generates the prevention policy that blocks the compromised package by name and version in CI, and the sidecar presents a **success notification**. The control becomes disabled to prevent a duplicate block
* Failure: If the request fails, the sidecar presents an **error notification with a retry option**. Select **Retry** to resubmit. If the failure persists, confirm that a CI integration is configured for the target scope
4. Confirm the resulting policy on the policy surface. The generated policy enforces against the compromised package at CI; from this point the package is blocked on subsequent pipeline runs within the policy scope.
**What happens next**
The Block in CI policy enforces at the CI stage on the next pipeline run within scope. A pipeline that attempts to introduce the blocked package, by the blocked name and version, is stopped at CI, preventing the compromised package from progressing to the protected branch, the build, and ultimately runtime. This is the prevention-first response to the attack; the upgrade-or-remove guidance addresses package instances that already exist in the environment.
#### Step 4: Remediate an attack
Remediation of an attack runs on two levels: remediate the compromised **package**, and remediate the **issues** the attack generated. Both actions start from the attack sidecar and address the footprint that prevention (Block in CI) alone cannot remove.
1. **Remediate the package.** For instances of the compromised package that already exist in the environment, the sidecar presents plain-text guidance to **upgrade to a safe version or remove the package**. This guidance addresses the existing package footprint directly
2. **Remediate the linked issues.** The sidecar and the attack row surface the open **Findings and Issues** the attack is responsible for, counted by severity:
1. In the attack sidecar, review the **Issues** count in the attack metadata, or select the **View compromised packages** or issue affordance to open the linked issues.
2. Select a linked issue.\
Expected outcome: The issue opens in the standard Application Security issue view, where the issue carries a **Supply Chain Attacks** association.
3. Remediate the issue through the standard Code-to-Cloud issue-remediation workflow, assign the issue, apply the fix, and track resolution against its SLA and Urgency.
> NOTE: Issues generated from supply-chain attack findings receive **Urgency** classification through the standard Application Security pipeline when they match an active Unified Application Security Policy with a **Create Issue** action. Prioritize remediation by Urgency level, utilizing scores derived from key asset attributes such as deployment status, internet exposure, and business criticality.
**What happens next**
Track closure of the attack through both the package footprint and the linked issues. When no compromised package, tool, CVE, or open issue remains, the sidecar presents the **no-longer-exposed** state, confirming the attack is no longer active in the environment.
---
# 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/software-supply-chain-security/supply-chain-attacks/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.