When a major software supply chain attack is discovered, security teams immediately need to know whether they are affected. As Frontier AI accelerates development and expands the volume of software creation, attackers have more opportunities to poison the supply chain pipeline by targeting the tools, systems and 3rd party components developers rely on. In 2025 alone, malicious open-source packages increased by 75%, while the share of breaches involving third-party environments doubled.
And if the first time your organization learns about an emerging supply chain threat is on X, you may already be behind. The challenge is determining whether the affected package, tool or dependency is already present in your environment, where it is being used, which objects in the environment it poisons and how far the exposure extends.
Responding to these attacks remains difficult. Software supply chain compromises take an average of 267 days to identify and contain, and when a compromise results in a data breach, average costs of handling it including the incurred damages can reach approximately $4.91 million.
Answering the critical question — Are we exposed? — often requires security teams to first understand how the attack works, which packages or tools are affected and what indicators to look for. They then have to manually trace those indicators across repositories, dependencies, pipelines and production environments to determine where exposure exists.
The new Supply Chain Attacks Portal in Cortex Cloud is designed to simplify that process by connecting intelligence about emerging software supply chain attacks directly with the software assets in an organization’s environment.
Turning Threat Intelligence Into Environment-Specific Context
When a new supply chain attack emerges, security teams first have to assemble the research needed to understand it, whether through internal threat researchers, public disclosures or a third-party incident response firm such as Palo Alto Networks Unit 42.
From there, teams need to identify the affected packages, tools and versions, understand the indicators associated with the attack, and determine whether those components are present in their repositories, pipelines or production applications.
The Supply Chain Attacks Portal brings that information into Cortex Cloud so teams can investigate an emerging attack without first piecing together research and translating it into separate searches across their environment.
Investigating an Attack From a Single Starting Point
The Supply Chain Attacks Portal organizes investigations around the attack rather than an individual finding. Each entry provides details about the campaign, including compromising packages and tools, related vulnerabilities, references and other information needed to understand the threat.
Cortex Cloud then automatically searches for those components in the organization’s environment. For malicious and vulnerable packages, it identifies affected repositories, business applications and images. For compromised tools, it identifies impacted pipelines and investigates where the exposure may extend.
With the Supply Chain Attacks Portal, security teams can move directly from a newly disclosed attack to remediation. Cortex Cloud automatically determines the attack’s blast radius, surfaces affected assets and links teams directly to the relevant assets for action—eliminating hours or days of manual investigation and correlation across separate security tools.
Understanding Where Exposure Leads
Finding an affected component does not necessarily tell a security team how urgently it needs to be remediated.
A compromised dependency in an inactive repository carries a different level of risk than the same dependency supporting an application currently running in production. Responders need enough context to understand where an affected component sits within the broader software lifecycle.
Security teams can use software package inventory, dependency relationships and Code-to-Cloud context to investigate those connections. Teams can determine where a package appears, understand its relationship to the repository that contains it and follow development context toward the artifacts and cloud assets associated with that software.
For a campaign involving dozens or hundreds of malicious package versions, that context helps teams move beyond searching for package names. Responders can focus on the exposures connected to applications and environments that matter most.
A faster understanding of those relationships becomes increasingly important as the number of software supply chain threats grows. Security teams cannot afford to treat every new campaign as an entirely new discovery exercise.
Moving From Exposure to Prevention
Identifying where an attack has reached the environment addresses only part of the response. Teams also need to reduce the chance that the same compromised component will continue entering the development process.
For supported compromised packages, the Supply Chain Attacks Portal includes “Block in CI”, which allows teams to immediately create a policy targeting the affected packages (names and versions). A newly identified malicious component can therefore become an input into preventive controls rather than remaining only an item for investigation and remediation.
Connecting those workflows helps close a common gap in supply chain incident response. One team may be focused on locating and removing existing exposure while developers continue building software. Without a corresponding prevention control, the same compromised dependency could be introduced again while remediation is still underway.
A more effective response connects each stage: understand the attack, identify affected assets, investigate where the exposure leads, remediate what is already present and prevent known compromised components from being introduced again.
The goal is to reduce the amount of time between learning about a new threat and applying that intelligence to the environment.
Expanding Software Supply Security to The Developer Endpoint
Software supply chain attacks can also begin before code reaches a repository or pipeline. Developers install IDE extensions, command-line tools, open-source packages and AI-powered development tools directly on their endpoints, often granting those tools access to source code, credentials and development infrastructure.
Developer endpoints therefore represent an increasingly important part of the supply chain security model.
Palo Alto Networks’ acquisition of Koi expands our ability to address that part of the development environment. Koi provides visibility and protection for software and agentic tools operating on endpoints, including the tools and extensions used by developers.
As Koi technology is integrated more broadly across Palo Alto Networks, an opportunity emerges to connect developer endpoint context with the software supply chain context already available in Cortex Cloud. Over time, a more complete view could help defenders understand how an attack affects the entire development SDLC: the developers’ workstations (endpoints), the source code on the Software Control Management (SCM) systems, the CI/CD orchestration systems and their associated pipelines, the created images pushed to the Artifact Registries, and eventually the cloud runtime.
Such an approach reflects how modern supply chain attacks already operate. Attackers can move across several stages of software development without respecting the boundaries between endpoint security, application security and cloud security. Defenders need context that can follow the attack across those same stages.
Making “Are We Exposed?” Easier to Answer
More threat intelligence alone will not solve the software supply chain security problem. Security teams need a faster way to understand how newly discovered attacks relate to the software they build and run.
The Supply Chain Attacks Portal brings emerging attack intelligence together with environment-specific exposure, software relationships and prevention controls. Security teams can investigate a campaign, determine whether affected components are present, understand where those components may lead and take steps to prevent known threats from entering the development process again.
As supply chain attacks become more frequent, the ability to make those connections quickly will matter as much as the ability to detect the underlying vulnerability or malicious package.
When the next major campaign emerges and someone asks, “Are we exposed?”, security teams should be able to answer with the context already available in their environment.
Learn More
Learn more about Software Supply Chain Security in Cortex Cloud, explore the latest capabilities, and request a demo to see how Cortex Cloud helps you build trust into your software supply chain.