Supply Chain Attacks

The Supply Chain Attacks interface is a continuously updated catalog of notable software supply-chain attacks, such as Shai-Hulud, Solarwind Supply Chain Attack and so on, caused by attack vectors such as malicious package injections, CI/CD pipeline compromises, and maintainer takeovers, many of which spread before a CVE is issued.

By correlating each attack entry directly against your organization's business applications, 3rd party software packages (SBOM), repositories, CI/CD pipelines, runtime assets, and development tools in use, the interface immediately identifies exactly where your environment is exposed.

This data delivers faster time-to-assessment and enables a shift-left security approach: you can enforce prevention by blocking compromised packages by exact name and version at the CI stage, stopping reintroduction before they reach a protected branch or build. Simultaneously, you can drive remediation workflows to upgrade or remove compromised instances that have already reached your code, built images, or deployed environments.

NOTE: The Supply Chain Attack Portal comes pre-populated with data from the most high-profile supply chain attacks of the past two years. Upon login, you can instantly see if your environment is exposed to any of these major threats.

Core capabilities

The Supply Chain Attacks experience is structured proactive-first; prevention precedes detection and remediation.

• Prevention (proactive): The Block in CI action converts a curated attack into an enforced policy that blocks the compromised package by name and version at the CI stage, the leftmost enforcement point, before the package can re-enter the pipeline
• Proactive awareness: The Command Center breach banner alerts Application Security users to a high-impact attack the moment they land on the Command Center, with a direct path into the attack sidecar
• Exposure quantification (detection): The Supply Chain attack sidecar quantifies organizational exposure across business-critical applications, CI/CD pipelines, repositories, and images, and links each count to the corresponding filtered asset surface
• Remediation (reactive): Remediation of an attack runs on two levels. At the package level, upgrade-or-remove guidance is provided for compromised-package instances that already exist in the environment. At the issue level, each attack links to the open Findings and Issues it is responsible for; select a linked issue to pivot into the standard Code-to-Cloud issue-remediation workflow (assignment, fix, and SLA/Urgency tracking). Remediation is therefore tracked both against the specific package and against every issue the attack generated

Prerequisites

Prerequisite	Description
Cortex Cloud license	An active Cortex Cloud license with the Application Security add-on license
VCS integration	At least one VCS integration active with repositories onboarded, so that repository exposure can be correlated to an attack
CI/CD integration	At least one CI/CD integration (for example, a Jenkins or CircleCI instance) onboarded, for pipeline exposure correlation
Policy-enforcement entitlement	An Application Security policy-enforcement entitlement and a CI integration capable of receiving the block policy. Required for the Block in CI action
RBAC role	The built-in AppSec Admin role, or a custom role with Application Security read access to assess attacks plus write access to Unified Application Security Policies for the Block in CI action. Refer to RBAC below

RBAC

RBAC controls what a user can do; the Cortex Cloud platform enforces it, not the Supply Chain Attacks feature. Assign roles in Settings > Roles. All roles below have full view of the page, sidecar, and Command Center widget; only the Block in CI action differs.

Role	Block in CI action
AppSec Admin	Full view of the page, sidecar, and Command Center widget, plus the Block in CI prevention action (policy generation)
DevSecOps	No — view only
Developers	No — view only
All other roles	View only, and only for the Application Security surfaces explicitly granted to the role

IMPORTANT: Block in CI generates a policy, so it requires write access to Unified Application Security Policies.

SBAC

SBAC controls which assets a user sees. Exposure counts and the sidecar's linked asset surfaces are scoped to the user's assigned application boundaries, so two users can see different exposure counts for the same attack. The attack entry itself — name, description, affected components, reference link — is identical for all users with view access; only the exposure is scope-dependent.

Core concepts

You need two concepts before you start; the catalog structure and data-freshness timing are lookup material and live in Reference C: Attack catalog and data freshness.

Exposure model

Supply Chain Attacks distinguishes between an attack that is active in the environment (the organization is exposed) and one to which the organization is no longer exposed. The organization is considered exposed when any of the following is present in the environment within the viewing user's SBAC scope: a compromised package associated with the attack, a compromised tool associated with the attack, a CVE associated with the attack, or an open issue related to the attack.

NOTE: For the complete exposure determination logic, see Reference B: Exposure determination matrix.

Prevention-first response

The Recommended actions section of the sidecar is ordered prevention-first. Block the compromised package in CI before relying on manual upgrade-or-remove remediation: blocking in CI is the leftmost enforcement point and prevents reintroduction of the compromised package, whereas upgrade-or-remove addresses instances that already exist.

NOTE: Block in CI operates at the CI stage of the Code-to-Cloud lifecycle. It is a guardrail that prevents reintroduction of a known-compromised component; it does not, by itself, remove instances of the package already present in repositories or running assets — those are addressed through remediation and tracked as issues. See Remediate an attack.

Available workflows

Capability	Tenant (UI)	CLI
View the attack catalog	✓	✗
Search and filter attacks	✓	✗
Assess exposure in the attack sidecar and pivot to impacted assets	✓	✗
Generate the Block in CI policy (AppSec role)	✓	✗
Enforce the Block in CI policy	Platform	✓
View upgrade-or-remove remediation guidance	✓	✗
Discover compromising attacks in the ASPM Command Center	✓	✗
Curate or edit attack entries	Vendor	✗

NOTE: Platform indicates enforcement performed automatically by Cortex Cloud during scans; Vendor indicates content curated by Palo Alto Networks rather than by the customer.

NOTE: The Block in CI action generates a Unified Application Security policy. That policy is enforced at the CI stage on subsequent pipeline runs, including through the Cortex CLI where the CLI is the CI scan mechanism. See CLI workflow and Unified Application Security Policies.