A developer pulls a package from a reliable repo. It is signed, has provenance, and has been scanned. And then…it contains malware.
That is no longer hypothetical. When the Miasma worm tore through the @redhat-cloud-services npm namespace in June, its malicious releases carried real SLSA provenance, because they were built in Red Hat’s own GitHub Actions workflows and published with legitimate OIDC tokens minted for those runs. To a registry scanner, the poisoned versions were indistinguishable from a routine update.
The closest analogy is a deepfake. On a video call, a synthetic face can pass at first glance, and you only catch it when something underneath gives it away. Software supply chain attacks have reached the same point, with one difference that makes them worse: A deepfake at least gives you something to catch. Miasma’s packages offered nothing at the level scanners look. The provenance was genuine; every signal a scanner checked was real, just worn by the wrong people. When attackers can put on the trust signals themselves, verification of those signals stops being a defence.
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. And 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.
from DevOps.com https://ift.tt/BsocK2S
Comments
Post a Comment