Signed, Attested, and Malicious: The Software Supply Chain Has a Deepfake Problem

From Forging Signals to Wearing Them

For years, software security rested on one assumption: that signing, verified maintainers, provenance, and attestation were hard to fake. To the average eye, a package called requets looks like requests - but a careful eye, or a decent scanner, could spot the seam. The attackers learnt to stop trying, so they started going upstream of it - compromising the accounts and pipelines that issue those signals.

The pattern is now well documented. Shai-Hulud, the first self-propagating npm worm, surfaced in September 2025, stealing maintainer tokens to republish poisoned packages. By late November, its second wave, “The Second Coming,” had backdoored 796 npm packages totalling more than 20 million weekly downloads.

In 2026, the payload was open-sourced as Mini Shai-Hulud. Attackers hijacked TanStack’s release pipeline mid-workflow, and its own trusted identity published malicious packages carrying valid SLSA provenance - it was the first time a poisoned package had shipped with genuine attestation. Days later, the worm swept more than 300 malicious versions across AntV packages in under half an hour, now minting real attestations for every package it spread to. Then came Miasma, where attackers published from inside Red Hat’s own pipeline, and the trust machinery did the rest. Within days, the same worm had moved into 73 Microsoft GitHub repositories, planting files that executed the moment a developer opened the code.

Inheriting the Trust Stack

A single stolen login now carries the full weight of the trust stack behind it. Miasma began with one compromised employee’s GitHub account, and researchers traced the Mastra compromise to a stale contributor credential that still held publish access to all 144 packages in the namespace. In Miasma’s case, the system then did exactly what it was built to do - it signed and attested the malware.

The parallel with deepfakes holds in two specific ways. First, there’s no fixed signature to catch: the worm writes a uniquely encrypted payload for every infection, so hash-based indicators are useful for one copy. Second, it strikes when a developer’s guard is down. The dropper fires when an infected repository is opened in Claude Code, Gemini CLI, VS Code, or Cursor, and a later variant goes further, planting a plain English instruction file that tells the AI agent to run the payload as a routine setup.

And for developers, the uncomfortable part is that nothing is technically broken. Provenance and attestation were built to answer one question: Did this come from where it says it did? These attacks live entirely inside the “yes.” SLSA’s own threat model puts “software producer intentionally submits bad code” explicitly out of scope - trust of the producer, it notes, is a separate property from integrity. SLSA’s maintainers made the same point in their own Mini Shai-Hulud post-mortem: SLSA records evidence, but policy decides what’s acceptable. Provenance tells you how something was built, not whether it’s safe to run. There’s no bug here to patch, because nothing failed on a technical level.

What Actually Has to Change

The fixes sit in the pipeline between the registry and the build, and they run on behaviour rather than paperwork:

• Watch what a package does - install hooks, network calls, what changed between versions - and watch the account behind it: one person does not legitimately publish 144 packages in 88 minutes.
• Treat brand-new versions as unproven until they’ve aged, because malicious releases are typically caught within hours, so even a short holding window strips out most of them before they ever reach a build.
• Catch it at ingestion. By the time an advisory lands, anyone who installed a package inside the exposure window is already compromised.

It’s also worth being honest about the limits. Enforcing provenance verification would have stopped Mastra, whose organisation generated attestations but never required them, so the registry accepted updates that quietly dropped the signature. It would not have stopped Miasma, whose provenance was entirely real. Signature checks are necessary but no longer sufficient on their own.

You catch a deepfake by watching what’s underneath the face - the expression that doesn’t fit, or the delays that follow. Software needs the same instinct: a control point between the open registry and the developer’s machine. Hold a package there, examine what it does before it touches a build, and make policy-as-code and continuous scanning the default posture rather than the retrofit. The problem this industry has to solve now is that the signatures will keep checking out.