Your Processor's Dependency's Dependency Had a Bad Day

In the thirty days between late April and late May 2026, the following software supply chain incidents reached public disclosure: a poisoned PyTorch Lightning release targeting AI training credentials; compromised Ruby Gems and Go modules stealing CI/CD pipeline credentials; a self-propagating worm through npm packages; AI-generated malware embedded in npm packages by North Korean state actors; eight Packagist packages with GitHub-hosted malware; GitHub's own internal repositories breached through a malicious VS Code extension; a Trellix source code breach compromising a cybersecurity vendor's own tools; and a supply chain worm spreading through TanStack, Mistral AI, UiPath, and OpenSearch packages.

This is not an exhaustive list. It is the list that made the press.

The governance question is not whether software supply chains are insecure - they demonstrably are, and have been for years. The governance question is: who is legally responsible when a compromised dependency causes data loss, processing violations, or AI system failures affecting EU data subjects?

The GDPR Was Not Designed for Transitive Failure

GDPR Articles 28 and 32 create the legal scaffolding for answering this question. The scaffolding was designed for a simpler world - one in which you knew what software you were running, and that software did what it said on the package.

Article 28 governs the relationship between data controllers and processors. A processor acts on the controller's behalf and must provide "sufficient guarantees to implement appropriate technical and organisational measures." Controllers must use only processors who provide these guarantees, confirmed by contract.

Article 32 requires both controllers and processors to implement "appropriate technical and organisational measures" to ensure security "appropriate to the risk" - taking into account "the state of the art."

The supply chain problem breaks both frameworks in the same way: the compromised code is not the processor's code. It is the processor's dependency. Or the dependency's dependency. Or a build tool that both parties use without either having chosen it deliberately. The Article 28 contract covers the relationship between two parties. The attack vector runs through twelve.

When PyTorch Lightning was compromised on April 30, any organisation using that library to train AI models - as a data processor, handling training data that might include personal data - was running attacker-controlled code in their environment for forty-two minutes. The data controller's GDPR contract with the processor said nothing about PyTorch Lightning. The processor probably did not know they were using the compromised version until Semgrep published the IoC analysis. The controller definitely did not know.

Who breached Article 32? The processor, who failed to maintain "appropriate technical measures" over their dependency tree? The controller, who failed to perform adequate due diligence on their processor's software supply chain? The open-source maintainers who published the poisoned package? The repository platform that distributed it?

The honest answer is that Article 32, designed with commendable thoroughness for a world in which organisations know what software they are running, functions in practice as a system for identifying - after the fact - which party failed to prevent something neither of them knew was happening. It is a governance instrument optimised for the post-mortem. It is, in this respect, in distinguished company.

The State of the Art Was Not Formally Classified as Wet

GDPR's "state of the art" standard creates an obligation that moves with technology. What was adequate security in 2018 may not be adequate in 2026. But "state of the art" for software supply chain security in 2026 is genuinely contested.

NIST's Secure Software Development Framework recommends Software Bill of Materials generation, dependency verification, and code provenance tracking. The EU Cyber Resilience Act, which entered into force in late 2024, imposes mandatory security requirements for products with digital elements - including software - and explicitly addresses supply chain security. Article 13 CRA requires manufacturers to "identify and document vulnerabilities" and maintain an SBOM.

But CRA compliance timelines are phased: most requirements apply from December 2027. The incidents described above are happening now, before mandatory SBOM requirements have entered force for most actors.

This creates a temporal paradox. Organisations that are not proactively managing their dependency supply chains are operating in a legal grey zone: not yet violating CRA, but potentially violating GDPR's "state of the art" standard, which is assessed at the time of incident, not the time of legislation. "State of the art" does not wait for compliance deadlines. It is a rolling standard that incorporates published best practice regardless of whether the legislator has mandated it yet.

Simply put, this is the regulatory equivalent of being told somebody drowned in water that had not yet been formally classified as wet (or as liquid) - simultaneously compliant with the regulation that specifies the classification, and liable under the regulation that requires from person to swim.

The AI Training Pipeline Is the Highest-Value Target

What makes this particularly acute for AI systems is the training pipeline vector. The PyTorch Lightning attack was not targeting web application credentials. It was targeting credentials from AI training environments - the infrastructure where models learn from data. A compromised training pipeline is not just a security incident. It is a potential data integrity incident, an AI safety incident, and a GDPR incident simultaneously.

If training data includes personal data - as it does in any AI system trained on real-world business data - then a compromised training environment may constitute unauthorised access to personal data under Article 4(12). Breach notification obligations under Article 33 may be triggered. The compromised model weights themselves may need to be treated as potentially tainted - though EU law currently provides no framework for "model contamination" as a data protection concept.

We have - at least, at this moment - no vocabulary for a model that has been taught by an attacker without anyone noticing.

The EU AI Act's requirements for data governance under Article 10 specify that training datasets must be subject to appropriate governance practices, including examination for biases and ensuring suitability. A supply chain attack that introduces arbitrary code into the training pipeline invalidates these assurances retroactively. But neither the AI Act nor the GDPR specifies the remediation obligation when this happens. The regulation tells you what the training data should look like. It does not tell you what to do when someone has quietly replaced it.

The North Korean AI Problem

AI governance frameworks were not designed with North Korean state actors in mind.

The DPRK, for its part, did not notice that.

The campaign documented in late April 2026 demonstrates what this looks like in practice: North Korean actors embedded malware in npm packages using AI-generated code specifically designed to evade detection tools. The malware was less detectable because AI was used to generate variants that matched fewer signatures. AI is now a tool of supply chain attack, not merely a subject of governance.

The AI-generated malware is indistinguishable from legitimate code to automated scanners calibrated on human-written malware patterns. This is not a governance gap that better controls at the application layer will close. It is a fundamental challenge to signature-based security that requires rethinking the detection model entirely.

The deeper risk follows the monoculture logic: when the target of supply chain injection is not developer credentials but the model itself. Training data poisoning - the introduction of malicious patterns into the data used to train or fine-tune a large language model - has the same architectural profile as a supply chain attack: it occurs upstream of the point of use, it is invisible to the consumer, and it propagates automatically to everything downstream. The difference is its scale. A poisoned npm package affects the applications that install it. A poisoned training dataset affects every deployment of every model trained on it. And because enterprise AI deployments are increasingly converging on a small number of foundation models, a supply chain attack on a foundation model's training pipeline would not produce one compromised system. It would produce thousands of them, all sharing the same blind spot, simultaneously unaware that the blind spot exists.

A globally spawned system.

For legal practitioners, this raises a causation problem. If an organisation was compromised by AI-generated malware specifically designed to bypass existing security measures, can they argue that their existing measures satisfied the "state of the art" standard under GDPR Article 32 - since the state of the art did not yet account for AI-generated malware? Or does the public existence of this attack vector - disclosed in April 2026 - mean that any organisation that did not update its security posture after that date is now operating below the state of the art?

The answer probably depends on whether a court considers "state of the art" to include defences against novel AI-generated attack methods that have been publicly documented but for which no commercial countermeasure yet exists. This is not an academic question. It will be asked, in exactly these terms, in an Irish or German courtroom within the next two years.

The Liability Chain Runs Downhill

The supply chain incidents collectively reveal a liability chain that the law has not yet fully mapped - though the direction is clear enough.

Open-source maintainers may bear some responsibility under CRA if their products meet the definition of "products with digital elements" - but many lack the resources to comply, which is why CRA includes specific provisions for open-source stewards under Article 24. The PyTorch Lightning community quarantined the compromise in forty-two minutes. That is better incident response than most enterprise security teams achieve. The law rewards this poorly.

Repository platforms - GitHub, PyPI, npm, RubyGems - function as de facto infrastructure for global software distribution. Platform liability for content they distribute is contested, but CRA creates obligations for repository operators relating to vulnerability disclosure and notification. Whether that is sufficient when the platform itself is breached (as GitHub was, through the Nx Console extension) is a question the regulation did not anticipate needing to answer about its own enforcement infrastructure.

Software vendors using third-party dependencies are generally considered to have assumed the security risk of those dependencies under GDPR Article 32 and CRA Article 13. The Trellix breach illustrates this with uncomfortable precision: a cybersecurity vendor - a company whose entire business proposition is protecting others from exactly this kind of compromise - had its own source code exfiltrated through a supply chain vector. If cybersecurity vendors cannot secure their own supply chains, the "state of the art" standard is arguably demanding something that does not yet exist in practice.

Data controllers who deploy software built on compromised supply chains bear ultimate responsibility under GDPR for the processing they direct. The defence "my processor's dependency was compromised" is not available under the regulation as currently interpreted. The controller chose the processor. The processor's supply chain is the controller's problem. This is clear in law and increasingly absurd in practice - but absurdity has never been a defence against liability, merely an argument for reform.

What This Actually Requires

Adequate supply chain governance for organisations processing personal data now demands something more than annual vendor questionnaires and contractual representations. It requires mandatory SBOMs for all software in processing environments, with automated monitoring for component vulnerabilities. It requires Article 28 agreements that explicitly oblige processors to maintain and provide SBOMs, with audit rights that extend to the dependency tree. It requires dependency pinning and verification in CI/CD pipelines, validated against cryptographic attestations. It requires separate network zones for AI training environments, with enhanced monitoring for credential exfiltration. And it requires incident response procedures that specifically cover supply chain compromise scenarios - including a triage protocol for "tainted model" situations that nobody has yet standardised because nobody has yet admitted the problem at scale.

Most organisations do not have these controls. Most Article 28 agreements in force today do not require processors to maintain SBOMs. Most AI governance policies written in 2023 or 2024 do not address supply chain risk to training pipelines.

The incidents are not slowing down. The legal framework is catching up. The gap between the two - between the regulation that tells you what security should look like and the supply chain that has already decided what it actually looks like - is where organisations are exposed.

The supply chain is not a technical problem awaiting a technical fix. It is a governance gap with a legal address.

And liability, as ever, lives in the gap.