SAN FRANCISCO — This past fall's
Shai-Hulud worm attacks may be only the beginning of an epidemic of similar attacks that weaponize the automatic-update features of many open-source-software repositories to create backdoors, steal information, or cause any kind of digital mayhem, two security engineers said in a presentation at the RSAC conference here last week (March 25).
"Today, updater automation has real authority," explained Shilpi Mittal, lead security engineer at Tyson Foods. "A dependency updater can pull changes, write fixes, merge PRs [pull requests], and publish artifacts."
Dependency dangers
As most developers know, the open-source ecosystem is a vast and tangled universe of tens of thousands of pieces of software referring to and depending on each other to function. Open-source code often finds its way into commercial projects as well, so proprietary software is not immune. Whichever way you look, it's dependencies all the way down.
To tame this mess, which is now too complex for any human to keep track of, many open-source repositories use auto-updating
continuous integration/continuous delivery (CI/CD) functions, such as GitHub Actions or AWS CodeBuild. If one piece of code is updated far down the line, it automatically propagates upward and outward so that all other pieces of software that depend on it receive the updated version.
This is a great idea in theory, but it also creates a vast
supply-chain attack surface for miscreants to add
malicious code.
"If any part of that chain is compromised," said Mittal, "the attacker can get code execution inside your organization."
If enough of the process is automated, both inside and outside of an organization that uses open-source software, then malicious activity may escape human detection and get to the point where it reproduces itself across an environment and becomes a true software worm.
"We can't review everything," Mittal said, "so attackers can 'spray and pray' across registries" to get results.
She defined an autonomous-dependency worm as a self-propagating supply-chain compromise that uses CI/CD to modify other projects and repositories.
"The worm rides trusted automation to turn one foothold into a repeatable spread across repositories, languages and registries," she explained. "It doesn't have to be perfect — just good enough."
Living off the land
But shouldn't existing tools catch this kind of activity? Not unless it involves a known malicious package, has a static pattern or signature, fails policy changes or has obvious anomalies, Mittal said. It can instead live off the land, change variants, spread using stolen tokens, or run only in development environments.
"Scanning tools aren't built to scan run-time behavior," she said.
We've already seen worm-like signals in open-source software, Mittal said. The
xz-utils backdoor (CVE 2024-3094) of 2024 was not a worm, but it demonstrated how malicious code could be added to a widely used project with almost no one noticing.
In 2025, the
tj-actions/changed files GitHub Action bug (CVE 2025-30066) forced repositories to leak secrets, while the Shai-Hulud NPM worms were genuinely self-replicating. In January 2026,
six serious flaws were found in top package managers that would enable more auto-update worms.
How to stop auto-update worms
To defend against this kind of self-propagating supply-chain attack, Ankit Gupta, principal security engineer at Exeter Finance, recommended a practical playbook using four layers that would work even when scanners fail.
Layer 1, he said, is to govern autonomy by disabling auto-merge, requiring code owners to approve build or CI changes, quarantining new software maintainers, and enforcing
MFA and short-lived publish tokens.
Layer 2 hardens CI/CD runtimes by eliminating long-lived secrets, restricting egress, and separating test cycles from publishing cycles.
Layer 3 verifies provenance by signing, attesting, and verifying updates and generating provenance attestations in CI.
Layer 4 detects and contains the spread of dependency worms by looking for unusual publish patterns, CI secrets accessed unusually, new outbound destinations, new post-install/pre-install scripts, or similar code appearing across multiple packages.
"Autonomy is the new attack surface and identity is the work's fuel," said Gupta.
Yet, as Mittal made clear, this kind of attack has surprisingly little to do with the main topic of this year's RSAC conference.
"This is not about
AI being dangerous," she said, "but about autonomy itself."
