Open-source software (OSS) has become strategic infrastructure: a shared and often irreplaceable input underpinning government services, financial systems, logistics networks, and segments of the defense technology base. Beyond the direct use of OSS, its strategic significance stems from the software supply-chains it underpins and on which organizations and individuals depend (see Fig. 1). In fact, according to recent large-scale audits, 96% of commercial applications’ codebases contain open-source code, putting OSS at the heart of digital systems across the globe. That dependence creates a new avenue for geopolitical leverage: actors able to compromise or control widely reused software components can impose risks across multiple sectors and jurisdictions.

Figure 1: The numbers show the rapid growth in the adoption of open-source software (OSS) as a component, dependency, or simply by including individual files in other codebases.

While the SolarWinds attack in 2020 and the discovery of Log4Shell in 2021 heightened attention to the geopolitical implications of software supply-chain risk, it was the 2024 XZ incident that marked a watershed moment in the threat posed by upstream compromise attacks, demonstrating a highly sophisticated, multi-year supply chain attack. Yet, outside specialist IT and cybersecurity circles, the incident has received comparatively limited attention. Unidentified actors inserted malicious code into the official release of XZ Utils, a little-known but widely used software package, with the apparent aim of indirectly compromising the SSH protocol for encrypted remote access through a trusted upstream dependency.

Since the XZ incident, upstream dependency attacks have remained a live and widening risk. In late March and early April 2026, Google and Microsoft attributed the supply-chain compromise of the widely used Axios OSS package to North Korea-linked actors. Much like XZ, the Axios incident shows that a piece of OSS that sits inside a widely trusted software distribution chain can propagate malicious code downstream at scale.

As such incidents accumulate, software provenance, assurance, and enforceable security obligations are becoming instruments of geopolitical power, shaping market access, procurement rules, and cross-border interoperability. The EU is at the forefront of this shift through the Cyber Resilience Act, which imposes mandatory cybersecurity requirements across the lifecycle of products with digital elements. Other jurisdictions are also tightening software supply-chain oversight, though through less targeted instruments: South Korea issued software supply-chain security guidance aligned with foreign SBOM requirements, the UK introduced a Cyber Security and Resilience Bill focused on essential services and digital infrastructure, and China’s amended Cybersecurity Law strengthened enforcement and state oversight. In practice, actors able to set compliance baselines, assurance requirements, and reporting standards for software security will increasingly shape market-entry conditions, public procurement choices, and the terms of interoperability across jurisdictions. That political leverage depends increasingly on the ability to demand credible evidence of how software was built, from which source, and under what controls.

The CPE Framework: Capture, Poison, Exploit

Upstream supply-chain attacks involve the direct manipulation of software or its delivery mechanisms, rather than the exploitation of an ordinary flaw in otherwise legitimate code. These incidents risk supply-chain attacks involving broader downstream exposure than conventional exploits because a compromise introduced upstream may propagate across many dependent systems at once. The risk created by upstream compromise lies in the depth and opacity of modern dependency chains. Recent large-scale audits found that the average evaluated application contained hundreds of open-source components (see Fig. 1), of which 64% were transitive. Hence, a compromise introduced upstream can spread far beyond the code directly visible to developers. Given that 2024 recorded a 156% year-on-year increase in detected open-source malware, CPE attacks should not be treated as isolated anomalies, but seen as part of a broader deterioration in the software supply-chain threat environment. Rather, the more useful approach is to distinguish three recurring and interoperable vectors of OSS-related compromise and strategic risk: capture and poison at the upstream level, and exploit at the downstream level (CPE).

Capture refers to the compromise or manipulation of project governance, maintainer authority, or release control so that malicious changes are introduced under the appearance of legitimacy. Here, the objective is not merely to poison a package, but to gain or manipulate the authority that allows a malicious release to appear routine and legitimate. An actor that acquires, coerces, or otherwise secures sufficient project access can insert malicious code into upstream dependencies and rely on trusted release processes to carry that compromise into downstream systems. Such attacks highlight that institutional pathways matter as much as technological ones: control over who can approve changes, publish releases, and confer trust is itself a strategic vulnerability.

Poison consists of attacking target systems indirectly through the software distribution layer, including package registries such as npm for JavaScript and PyPI for Python, as well as other automated installation and update mechanisms. In this way, long-trusted and otherwise legitimate installation and update procedures become hard-to-detect delivery mechanisms for malicious code. In late March 2026, an attack traced back to hacker groups with ties to North Korea involved the publication of two malicious Axios package versions to npm, allowing malware delivery through a widely trusted software distribution channel. Such attacks illustrate one of globalization’s security externalities: installation of OSS through open distribution channels can transmit compromise across jurisdictions and sectors through routine automated installation and update processes.

Exploit refers to the downstream use of a known weakness against organizations that fail to patch, mitigate, or isolate affected systems in time. A vulnerability in a widely deployed OSS component, whether discovered opportunistically or introduced upstream, can be exploited against systems that do not apply patches or workarounds long after it is publicly acknowledged (see Fig. 2). For instance, the US Cybersecurity and Infrastructure Security Agency (CISA) warned that malicious actors continued exploiting the Log4Shell vulnerability in unpatched systems, illustrating how delayed remediation can extend the life of a widely known vulnerability. Geopolitically, this vector matters because it exposes differential resilience: jurisdictions and sectors with slower upgrade cycles, weaker asset visibility, and deeper dependence on legacy systems are structurally more vulnerable to prolonged exploitation.

Figure 2: Almost all applications include OSS components, but most of them are more than 10 versions behind the most current version OSS releases.

Taken together, capture, poison, and exploit show that the strategic significance of OSS lies not in any single vulnerability, repository, or maintainer, but in the concentration of trust within the governance, maintenance, and distribution systems on which the wider digital economy depends. Exploit reveals uneven resilience across jurisdictions and sectors; poison shows how globally shared distribution channels can transmit compromise at scale; and capture demonstrates that governance and release authority are themselves strategic assets. Considered together, these vectors make clear that open-source risk is systemic rather than episodic: strategic power lies not only with those who can write or break code, but also with those able to shape the standards, institutions, and dependency chains through which trusted software is maintained, distributed, and secured. In that sense, OSS has become strategic infrastructure because geopolitical contestation increasingly turns on who can govern, secure, and control the trust relationships embedded in software ecosystems.

The XZ backdoor: A Multi-vector CPE Attack

The XZ attack did not first appear as an obvious breach; instead, it revealed the strategic significance of a CPE attack that combined compromised governance, poisoned release artefacts, and downstream exploitation (Fig. 3). The first signs were subtle and easy to dismiss, emerging only after the compromise had already moved through trusted upstream development and release channels. By that point, both the upstream XZ repository and the official release had been ‘backdoored’, allowing malicious code to travel through trusted distribution paths into downstream systems.

Figure 3: A schematic of the XZ CPE attack highlighting each vector: how attackers built trust around the JiaT75 account to capture maintainer access, then poisoned official XZ releases, and finally leveraged downstream package updates to backdoor users’ SSH connections.

That matters because the compromise did not depend on an end user error or on the opportunistic exploitation of a routine flaw. It relied instead on the cultivation of trusted status within the project: building credibility over time, contributing consistently, and using social pressure to expand influence over maintenance and release decisions. That sustained investment in both software and social engineering was worthwhile because maintainership is a strategic form of authority in OSS: it shapes what code is accepted, what releases are treated as legitimate, and what changes propagate through wider software supply chains.

The attackers appear to have captured control over XZ’s development through a mix of impatience, reputational nudging, and at times overt pressure on XZ’s long-time maintainer, Lasse Collin. By early 2024, the user operating as ‘Jia Tan’ had gained enough standing to function as the project’s new maintainer in practice. At that stage, the conditions for poison and exploit had been assembled for the deployment of a backdoor. Crucially, ‘hacking’ in the narrow sense was enabled by pervasive maintainer scarcity and decentralized release authority. Those institutional factors allowed a malicious actor to acquire influence over the development and release of a key upstream OSS dependency.

The technical execution reinforced the same strategic logic and highlighted the interoperability of CPE techniques. The attackers did not merely hide malicious code in publicly visible project materials, they also manipulated the release process so that end users received software instructions not present in the open-source codebase. Just as importantly, the malicious logic was tuned to activate only under specific installation conditions, targeting x86-64 Linux environments systems widely used in server and desktop environments. In effect, the operation was designed so that the repository and the release path did not present the same effective behavior, leaving downstream users exposed through trusted packaging and distribution channels.

XZ itself is only a compression utility, but its strategic value lies in the depth of modern dependency chains. As shown in Fig. 1, contemporary software stacks often rely on vast numbers of upstream components, many of which are transitive rather than directly visible to developers. That is what made XZ consequential: a compromise in a relatively obscure upstream component could reach systems relying on SSH for remote access, despite XZ rarely being the focus of direct scrutiny. The same structural logic appeared to the Log4Shell vulnerability, with more than 80% of affected packages depending on the compromised OSS indirectly and a majority only needing it as a fifth-order dependency. These cases show that CPE operations are becoming a modular way of reaching high-value targets through trusted but weakly understood dependencies that are widely reused across software environments.

More than two years after the XZ disclosure, there is still no public authoritative attribution of the operation to a specific state actor. Senior researchers described the operation’s multiyear patience and technical sophistication as consistent with a state-backed effort. Some experts have speculated that the hacker group APT29, linked to Russia’s Foreign Intelligence Service, is the likeliest culprit. Nevertheless, that remains an unproven conclusion, and multiple states possess the necessary resources and capabilities, including China and North Korea. Beyond attribution, the more important point is that XZ demonstrated how a combined, multivector CPE attacks, can be directed at OSS components underpinning key digital infrastructure.

The damage remained limited largely because the compromised versions were detected before they were widely deployed in production systems. The compromised XZ versions had not yet been widely integrated into production Linux distributions when the attack was disclosed, though they had entered testing, unstable, experimental, and other pre-release channels. However, the affected versions were available through pre-release and development channels, prompting distributors to revert packages and rebuild affected software packages to prevent automatic installation of the compromised code.

It was therefore a close call, and not obviously an unrepeatable one. The XZ playbook leverages persistent weaknesses in the OSS ecosystem: chronic maintainer scarcity, the legitimacy conferred by long contribution histories, and the habit of treating upstream release artefacts as trusted inputs. Overall, XZ offered an early warning of a broader strategic contest over OSS, showing how CPE operations can leverage governance weaknesses and weak assurance practices to capture critical software dependencies, poison the software supply chain, and carry out exploits against downstream users.

The Appeal of CPE Attacks to State Actors

State actors are drawn to CPE attacks for three interrelated reasons. First, they offer favorable cost asymmetries by allowing influence over a single upstream position to generate defensive burdens across entire software ecosystems. Second, they create strategic optionality by enabling pre-positioning that can be activated later for intelligence, disruption, or coercion. Third, they exploit the interdependence created by shared OSS dependencies, allowing compromise to generate cross-border effects in allied and rival economies alike.

Coming to the first set of incentives, CPE attacks are best understood as an investment decision under conditions of attacker-defender cost asymmetry. In classic intrusion campaigns, the attacker pays per target: reconnaissance, access, persistence, and evasion repeated across organizations. Supply-chain compromise through OSS ecosystems flips that equation. The attacker pays to obtain or influence a single piece of upstream OSS through maintainer authority, poisoning of a build pipeline, or manipulating a release artefact. Defenders, by contrast, inherit recurring verification costs across entire ecosystems: provenance checks, dependency audits, incident response across downstream users, and long-tail remediation once the compromised component has propagated through transitive dependencies. Increasingly, trust in OSS maintainers, suppliers, and release channels is becoming a standing national-security concern rather than a niche IT issue.

The second incentive is strategic optionality through pre-positioning. Upstream access is a strategic asset even when it is not immediately used as it preserves future choice: intelligence collection in peacetime, disruption in crisis, or coercive leverage over exposed sectors. That is why multi-vector CPE operations like the XZ attack remain strategically attractive even when their immediate payoff is uncertain. Their value lies in preserving the option to trigger downstream effects later, selectively, and against targets of greater strategic consequence.

Third is interdependence. The same broad set of open-source dependencies runs through allied and rival economies alike because OSS functions as a shared industrial input. That means compromise can generate transnational risk by eroding trust, disrupting commerce, and reshaping procurement, assurance, and compliance decisions across borders. The growing emphasis on software transparency, including SBOMs as a formal ‘ingredients list’ for software components, is therefore more than a technical best practice. It is an attempt to make software composition and dependency relationships legible across jurisdictions so that states and large organizations can more effectively govern shared supply-chain risk.

Software Trust: From Volunteerware to Strategic Infrastructure

Maintainer scarcity is no longer just a community-management problem; it is a security externality with broader economic and national-security consequences. The Linux Foundation’s Census II spells out the structural issue: OSS is a critical part of the modern economy, yet it is produced in a decentralized and distributed manner, with no central authority to ensure the quality and maintenance of all projects, making it difficult to know what is most widely used and how well supported it is. Concretely, among 47 leading OSS projects, 81% had fewer than ten individuals accounting for more than 80% of the work and 40% had no more than two main developers. That creates incentives to capture the maintainer authority hold by one person rather than a whole platform. Stewardship and funding are not charity; they are forms of systemic risk reduction for the digital industrial base, because weaknesses in heavily reused components propagate far beyond the projects in which they originate.

Some governments are beginning to act on that logic moving beyond passive dependence on OSS and towards active stewardship of this shared industrial input. In Germany, that shift takes the form of direct public investment allocated through the Sovereign Tech Fund and designed to improve the security, stability, and reusability of critical open digital infrastructure, paired with a resilience program focusing on vulnerability prevention, audits, bug handling, and reducing the risk of severe flaws. France illustrates a sovereignty-oriented variant of the same logic, with state-financed and sponsored OSS acting as a central element of France’s digital-sovereignty agenda. Similarly, Japan is framing OSS more explicitly as a foundation of technical autonomy and software modernization while presenting support for participation in, and cultivation of, the OSS ecosystem as part of a broader national capability-building effort. Taken together, these approaches suggest a wider geopolitical shift: OSS’s sustainability is no longer being treated solely as a matter of community goodwill, but increasingly as a question of resilience, sovereignty, and strategic investment.

Provenance is emerging as the next arena of power because it determines whose software can be trusted, verified, and admitted into procurement and assurance regimes. The decisive question is who can generate and verify credible evidence of what software was built, from which source, and through which build process at scale. Frameworks such as SLSA, Sigstore, and In-toto turn trust from an informal assumption into something that can be evidenced, checked, and enforced across the software supply chain. They are not just technical tools; they are emerging infrastructure through which states, regulators, and large organizations can make trust claims more enforceable in OSS. Once such trust claims become technically verifiable, regulation and procurement can turn them into enforceable conditions of market access, supplier eligibility, and public-sector assurance. In that sense, provenance tools matter not only because they improve software integrity, but because they supply the evidentiary basis through which states and large organizations can govern software interdependence.

The second-order risk is fragmentation: as assurance requirements harden, software ecosystems may begin to segment into more curated and jurisdictionally shaped trust environments. Early signs are visible in the shift toward structured software-assurance procurement, repository-security principles, and public-sector catalogues intended to make software supply chains more legible and governable.

Conclusion

Recent incidents, including the CPE operation against Axios in March 2026, show that upstream supply-chain attacks remain an active and recurring risk. They are often deniable, scalable, and leverage a persistent asymmetry in the provision of OSS as a shared industrial input that favors malicious actors. Defenders must repeatedly verify diffuse and decentralized OSS dependency chains, often with incomplete visibility into how components are maintained, packaged, and propagated. Conversely, attackers may need only a single upstream foothold: compromise a maintainer account, a release channel, or an installation step, and then rely on trusted distribution to carry the effect downstream. The compromise of the widely used Axios OSS package distributed through the long-established npm repository showed how quickly a trusted dependency can be turned into a malware delivery channel. Google traced the Axios attack to UNC1069 while Microsoft attributed the compromise to Sapphire Sleet, both are North Korea-linked threat actors.

The implication is that strategic competition is shifting from who can penetrate systems to who can underwrite and verify trustworthy OSS at scale. The key levers are credible build provenance, enforceable security obligations, and sustained stewardship of critical components. Platforms like Github, npm, and PyPI are already implementing provenance attestations, signing infrastructure, and transparency mechanisms that help establish where and how software was built.

The fact that attribution will often remain contested does not diminish the strategic risk: CPE attacks can scale regardless of whether responsibility is ever definitively assigned. The criterion for resilience is therefore not merely more audits, but institutionalized and verifiable trust arrangements that scale across borders and suppliers throughout the OSS supply chain, raising the cost of compromise and enabling rapid containment when compromise occurs.