> 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.md). # 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. --- # 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.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.