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.

1. 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.
2. 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

1. 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.