The Trust Model That Was Never Built
Software supply chain compromise, the dual-use AI inflection, and the shared responsibility question for open-source security
Author: Gavin Fitzpatrick Classification: Public Date: June 2026 Companion piece: The Door That Stayed Open (LinkedIn, Part 1)
Executive summary
CVE-2024-3094 was not a vulnerability in a compression library. It was a vulnerability in the trust model that holds open-source infrastructure together. A state-resourced actor spent over two years acquiring upstream maintainer status on xz/liblzma, a library most engineers had never heard of, then shipped a backdoor that landed in the release tarballs but not the git tree. The payload hijacked OpenSSH authentication on most major Linux distributions and granted root-level remote command execution. Detection was an accident. A Microsoft engineer traced a 500-millisecond SSH login delay during unrelated benchmarking and disclosed it before any major distribution promoted the affected versions to stable. The industry called it a near-miss and returned to normal practice inside six weeks.
It was not a near-miss. It was a demonstration. In the eighteen months since, four further campaigns have exploited the same structural failure at progressively compressed timescales: the self-propagating Shai-Hulud npm worm, the North Korean compromise of Axios, the TanStack incident that became the first documented case of malicious packages shipping with valid SLSA Build Level 3 provenance, and TrapDoor, a cross-ecosystem campaign active from 22 May 2026 that introduced two vectors not seen in any prior campaign: exploitation of the Rust build system via build.rs execution in crates.io packages, and deliberate poisoning of AI coding assistant configuration files as a persistence and instruction-injection mechanism. The cadence is accelerating, and the interval between the four most recent campaigns was measured in days.
Three developments between April and June 2026 changed the economics again. On 30 April 2026 the UK AI Safety Institute evaluated OpenAI's GPT-5.5-Cyber and recorded it solving a reverse-engineering task in ten minutes that took a human expert twelve hours. On 22 May 2026 Anthropic published the first results of Project Glasswing, in which Claude Mythos Preview identified more than ten thousand high- or critical-severity vulnerability candidates across over a thousand open-source projects in a single month. On 9 June 2026 Anthropic put Mythos-class capability into general availability as Claude Fable 5, priced at ten dollars per million input tokens, behind classifier-mediated safeguards, with the unfiltered model (Mythos 5) reserved for Glasswing partners and a forthcoming trusted access programme. The same underlying model now sits on both sides of the equation, distinguished by what its safeguards block rather than by who can use it. The difference between offensive and defensive use is no longer the gating of access. It is the durability of the safeguards in front of the public-availability tier, and the UK AI Safety Institute has already made initial progress toward a universal jailbreak.
This paper makes three arguments. First, the technical controls that would have changed the outcome of every campaign in this wave exist today, are operationally inexpensive, and remain rare in practice. Second, the accountability vacuum underneath these failures has a specific shape: open-source software generates trillions in demand-side value while being maintained predominantly by unpaid volunteers, and no shared responsibility model exists to allocate the security cost. Third, the AI capability shift has converted that vacuum from a slow structural problem into an urgent operational one, because the bottleneck in software security is no longer finding vulnerabilities but triaging and patching them faster than a frontier model on the other side can weaponise them.
The shared responsibility model for open-source security needs to exist before the next major incident forces it into existence. At the time of writing, it does not.
Part 1: The attack
1.1 The operation
The actor operated under the pseudonym Jia Tan, username JiaT75. The first commit to xz/liblzma landed on 29 October 2021 and added an editorconfig file. Through early 2022 the account submitted further legitimate patches, and the project's sole maintainer, Lasse Collin, accepted them. Collin had maintained the project as an unpaid side project since 2009 and had discussed his own capacity limits and mental health in public on the project mailing list.
The social engineering ran in parallel and through separate personas. Between April and June 2022, accounts including Jigar Kumar and Dennis Ens applied public pressure on the mailing list, complaining about release cadence and demanding additional maintainers. The pressure campaign weaponised the maintainer's disclosed capacity constraints. On 8 June 2022 Collin acknowledged he had been receiving off-list help from Jia Tan, and on 29 June 2022 he wrote that Jia Tan was "practically a co-maintainer already." JiaT75 was added to the Tukaani GitHub organisation in October 2022, and from March 2023 was the sole release builder.
The technical preparation was again separated by persona. Between 22 and 28 June 2023, a low-activity account identified as Hans Jansen submitted patches introducing GNU IFUNC support, the runtime mechanism the backdoor would later depend on. Two weeks later, Jia Tan opened a pull request to disable IFUNC fuzzing in Google's oss-fuzz project, citing a supposed incompatibility with address sanitisers. The automated detection path was blinded before the payload arrived.
1.2 The payload
The backdoor was delivered in two stages that decoupled the malicious runtime from the source repository.
The first stage was a build-time modification. Release tarballs 5.6.0 and 5.6.1 contained a modified build-to-host.m4 autotools macro that was absent from the git tree. The repository held two compressed test fixtures, presented as corrupt test data, that contained the obfuscated payload. Those fixtures were inert on their own. The modified macro extracted and chained them during compilation. A gitignore entry, added deliberately in February 2024, ensured the modified macro would not be tracked in the repository. The divergence between source and release artefact was the entire point.
The second stage was a runtime hook. OpenSSH does not link liblzma in its upstream configuration. The compromise reached the SSH daemon through a downstream choice made by major distributions, which patch sshd to link libsystemd for readiness signalling, and libsystemd carries a transitive dependency on liblzma. Once liblzma loaded into the sshd address space, the backdoor used glibc's IFUNC mechanism to replace the resolution of RSA_public_decrypt, an OpenSSL function called during public-key authentication, with its own implementation. The hooked function inspected each inbound key. A key carrying a payload signed with the attacker's hardcoded Ed448 key and decrypted with ChaCha20 triggered command execution in the sshd process, which on most distributions runs as root. Normal connections were unaffected. The backdoor did not break authentication for anyone. It added a private authentication path observable only to the attacker.
1.3 The discovery
Andres Freund, a Postgres developer at Microsoft, was running unrelated micro-benchmarks when he noticed SSH logins on a test machine taking roughly 500 milliseconds longer than expected, alongside valgrind warnings during symbol resolution. He traced the latency to liblzma, found the obfuscation, and disclosed the issue on the oss-security mailing list on 29 March 2024.
The lesson usually drawn is that curious engineers save the day. That is true and entirely insufficient as a control. The only thing distinguishing a backdoored production SSH daemon from a clean one was a measurable change in CPU utilisation, and the only person who measured it was running unrelated tests for an unrelated reason. No observability programme would have caught this. The control that mattered was the divergence between the git tree and the release tarball, and that divergence could have been detected by automated verification. No project of liblzma's profile had such verification in place. Most still do not.
1.4 What was not the cause
The xz project had clean code in its repository and no novel cryptography. Static analysis, software composition analysis, fuzzing, bug bounties, and SLSA Level 3 build provenance would each have returned clean, because every one of these controls assumes the adversary is external to the project. The XZ adversary was the project. This is the structural fact the rest of this paper builds on.
Part 2: The wave
Four campaigns since Freund's disclosure have moved the XZ pattern from theoretical to operational. With XZ itself, that is five in eighteen months. None used the exact XZ mechanism. All exploited the same underlying truth: open-source dependency chains are the soft path to high-value targets, and the trust model holding them together has not been re-engineered.
2.1 Shai-Hulud
In mid-September 2025, the first self-propagating worm in the npm ecosystem began compromising packages downstream of an earlier compromise. The malware embedded a post-install script that scanned for cloud and registry credentials, then exfiltrated them to attacker-created public repositories under the victim's own account. Its structural innovation was propagation: when it found npm publish tokens, it automatically published malicious versions of every package the victim controlled, and each newly infected package became a new vector. The first wave compromised more than 187 packages.
A second wave in late November 2025 escalated the technique. It reached approximately 700 packages across 350 maintainers, moved execution to the preinstall lifecycle phase so the payload ran before installation completed, bundled the Bun runtime to evade Node-targeted detection, and repurposed the open-source TruffleHog secrets scanner for offensive credential harvesting. It registered compromised machines as self-hosted CI runners for persistence and retained a destructive fallback that wiped the user's home directory where exfiltration failed. Affected packages included libraries from Zapier, PostHog, Postman, and others.
2.2 Axios
Between 00:21 and 03:20 UTC on 31 March 2026, two malicious versions of the Axios npm package were published. The attacker had compromised the maintainer's npm account following an approximately two-week social engineering operation that used a fake recruiter persona and a simulated technical interview to trick the maintainer into executing a malicious verification module, harvesting session credentials and bypassing multi-factor authentication. The malicious versions introduced a hidden dependency that deployed a cross-platform remote access trojan to Windows, macOS, and Linux. They were live for roughly three hours. Axios is downloaded approximately 100 million times per week.
Google Threat Intelligence Group attributed the attack to UNC1069, a North Korean cluster active since at least 2018 and tracked variously as BlueNoroff, Sapphire Sleet, and APT38 under the broader Lazarus umbrella. Microsoft Threat Intelligence and Elastic Security Labs published independent corroborating analyses. The pattern is precisely the threat model that matters most: a state-aligned actor conducting patient social engineering against a maintainer with privileged publish access to widely deployed code, then using that access to reach downstream developer machines and CI pipelines. Hardware-bound MFA is necessary against this pattern but not sufficient. Maintainers also need a mandatory reporting channel for unsolicited recruiter contact and identity verification for anyone with publish access to a critical artefact.
2.3 TanStack
The 11 May 2026 incident carries the most consequential implications. In a six-minute window, 84 malicious package versions were published across 42 packages in the @tanstack namespace. The most prominent affected package receives roughly 12.7 million weekly downloads, and the campaign spread to packages in other namespaces across npm and PyPI.
The attacker compromised no publishing credentials. On 10 May 2026 they created a fork of TanStack/router, renamed zblgg/configuration to keep it out of fork-list searches, and staged the payload commit under a forged identity, claude <claude@users.noreply.github.com>, impersonating the Anthropic Claude Code GitHub App and prefixed [skip ci] to suppress automated checks on push. The next day they opened a pull request that triggered a workflow using the privileged pull_request_target trigger, and used that workflow to execute fork-controlled code in the base repository's context. That code poisoned the build cache. When a later legitimate merge to the main branch ran the release workflow, it restored the poisoned cache. Attacker-controlled binaries then extracted OIDC tokens directly from the CI runner's process memory, and the malicious packages were published by the project's own legitimate release pipeline using its trusted OIDC identity.
The resulting package versions carried valid SLSA Build Level 3 provenance attestations. This was the first documented case of malicious packages with valid SLSA L3 provenance. The provenance attestation correctly identified the workflow that built the package. The workflow had been hijacked mid-execution. The attack, assigned CVE-2026-45321 at a CVSS score of 9.6, propagated through the rest of the day: by end of 11 May, roughly 169 npm packages and 373 malicious versions had been published, reaching the @antv data-visualization ecosystem, Mistral AI, UiPath, and Guardrails AI. Wiz, StepSecurity, and Unit 42 attribute the campaign, tracked as Mini Shai-Hulud, to a threat group known as TeamPCP, the same operators linked to earlier compromises of Trivy, Bitwarden CLI, and Intercom. Within 24 hours NHS England Digital issued a cyber alert recommending package cooldowns, lockfile verification, and credential rotation across affected estates.
That the forged identity was an AI assistant's rather than a human maintainer's is the novel element. By May 2026 an automated commit signature was unremarkable enough in an active repository that impersonating one helped the change pass without scrutiny. The attack surface of AI in the developer environment is not a future concern, and Part 2.4 shows the same campaign class writing directly into AI assistant configuration.
2.4 TrapDoor
Beginning 22 May 2026, three days before the Glasswing results were published, a campaign named TrapDoor began deploying malicious packages across npm, PyPI, and crates.io simultaneously. Socket Security identified 34 malicious packages and more than 384 versions. Attribution remains unconfirmed at the time of writing. The campaign carries no CVE, and because all 34 packages were newly created rather than compromised versions of established libraries, CVSS-based vulnerability scanners returned clean across the full package set. The threat is the code inside the packages, and detection requires behavioural and cross-registry analysis rather than known-vulnerability matching.
The campaign introduces two vectors not seen in any prior campaign in this wave. The first is exploitation of crates.io via build.rs, the Rust build script that executes automatically during compilation. Malicious Rust packages located local cryptocurrency keystores, obfuscated them with a hardcoded XOR key, and exfiltrated them to GitHub Gists during what appeared to be a normal build. Any developer or CI pipeline that compiled a TrapDoor crate executed the payload without invoking an install hook, without triggering lifecycle script policies, and without downloading any secondary binary. The Rust ecosystem's build.rs mechanism, legitimate and widely used for native library compilation, is now a confirmed attack surface.
The second vector is direct targeting of AI coding assistant configuration. TrapDoor packages wrote malicious instructions into .claude/settings.json, .cursor/rules, .vscode/tasks.json, and related IDE configuration files, configuring folder-open hooks to execute credential-harvesting payloads whenever a developer opened an affected project. This is the first documented case of a supply chain campaign deliberately targeting AI assistant context injection as an attack vector. It is not isolated: the Mini Shai-Hulud campaign in May also wrote to .claude/settings.json. Two separate campaigns within weeks of each other targeting the same configuration files is not coincidence. It is an emerging attack pattern.
The developer environment now has a new boundary that most security programmes have not drawn. AI coding assistant configuration files, IDE workspace files, and the build scripts that execute during compilation are security-sensitive artefacts. An organisation that treats .claude/settings.json as a developer convenience file rather than a trust boundary has not yet adjusted its threat model to the current campaign landscape.
2.5 What the wave proves
Five conclusions follow from this campaign record, three from the first four campaigns and two that TrapDoor adds.
The XZ pattern is operational at scale, spanning state-aligned actors, financially motivated Eastern European clusters, and unattributed campaigns, which means defence cannot be calibrated for a single actor profile or motivation. Attack speed now exceeds detection speed by orders of magnitude: Axios was live for three hours, the TanStack publication window was six minutes, and TrapDoor's average time from publication to detection by Socket's automated analysis was five minutes and fifty-six seconds. Incident-response models assuming days of attacker dwell time are obsolete for this class. And the developer environment is a first-class attack surface: every campaign since Shai-Hulud has succeeded primarily through compromise of developer credentials, runner memory, lifecycle script execution, or build system abuse rather than the protocol code itself.
TrapDoor adds two further conclusions. The Rust ecosystem and crates.io are now active supply chain attack surfaces. Prior campaigns focused on npm and PyPI; the Rust community's reputation for memory safety and compile-time guarantees does not extend to the build.rs execution model. And AI coding assistants, now embedded in the majority of professional development workflows, have become a persistence and injection target. The attack surface of the developer environment has expanded faster than the security perimeter around it.
2.6 SLSA Level 3 after TanStack
SLSA Level 3 guarantees authenticated build provenance, two-party review of build infrastructure, isolated build environments, and no persistent credentials in CI/CD. It does not guarantee the source is correct, that the release artefact reproduces from the source tree, that the contributor who triggered the build is who they claim to be, or, after TanStack, that the OIDC identity used to sign the build was not extracted from runner memory. SLSA Level 3 was the strongest widely deployed supply chain integrity standard in open source. It remains a necessary floor. It is no longer a terminal control.
2.7 The contribution model is the next surface
Every campaign above exploited a trust model that assumes contributors are human. The XZ actor needed two years and a coordinated multi-persona effort to manufacture that assumption before exploiting it. The same AI capability shift documented in Part 4 has collapsed the cost of that effort. In the first three weeks of January 2026, three critical projects took defensive measures against high-volume AI-generated contribution floods: curl shut down its six-year bug-bounty programme after receiving twenty AI-generated vulnerability reports in twenty-one days, none of which identified a real flaw; Ghostty moved to a zero-tolerance policy and a vouch-based contribution gate; and tldraw began auto-closing all external pull requests. In March 2026 the Jazzband collective, which had maintained 84 Python projects across a decade, announced it was sunsetting entirely. The underlying data is consistent with what the maintainers describe: CodeRabbit's December 2025 analysis of 470 pull requests found AI-generated contributions carried roughly 1.7 times more issues than human-written ones, 10.83 against 6.45 per request, at materially higher volume.
These responses address quality and volume. They do not address identity. A patient synthetic contributor that builds genuine standing over weeks before placing a payload would look, from the outside, identical to the XZ operation at a fraction of its cost. Neither this paper nor the field can yet say how close that threat is. What the campaign record establishes is what failure looks like once the contribution model breaks. Naming the surface before it breaks is the more useful exercise.
Part 3: The measures that would have changed the outcome
Three measures would have materially changed the outcome of every campaign in this wave. They sit at different levels of unilateral control, and the honest framing names that difference rather than obscuring it.
3.1 Dependency cooldowns
A seven-day cooldown on all non-security updates entering production build pipelines would have blocked the three-hour Axios exposure window and the six-minute TanStack window entirely. Dependabot, Renovate, and Snyk support cooldown configuration natively, and NHS England Digital recommended it as a primary mitigation within 24 hours of the TanStack disclosure. OpenAI confirmed in its post-incident statement that the only devices in its estate to ingest the malicious TanStack versions were those not yet configured with the cooldown it had begun deploying in direct response to Axios.
Security patches bypass the cooldown by design, so the measure does not slow remediation. It slows opportunistic dependency upgrades, which is the surface that matters. The friction is cultural rather than technical: engineers want the latest patches and product teams want the latest features. That friction is several orders of magnitude cheaper than ingesting a poisoned package during its live window. This is the single most accessible measure in the paper, and it requires no engineering project, only a configuration decision and the organisational will to hold it.
3.2 Ephemeral CI runners with restricted egress
Runners destroyed after each job limit the dwell time available to any payload that survives a single workflow run. Restricting outbound network egress from runners to an allow-listed set of package registries and artefact stores closes the path TanStack used to publish to npm under the project's own identity. Both controls are supported natively across the major CI platforms, and both apply to any organisation running its own continuous integration, not only to open-source maintainers. The configuration cost is hours rather than weeks, and the benefit is the closure of the specific exfiltration path the 2025-26 wave depends on.
For organisations maintaining critical-path repositories, two further controls belong in the same layer: commit-SHA pinning on all CI actions, because tags can be reassigned by a compromised maintainer while commit SHAs cannot, and a categorical ban on the pull_request_target and workflow_run triggers in any repository with elevated release permissions, because those triggers were the entry point for the TanStack chain.
3.3 Build verification
This is where unilateral control runs out and the industry argument begins. The heavy version is reproducible builds, in which any independent party can rebuild a release from its tagged commit and verify byte-level equivalence. That work sits with upstream maintainers and the Reproducible Builds project, which has refined the toolchain for over a decade. Debian leads among major distributions. Language ecosystems are materially behind: a February 2026 analysis found only 12.2 percent of PyPI packages reproducible out of the box, with the gap largely determined by build backend choice, and RubyGems reproducibility was effectively zero. The npm and crates.io ecosystems sit between these extremes but remain partial.
The most significant defensive development in this space since the XZ disclosure is Google's OSS Rebuild project, announced in July 2025. OSS Rebuild performs automated rebuilds of PyPI, npm, and crates.io packages as they are published, using automation and heuristics to infer build definitions from published metadata, rebuilding in containers, and publishing SLSA Level 3 provenance attestations signed via Sigstore without requiring any action from the package publisher. Infrastructure definitions are publicly available for organisations to run their own OSS Rebuild instances. This is not a future aspiration. It is live, it is producing attestations today, and a consuming organisation can integrate those attestations into its own ingestion pipeline as a verification step. The direct response to TrapDoor's crates.io build.rs vector is for any team consuming Rust crates to verify OSS Rebuild attestations before allowing a crate into a build environment.
What the consuming organisation can do today: verify provenance attestations that already exist using Sigstore and SLSA statements, with OSS Rebuild attestations as the primary source for language ecosystem packages; pin to specific versions with integrity hashes in lockfiles and treat hash mismatches as build failures rather than warnings; and prefer packages from projects that publish reproducible builds as a procurement criterion. What it should do is fund the upstream work: the cost of underwriting reproducible builds infrastructure is a rounding error against the cost of a successful supply chain incident, and the only reason it is not standard practice is that the security functions who would benefit most have not pressed the case hard enough. The argument connects directly to Part 5.
Part 4: The symmetrical accelerator
Adding AI to both sides of the supply chain equation changes the economics again, and the change happened inside the two months before this paper was written.
4.1 The offensive benchmark
On 30 April 2026 the UK AI Safety Institute published its evaluation of OpenAI's GPT-5.5-Cyber. The benchmark of interest is a reverse-engineering task contributed by Crystal Peak Security, consisting of a stripped Rust ELF implementing a custom virtual machine and a second file containing bytecode for that VM in an undocumented format, guarding an authentication mechanism on a network port. To solve it, an attacker must reverse-engineer the VM from the host binary, build a disassembler for the bytecode, recover the password-check logic from the disassembled authenticator, solve for a valid input, and submit it. No off-the-shelf tooling exists for the custom VM, so the attacker must build their own instruction decoder before reading a single line of the target.
Crystal Peak's expert playtester solved the challenge in roughly twelve hours using Binary Ninja, gdb, Python, and Z3. GPT-5.5-Cyber solved it in ten minutes and twenty-two seconds, with no human assistance, at an API cost of $1.73, using a basic agent scaffold in a Kali Linux container. On the institute's expert-tier task suite, GPT-5.5-Cyber recorded an average pass rate of 71.4 percent, the highest the institute had measured. It also became the second model, after Claude Mythos Preview, to complete a 32-step simulated corporate network attack end-to-end, an exercise the institute estimates would take a human expert around twenty hours.
The implication for patch management is direct. The 30-day window for patching internet-facing systems was calibrated against human attackers reading advisories at human speed. When a frontier model can read a patch diff, identify the corrected flaw, write a working exploit, and fire it within the same business hour the patch shipped, the 30-day window is not a control. It is a permission slip. The NCSC has separately published guidance on preparing for a "vulnerability patch wave" in direct response to this dynamic.
4.2 The defensive benchmark
On 22 May 2026 Anthropic published the first month of results from Project Glasswing, a programme launched on 7 April 2026 that gave an initial cohort of roughly 50 vetted partners early access to Claude Mythos Preview, an unreleased frontier model with specialised vulnerability-discovery capability. The twelve named launch partners were Anthropic, AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks, alongside more than forty further organisations maintaining critical software infrastructure. Anthropic committed up to $100 million in Mythos Preview usage credits and $4 million in direct donations to open-source security organisations, split between OpenSSF Alpha-Omega and the Apache Software Foundation. On 2 June 2026 the programme expanded by approximately 150 organisations across more than fifteen countries, reaching roughly 200 in total and adding power, water, healthcare, communications, and hardware sectors absent at launch. For the first two months of the programme the model was not publicly released, on the stated grounds that its capability would not be safe in open distribution. On 9 June 2026 that posture changed: Mythos Preview was retired and replaced with Mythos 5 for Glasswing partners, and Fable 5 (the same underlying model with classifier-mediated safeguards) was released into general availability, priced at ten dollars per million input tokens, less than half the prior price.
In one month, the programme identified more than ten thousand high- or critical-severity vulnerability candidates across more than a thousand open-source projects. Of a reviewed sample, independent security firms confirmed 90.6 percent as valid true positives. Mozilla reported finding and fixing 271 vulnerabilities in a single Firefox release while testing the model, more than ten times the number identified during equivalent testing with the prior-generation model. Cloudflare reported 2,000 findings, 400 of them high or critical. A disclosed finding in the wolfSSL cryptography library, CVE-2026-5194 at CVSS 9.1, was a certificate forgery vulnerability in a library deployed across billions of devices in IoT, automotive, and industrial-control environments; Mythos Preview constructed a working exploit for it.
The most important figure in the disclosure is not the headline count. It is the patch gap. Of the high- or critical-severity vulnerabilities disclosed, only a double-digit number had been patched at the time of the update. Anthropic stated the bottleneck plainly: the constraint is no longer the capacity to find vulnerabilities, but the human capacity to triage, report, and deploy patches for them. Some maintainers reportedly asked Anthropic to slow the pace of disclosure because they needed more time to develop fixes.
4.3 The corroborating evidence and the dissent
Palo Alto Networks, testing Mythos from 7 April alongside Claude Opus 4.7 and GPT-5.5-Cyber under OpenAI's Trusted Access for Cyber programme, released a single month's security advisories covering 26 CVEs representing 75 issues across more than 130 products, against a typical monthly volume of fewer than five CVEs. Their Chief Product and Technology Officer cautioned that running a model does not by itself resolve the vulnerability problem, and estimated organisations have three to five months to get ahead of AI-driven exploitation before it becomes the norm.
The framing has its critics, and a defining-issue argument should engage them. Independent analysts have noted that aggregate vendor statistics presented in the most favourable light risk converting routine advisory cycles into procurement urgency, and that buyers reallocating budget toward AI-flavoured product spend on the basis of the urgency framing may move money away from operational basics like patch cadence and interface segmentation. The caution is fair. The capability shift is real, the benchmarks are independently published, and the vendor framing around them is partly promotional. Both things are true at once, and the measures in this paper are deliberately operational basics rather than product purchases for exactly that reason.
4.4 The asymmetry
The same model class that finds a 27-year-old latent bug in OpenBSD or a 16-year-old flaw in FFmpeg, both of which Mythos surfaced after decades of human review and fuzzing, is available on both sides of the equation. Until 9 June 2026 the difference between offensive and defensive use was access governance: Anthropic gated Mythos behind vetted partnership and coordinated disclosure, OpenAI gated GPT-5.5-Cyber behind tiered access and identity verification under its Trusted Access for Cyber programme, and the partition held for two months. From 9 June 2026 forward Anthropic operates a two-tier model: classifier-mediated public access via Fable 5, with cybersecurity, biology and chemistry, and distillation queries routed to a fallback model (Opus 4.8), and unmediated Mythos 5 for Glasswing partners and a forthcoming trusted access programme. Anthropic states that more than 95 percent of Fable sessions involve no fallback, which means for the great majority of usage the publicly-available model performs identically to the gated one. The capability differential the industry is depending on is therefore no longer measured by who has access. It is measured by how durable the classifiers are, and how long they hold against sustained red team work. Anthropic disclosed in the same launch material that the UK AI Safety Institute had made initial progress toward a universal jailbreak of Fable 5 within a brief testing window. Neither this scheme nor OpenAI's holds indefinitely. Frontier capability diffuses on the same trajectory every prior generation has followed, and open-weight models approximate the frontier within months.
Part 5: The accountability model that was never built
5.1 The missing diagram
Cloud computing has a shared responsibility model. The providers publish the diagram. Security of the cloud belongs to the provider, security in the cloud belongs to the customer, and the boundary is defined well enough to survive a regulatory audit.
Open-source software has no equivalent. There is no published diagram, no agreed boundary, and no settled answer to the question of who is responsible when a library underpinning global infrastructure is maintained by one volunteer who disclosed his own capacity limits in a public mailing list before a state actor used those limits as the attack vector.
A 2024 Harvard Business School working paper estimated the demand-side value of widely used open source at $8.8 trillion against a supply-side replacement cost of $4.15 billion, and found that 96 percent of that demand-side value is created by roughly 5 percent of developers. The figures are working paper estimates based on replacement-cost modelling, and published methodological critiques note that the demand-side figure conflates one-time replacement cost with ongoing value in ways that may overstate the counterfactual. The precise numbers carry uncertainty. The order of magnitude is not in dispute, and the ratio between the value extracted and the cost of maintaining the infrastructure that generates it is the point: whoever is receiving the $8.8 trillion is not the person doing the maintenance.
A 2024 Tidelift survey of more than 400 maintainers found that 60 percent categorise themselves as unpaid hobbyists, a figure identical to the 2023 survey, and that paid maintainers are 55 percent more likely to implement critical security and maintenance practices than unpaid ones. Seventy-eight percent of unpaid hobbyist maintainers work ten hours or less per week on their projects. The demographic trend compounds the structural problem: the share of maintainers aged 46 to 65 has doubled since 2021, while those under 26 have fallen from 25 percent to 10 percent. The ecosystem is ageing, underfunded, and not replacing itself. The XZ attack did not create these conditions. It exploited them.
The organisations extracting that value have externalised the security cost onto unpaid volunteers for three decades, because deferring the responsibility question was cheaper than answering it.
That deferral is ending.
5.2 The regulatory direction is settled even where the boundaries are not
The regulatory centre of gravity has shifted decisively toward whoever commercialises, ships, or profits from software, and away from the volunteer maintainer.
The EU Cyber Resilience Act, in force from December 2024 with full obligations applying from December 2027, places security obligations on manufacturers of products with digital elements and explicitly extends due-diligence duties to the open-source components a manufacturer integrates. It exempts non-commercial development and individual volunteer contributors, and it creates a novel and deliberately light-touch category, the open-source software steward, for organisations that systematically support open-source development intended for commercial use. The intent is to place the burden on those who profit while shielding the volunteers who do not.
NIS-2 carries the broader hook. Article 21(2)(d) requires every essential and important entity, across 18 sectors including energy, health, transport, digital infrastructure, and public administration, to manage security risk across its supplier and service-provider relationships. It has no carve-out for open-source dependencies and no provision for "it was just a library." Because a raw open-source dependency has no counterparty and no contract, the obligation does not attach to the library. It reverts to the entity in scope.
Transposition has been uneven and slower than the October 2024 deadline required. On 7 May 2025 the European Commission sent reasoned opinions to 19 member states, including Germany, France, Spain, Ireland, Denmark, the Netherlands, Austria, Finland, and Sweden, for failing to notify full transposition. Most completed their national legislation during 2025 following Commission infringement pressure, and Bird & Bird confirmed in early 2026 that Germany, Portugal, and Austria had recently adopted implementing legislation while Spain, France, and Poland were nearing completion. Several states have compliance audit deadlines running into mid-2026. The unevenness creates jurisdiction-specific compliance timelines but does not change the underlying obligation: once transposition completes in any member state, the "it was open source" defence is available to no essential or important entity operating within scope of that transposition.
For financial entities specifically, DORA reaches the same place by a different route. Its third-party risk regime under Article 28 presupposes a contractual ICT provider, which a package pulled from a registry is not, but the binding technical standard in Commission Delegated Regulation (EU) 2024/1774 names open-source libraries explicitly and requires in-scope entities to identify, track, and monitor the third-party and open-source libraries supporting critical functions. Article 28(1)(a) makes the financial entity "at all times" fully responsible. The duty does not disappear because there is no vendor. It reverts to the firm.
The direction across all three instruments is consistent. Responsibility flows to whoever ships or profits. The boundaries between actors are not yet precise. That imprecision is the substance of the rest of this section.
5.3 The distribution layer is the under-examined actor
The XZ backdoor was engineered specifically to exploit the Debian and RPM packaging path, not the upstream source. It targeted the distribution layer, where upstream code is packaged, patch-ported, compiled, and redistributed into the images and repositories that consumers actually run. Yet the responsibility debate is framed almost entirely around the upstream maintainer and the downstream consumer, leaving the distribution layer least clearly assigned.
The positions of the major distributions diverge sharply. Canonical accepts the manufacturer designation under the Cyber Resilience Act for Ubuntu and states that customers can consume open source through it without taking on the corresponding responsibility themselves. Red Hat claims a deliberate dual role as both manufacturer and steward, extending stewardship to critical upstream projects while arguing the Act should not force volunteer maintainers to become commercial suppliers. Debian, a community distribution, passed a formal resolution opposing the Act's framing on the grounds that determining the commercial or non-commercial nature of every downstream use is not feasible, and that the Act's mandatory reporting timelines would overturn the community's established responsible-disclosure practice. No framework resolves cleanly who is responsible for a vulnerability that enters at the packaging layer, which is the specific class of failure that XZ exploited.
5.4 Cloud providers are where the provocation lives
Cloud providers occupy a dual position that no framework maps cleanly. Hyperscale providers including AWS and GCP, and mid-tier providers including OVH and Hetzner, distribute open-source software at scale through managed services, marketplace images, base container images, and platform runtimes. When they consume upstream open source into their own engineering stack, they are consumers. When they ship it packaged into the products their customers run, they become manufacturers and distributors. Under NIS-2, cloud computing services are classified as essential entities, which means a provider carries its own supply chain security obligation, not merely a place in someone else's chain.
When a provider distributes a managed image built on a distribution that packaged a library compromised at the packaging layer, the customer running that image has no independent ability to detect or remediate the compromise. They did not build the image. They cannot patch it. They can only trust that the provider's security posture is what the provider represents it to be.
The challenge to every cloud provider is direct. If you are not actively maintaining the images you ship and funding the upstream maintainers those images depend on, your customers face a forced choice that no one is yet naming. They can consume managed images they cannot independently verify. They can build and maintain their own images, which replicates the maintainer-fatigue problem at scale inside the consuming organisation. Or they can rethink the dependency model entirely, moving toward distroless or hermetic builds that minimise the attack surface of the packaging layer. Providers will resist the responsibility framing until the market or a regulator forces the question, and the forcing mechanism will be either a major incident involving a widely deployed managed image, or a NIS-2 enforcement action against a provider that failed its own supply chain obligation as an essential entity.
Two things sit at different evidentiary weights and the distinction matters. That cloud services are essential entities under NIS-2, and therefore carry the Article 21(2)(d) supply chain obligation in their own right, is settled regulatory ground. That a supervisory authority will interpret distribution of a managed image built on a compromised packaging layer as a breach of that obligation is a forward prediction. No regulator has yet tested the question against a managed-image incident, and no ENISA guidance has been published addressing the pass-through defence directly. The direction of travel across NIS-2, DORA, and the Cyber Resilience Act is consistent. The test is coming. It has not been concluded.
5.5 The funding question is real but undersized
Every serious actor in this space agrees the burden should not fall on volunteers. CISA stated after XZ that every manufacturer profiting from open source must be a responsible consumer of and sustainable contributor to the packages it depends on. The OpenSSF Alpha-Omega programme operationalises this by routing commercial funding into foundation-employed security staff at critical upstream projects, and has issued more than $20 million in grants since 2022. In March 2026, AWS, Google, Microsoft, Anthropic, GitHub, and OpenAI collectively committed a further $12.5 million to the programme, specifically to help maintainers process the surge of AI-generated vulnerability reports.
The funding is real, the intent is correct, and it remains a rounding error against the demand-side value those same organisations and their customers extract. There is also an irony worth naming directly: the AI companies funding the cleanup are the same companies generating the report flood that prompted it. That is not a criticism of the funding, which is welcome. It is an observation that the scale of the response is calibrated to corporate philanthropy rather than to the size of the value at risk, and philanthropy has never been a substitute for a responsibility model.
One costed alternative exists at national scale. Germany's Sovereign Tech Fund, operational since 2022, has invested over €23.5 million across more than 60 foundational open-source projects, including cURL and GNOME, financed through public procurement rather than donation. A 2025 feasibility study commissioned by GitHub and conducted by OpenForum Europe, Fraunhofer ISI, and the European University Institute priced a pan-European scale-up at a minimum €350 million contribution from the EU multiannual budget, as the base for leveraging national and industry co-financing. That figure is not aspirational. It is a published, costed political ask with named institutional sponsors. It has not been adopted, because the gap it addresses is political rather than technical, and the difference between a procurement-funded model and a philanthropy-funded one is whether maintenance is treated as infrastructure or as charity.
5.6 The AI lens changes the category of the question
The debate about who is responsible for open-source security has been a slow structural argument for years, held in place partly because the threat moved at a manageable speed. Mythos and GPT-5.5-Cyber removed that. When a frontier model can identify ten thousand high-severity vulnerabilities across a thousand projects in a month, the bottleneck is no longer discovery. It is triage, prioritisation, and patching, at a speed the volunteer ecosystem cannot reach. A maintainer receiving hundreds of AI-generated vulnerability reports cannot process them at the rate a frontier model on the other side of the equation can weaponise them. The $12.5 million commitment in March 2026 is an admission that the AI capability shift has converted the funding gap from a structural concern into an operational emergency. The shared responsibility model the industry deferred for thirty years now needs to exist before the triage gap becomes the next attack surface.
5.7 What Glasswing answers, and what it does not
Project Glasswing is the closest thing to a shared responsibility model open-source security has produced, and it is worth being precise about which half it builds. It was not built by regulators. It was built by a consortium of the largest beneficiaries: twelve named launch partners, more than forty further critical-infrastructure maintainers at launch, and roughly 200 organisations across more than fifteen countries after the 2 June 2026 expansion, with $100 million in model credits and a direct application channel for open-source maintainers. That is a private-consortium answer to a structural failure a decade of public debate did not resolve, and on its own terms it is moving faster than any public mechanism has.
Anthropic has said that, in the medium term, an independent third-party body bringing together private- and public-sector organisations might be the ideal home for the work. That is the first published proposal for the governance architecture this question requires. It also exposes the gap it does not yet close. Today Anthropic is the convener, the funder, and the body that sets the prioritisation criteria for which codebases the programme covers, because no independent body exists yet to set them instead. That is not a conflict that makes the programme wrong; it is a governance gap the programme itself acknowledges. The half being built covers the highest-profile systems and the largest beneficiaries. The half not being built covers the long tail, the regulatory accountability, and the mandatory obligations a genuine shared responsibility framework would carry. A consumer in scope of NIS-2 cannot evidence supply chain due diligence by pointing at its hyperscaler's Glasswing membership, and a volunteer maintainer of a library no consortium prioritises receives no benefit from the programme's funding at all.
5.8 What 9 June 2026 changed
The 9 June 2026 release of Claude Fable 5 and Claude Mythos 5 is the third inflection in the wave this paper documents, and the first one initiated by a model provider rather than by an attacker or a regulator. Three elements of the release matter for the shared responsibility argument.
First, the access-governance partition this paper described holds for two months and then narrows. Mythos-class capability is now generally available behind classifier-mediated safeguards at ten dollars per million input tokens, half the prior price. Anthropic states that classifiers route cybersecurity, biology and chemistry, and distillation queries to a fallback model (Opus 4.8), and that fewer than five percent of Fable sessions trigger fallback. Over a thousand hours of external red team work, plus internal evaluation, produced no universal jailbreak before launch. The UK AI Safety Institute, separately, made initial progress toward one within a brief initial testing window, and Anthropic published that on the launch page. The capability differential the industry depends on for defensive lead time is now bounded by the half-life of the safeguards, not by the partition between trusted access and general availability.
Second, the safeguard architecture itself is the new artefact. Classifiers running in front of a frontier model, with deterministic fallback to a less-capable model when classifiers fire, plus a 30-day mandatory retention policy on all Mythos-class traffic on first- and third-party surfaces, with logged human access and deletion after 30 days, is the first published end-to-end pattern for safe deployment of a dual-use frontier model. CISOs evaluating internal agent deployments and procurement of third-party AI products will now be measured against this pattern. The retention policy is the operational lever that makes the classifier argument credible at scale: without telemetry across multi-turn attacks and novel jailbreak campaigns, the classifiers degrade silently. The retention policy is what lets the provider detect that degradation and respond before it becomes systemic.
Third, the trusted access programmes that Anthropic announced for cybersecurity and biology, separate from and parallel to Glasswing, are the first published mechanism by which an organisation outside the original launch consortium can apply for unmediated access to a Mythos-class model. That is materially different from Glasswing, which has expanded by direct invitation and which selects against a private set of criteria. A published application channel with stated eligibility criteria is the precondition for the governance gap section 5.7 identifies to begin closing without an independent third-party body being formed. It does not close the gap. It does establish the procedural template that a future independent body, if one is constituted, would inherit.
None of this resolves the regulatory half of the shared responsibility model. A consumer in scope of NIS-2 still cannot evidence supply chain due diligence by pointing at a hyperscaler's Glasswing membership or its trusted-access enrolment. A volunteer maintainer of a library no consortium prioritises still receives no benefit. What the 9 June release changes is the size of the private-consortium answer relative to the regulatory one. The consortium answer just expanded materially. The regulatory answer is in the same position it was on 8 June.
Part 6: Incident response for the supply chain class
The technical measures in Part 3 reduce the probability of compromise. They do not eliminate it. An organisation consuming open source at scale needs a response model calibrated to the speed this attack class now operates at. The framework is not the novel part. NIST SP 800-61r3, published in April 2025, restructured incident response around continuous risk management rather than a one-off event lifecycle, and it defers the operational detail to the CISA incident and vulnerability response playbooks. What the supply chain class changes is the calibration: the detection paths it surfaces through, the containment assumptions it breaks, and the disclosure clock it runs against all tighten.
6.1 Detection triggers
A supply chain compromise will surface through one of five paths: a reproducibility verification failure, where an automated rebuild does not match the published artefact; a dependency or AI-review escalation, where an ingested package is newer than the cooldown threshold or matches a known attack pattern; a runtime telemetry anomaly, such as an unexpected performance shift or an outbound connection from a runner to a non-allow-listed destination; a credential anomaly, such as an unexpected publish event or token use; or an external disclosure from a researcher, registry, or downstream consumer. The response model must not depend on which path fires.
None of these paths is hypothetical, and each maps to something this paper has already documented. Reproducibility verification is the OSS Rebuild capability described in Part 3.3, now producing attestations a consuming organisation can check at ingestion. The AI-review escalation is the defensive side of the capability shift in Part 4, where a model reads a dependency before a human does. Runtime and credential anomalies are how Shai-Hulud and Axios surfaced, through unexpected publish events and outbound connections rather than through code review. External disclosure is how XZ itself surfaced, and the lesson from Part 1.3 holds: Freund found it by accident while benchmarking something unrelated. An accident is not a control. The detection programme exists so the next compromise does not depend on a curious engineer noticing a 500-millisecond delay for an unrelated reason.
6.2 Containment under the new timelines
Because the developer environment is a first-class attack surface, containment must treat any machine that installed an affected dependency as compromised regardless of subsequent package removal. The configuration-file persistence documented in Part 2.4, where TrapDoor and the Mini Shai-Hulud campaign wrote folder-open hooks into IDE and AI-assistant settings that re-executed on project launch, is why remove-and-rotate is insufficient: full machine remediation with credential rotation is required. Any CI runner that processed an affected version is treated the same way. The speed of this attack class means the containment decision must be pre-authorised. NIST SP 800-61r3 places this in the Preparation function for a reason. The conditions under which a pipeline is paused or a credential set is rotated should be agreed before an incident, not negotiated during one.
6.3 Disclosure
For entities in scope, disclosure is governed by a regulatory clock, not a communications calendar, and the two regimes do not stack. NIS-2 and DORA cover different entity types. A financial entity reports under DORA as lex specialis rather than under NIS-2, and NIS-2 Article 23(6) treats the NIS-2 obligation as satisfied where the same incident has been reported under DORA. The response model must reflect whichever clock applies, not both.
Under NIS-2 Article 23, an essential or important entity files an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. Under DORA, a financial entity submits an initial notification within four hours of classifying an incident as major, an intermediate report within 72 hours, and a final report within one month. The DORA clock starts at classification, not detection, which moves the pressure upstream: the classification criteria have to be agreed and documented before an incident so that the four-hour window is not consumed by an argument about whether the threshold has been met.
The governing principle sits above both clocks. Institutional customers and regulators should not learn of a confirmed incident from public reporting. Legal counsel advises and the security function decides on the tightest defensible disclosure window, measured against the regulatory deadline rather than the communications calendar.
6.4 Recovery and the learning loop
Recovery is not the point at which the affected package is removed. It is the point at which the replacement has been independently verified. For this attack class that means the clean artefact has been rebuilt and checked against published provenance before it re-enters the pipeline, using the same verification path described in Part 3.3. Resuming on an unverified replacement reintroduces the exposure the incident was meant to close.
The postmortem is the mechanism that converts one incident into a permanent control. NIST SP 800-61r3 frames incident response as a continuous practice rather than a discrete event, and the lessons-learned step is the one most organisations skip once the immediate pressure lifts. For the supply chain class the discipline is specific: every confirmed compromise yields a new named detection pattern, and that pattern is added to the triggers in 6.1. An incident that does not change the detection rules has been survived, not learned from.
Conclusion
CVE-2024-3094 was the most consequential supply chain attack that did not happen. The patch shipped before the affected versions reached stable, and the industry treated the near-miss as a wake-up call for about six weeks before returning to normal practice. In the eighteen months since, four campaigns have demonstrated the same structural failure at accelerating speed. Reproducible builds are still rare on critical-path open-source projects. Maintainer fatigue is still the operating model, and the maintainer community is ageing without replacing itself. The interval between the four most recent campaigns was measured in days, not weeks, and TrapDoor introduced two vectors, crates.io build.rs execution and AI assistant configuration poisoning, that most security programmes have not yet drawn a boundary around. The AI capability benchmarks from April and May 2026 demonstrate that the time between vulnerability disclosure and working exploit is now measured in minutes.
The technical measures that would have changed the outcome of every campaign in this paper are publicly documented and operationally inexpensive. The benchmarks demonstrating the capability shift on both sides are publicly verifiable, and the threat actors are publishing their own proofs of concept by exploiting them in production. The trust model that holds open-source infrastructure together has not been re-engineered since Freund's disclosure, and there is no longer any technical or commercial reason for that to be the case.
The distance between what the ecosystem has and what the evidence demands is no longer a tooling problem. It is an accountability problem, and it is a choice being deferred by every organisation that consumes open-source software without operationalising the work the last eighteen months have made unavoidable. The next major incident, whether a compromised managed image, a poisoned distribution layer, or an AI-accelerated exploit chain against an unpatched volunteer-maintained library, will not defer the question again. It will force it, in front of a regulator, a board, or both at once.
The shared responsibility model for open-source security needs to exist before that incident arrives. At the time of writing, it does not.
References
Primary sources, XZ Utils (CVE-2024-3094)
Freund, A. (2024). "backdoor in upstream xz/liblzma leading to ssh server compromise." oss-security mailing list, 29 March 2024. https://www.openwall.com/lists/oss-security/2024/03/29/4
Cox, R. (2024). "Timeline of the xz open source attack." research.swtch.com. https://research.swtch.com/xz-timeline
CISA (2024). "Lessons from XZ Utils: Achieving a More Sustainable Open Source Ecosystem." US Cybersecurity and Infrastructure Security Agency, 29 April 2024. https://www.cisa.gov/news-events/news/lessons-xz-utils-achieving-more-sustainable-open-source-ecosystem
2025-26 supply chain wave
Wiz (2025). "Shai-Hulud npm Supply Chain Attack." https://www.wiz.io/blog/shai-hulud-npm-supply-chain-attack
Wiz (2025). "Shai-Hulud 2.0 Supply Chain Attack." https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack
Google Threat Intelligence Group (2026). "North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack." https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package
Tenable Research (2026). "Axios npm Supply Chain Attack FAQ: North Korea UNC1069." https://www.tenable.com/blog/faq-about-the-axios-npm-supply-chain-attack-by-north-korea-nexus-threat-actor-unc1069
Snyk (2026). "TanStack npm Packages Hit by Mini Shai-Hulud." CVE-2026-45321. https://snyk.io/blog/tanstack-npm-packages-compromised/
Wiz (2026). "Mini Shai-Hulud Strikes Again: TanStack and more npm Packages Compromised." https://www.wiz.io/blog/mini-shai-hulud-strikes-again-tanstack-more-npm-packages-compromised
TanStack (2026). "Postmortem: TanStack npm supply-chain compromise." TanStack Blog, May 2026. https://tanstack.com/blog/npm-supply-chain-compromise-postmortem [Primary source for the forged claude <claude@users.noreply.github.com> identity, the zblgg/configuration fork, and the three-vulnerability chain.]
Unit 42, Palo Alto Networks (2026). "The npm Threat Landscape: Attack Surface and Mitigations." Updated 21 May 2026. [Source for the end-of-day spread: 373 malicious versions across 169 npm packages. Attribution of the Mini Shai-Hulud campaign to TeamPCP corroborated by Wiz and StepSecurity.]
CodeRabbit (2025). "State of AI vs Human Code Generation Report." December 2025. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report [470 pull requests analysed; AI-generated PRs averaged 10.83 issues against 6.45 for human-written, a 1.7x difference.]
Stenberg, D. (2026). "The end of the curl bug-bounty." January 2026. Hashimoto, M., Ghostty contribution policy (January 2026). Ruiz, S., tldraw external-PR policy (January 2026). Leidel, J., "Sunsetting Jazzband" (14 March 2026). [Primary maintainer statements on AI-generated contribution floods.]
NHS England Digital (2026). "Supply Chain Attack Affecting Numerous npm and PyPI Packages." Cyber Alert CC-4781, 12 May 2026. https://digital.nhs.uk/cyber-alerts/2026/cc-4781
Socket Security (2026). "TrapDoor Crypto Stealer Supply Chain Attack Hits npm, PyPI, and Crates.io." May 2026. https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-crates
The Hacker News (2026). "TrapDoor Supply Chain Attack Spreads Credential-Stealing Malware via npm, PyPI, and CratesIO." 25 May 2026. https://thehackernews.com/2026/05/trapdoor-supply-chain-attack-spreads.html
Google Open Source Security Team (2025). "OSS Rebuild: Securing the Open Source Software Supply Chain with Reproducible Builds." Announced July 2025. https://github.com/google/oss-rebuild
Nesbitt, A. (2026). "Reproducible Builds in Language Package Managers." February 2026. https://nesbitt.io/2026/02/24/reproducible-builds-in-language-package-managers.html
European Commission (2025). "Commission calls on 19 Member States to fully transpose the NIS2 Directive." Press release, 7 May 2025. https://digital-strategy.ec.europa.eu/en/news/commission-calls-19-member-states-fully-transpose-nis2-directive
Bird & Bird (2026). "European Cybersecurity Regulatory Update: NIS2 and Beyond." Early 2026. https://www.twobirds.com/en/insights/2025/european-cybersecurity-regulatory-update-nis2-and-beyond
Whitacre, C. (2024). "Questioning 'The Value of Open Source Software'." Open Path, January 2024. https://openpath.quest/2024/questioning-the-value-of-open-source-software/ [Published methodological critique of Hoffmann, Nagle, Zhou (2024).]
Dual-use AI capability
UK AI Safety Institute (2026). "Our evaluation of OpenAI's GPT-5.5 cyber capabilities." 30 April 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities
Anthropic (2026). "Project Glasswing: An initial update." 22 May 2026. https://www.anthropic.com/research/glasswing-initial-update
Anthropic (2026). "Project Glasswing: Securing critical software for the AI era." 7 April 2026. https://www.anthropic.com/glasswing [Launch announcement, twelve named launch partners, $100M credits and $4M donations, and the medium-term proposal for an independent third-party governance body.]
Anthropic (2026). "Expanding Project Glasswing." 2 June 2026. https://www.anthropic.com/news/expanding-project-glasswing [Expansion to approximately 150 further organisations across more than fifteen countries, reaching roughly 200 in total.]
Anthropic (2026). "Claude Fable 5 and Claude Mythos 5." 9 June 2026. https://www.anthropic.com/news/claude-fable-5-mythos-5 [General availability of Mythos-class capability as Fable 5 at $10/M input tokens with classifier-mediated safeguards and Opus 4.8 fallback; Mythos 5 replaces Mythos Preview for Glasswing partners; 30-day mandatory retention policy; UK AISI initial progress toward a universal jailbreak disclosed; planned trusted access programmes for cybersecurity and for biology. System card: https://anthropic.com/claude-fable-5-mythos-5-system-card]
OpenForum Europe, Fraunhofer ISI, and European University Institute (2025). "Funding Europe's Open Digital Infrastructure: Feasibility Study for an EU Sovereign Tech Fund." Commissioned by GitHub, July 2025. https://eu-stf.openforumeurope.org [€350 million minimum EU contribution; Germany's Sovereign Tech Fund cited as template, over €23.5 million across more than 60 projects, 2022-2024.]
Palo Alto Networks (2026). "Defender's Guide to the Frontier AI Impact on Cybersecurity: May 2026 Update." 13 May 2026. https://www.paloaltonetworks.com/blog/2026/05/defenders-guide-frontier-ai-impact-cybersecurity-may-2026-update/
The Register (2026). "Welcome to the vulnpocalypse, as vendors use AI to find bugs and patches multiply." 14 May 2026. https://www.theregister.com/patches/2026/05/14/welcome-to-the-vulnpocalypse/
Cybersecurity Dive (2026). "Frontier AI models reap rapid discovery of security vulnerabilities." https://www.cybersecuritydive.com/news/frontier-ai-rapid-discovery-security-vulnerabilities/820258/
The Hacker News (2026). "Claude Mythos AI Finds 10,000 High-Severity Flaws in Widely Used Software." https://thehackernews.com/2026/05/claude-mythos-ai-finds-10000-high.html
Regulatory and accountability
European Commission. "Cyber Resilience Act." Regulation (EU) 2024/2847. https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
OpenSSF Best Practices Working Group. "Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers." https://best.openssf.org/CRA-Brief-Guide-for-OSS-Developers.html
NIS-2 Directive (EU) 2022/2555, Article 21(2)(d).
NIS-2 Directive (EU) 2022/2555, Article 23 (incident reporting obligations: 24-hour early warning, 72-hour notification, one-month final report).
Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 (DORA RTS on ICT risk management). https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng
Commission Delegated Regulation (EU) 2025/301 (DORA RTS on the content and time limits for reporting major ICT-related incidents). https://eur-lex.europa.eu/eli/reg_del/2025/301/oj
Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024 (DORA RTS on the classification of ICT-related incidents). https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng
Debian Project (2023). "Statement about the EU Cyber Resilience Act." https://bits.debian.org/2023/12/debian-statement-cyber-resillience-act.md.html
Red Hat. "Red Hat and the EU Cyber Resilience Act (CRA)." https://www.redhat.com/en/red-hat-eu-cyber-resilience-act
Canonical / Ubuntu. "The Cyber Resilience Act: What it means for open source." https://ubuntu.com/blog/the-cyber-resilience-act-what-it-means-for-open-source
Hoffmann, M., Nagle, F., Zhou, Y. (2024). "The Value of Open Source Software." Harvard Business School Working Paper 24-038. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4693148
Tidelift (2024). "The 2024 State of the Open Source Maintainer Report." https://www.tidelift.com/open-source-maintainer-survey-2024
OpenSSF / Alpha-Omega (2026). "Linux Foundation Announces $12.5 Million in Grant Funding to Advance Open Source Security." 17 March 2026. https://openssf.org/press-release/2026/03/17/linux-foundation-announces-12-5-million-in-grant-funding-from-leading-organizations-to-advance-open-source-security/
Black Duck (2025). "Open Source Security and Risk Analysis (OSSRA) Report." 25 February 2025. https://news.blackduck.com/2025-02-25-New-Black-Duck-Report
Incident response standards
NIST (2025). Special Publication 800-61r3, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile." April 2025. https://doi.org/10.6028/NIST.SP.800-61r3 [Supersedes SP 800-61 Rev. 2, withdrawn April 2025.]
CISA (2021). "Federal Government Cybersecurity Incident and Vulnerability Response Playbooks." November 2021. https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks
Background reference material
This paper draws on a prior internal analysis of the XZ Utils attack chain and the 2025-26 supply chain wave, and on a synthesis of vendor incident reports compiled for that analysis. Differential property monitoring as a forward research direction draws on Brechelmacher (2024), "Differential Property Monitoring for Backdoor Detection," TU Wien, published in Runtime Verification 2024, Springer LNCS, extending Muehlboeck and Henzinger (2021), "Differential monitoring," Runtime Verification 2021, Springer LNCS 12974.
A note on method and sourcing
This paper began as a personal exercise: a structured postmortem on the XZ Utils supply chain attack, tracing both the mechanics of the compromise and the defensive posture it exposed. That exercise grew into the argument here.
The structural positions in this paper draw on two decades of operational security experience across cloud infrastructure and financial protocol environments, including time at Amazon where the Shared Responsibility Model was built and tested as a working framework, not an abstraction. The argument about accountability distribution in open-source supply chains is an extension of that thinking into a different context, not a framework borrowed from secondary literature.
An AI-augmented workflow was used for drafting, cross-critique, and cross-referencing within a controlled project workspace. The models accelerated the work. The intellectual architecture, the sourcing decisions, and every position taken in the paper are the author's. Every architectural and quantitative claim was traced to a primary source and verified before inclusion.
Specific sourcing decisions worth noting. The wolfSSL device-population figure is stated as "billions" per the primary disclosure rather than a more specific figure that appeared only in secondary coverage. The Axios download figure of "approximately 100 million times per week" is widely cited across Tenable, Google GTIG, and Microsoft secondary reporting but has not been independently verified against npm registry primary data and is presented as reported. TrapDoor attribution is unconfirmed at publication date; the campaign is described on the basis of Socket Security's primary incident analysis with no attribution claim made. The Harvard $8.8 trillion demand-side figure is from the primary working paper and carries the methodological caveat noted in Part 5.1. Vendor capability claims are presented alongside the independent benchmarks that corroborate them and the published criticism that contests the framing.