Ankit is a Senior Engineering Manager at GitHub, where he leads the Dependabot team in the Supply Chain Security organization.

getty

The name got me before the details did. Shai-Hulud, the sandworm from Dune. And what stuck with me wasn't the payload. It was the propagation. The September campaign compromised more than 500 packages; a second wave in November backdoored nearly 800 more and dumped stolen secrets into more than 25,000 repositories on GitHub.​

Malicious packages are old news. A worm that uses the package registry itself as its transport layer is something else.

I lead the engineering team at GitHub that builds Dependabot, the automation that opens pull requests when a project's dependencies need updating. That job gave me a front-row seat on 2025. The big lesson from the year: Automation moves whatever the registry serves it, good or bad, and the review step between a proposed update and production matters more than it ever has.

The numbers back that up. Sonatype, which monitors the public registries, counted more than 454,600 new malicious packages in 2025, a number that pushed the running total of known open-source malware past 1.23 million. More than 99% of it landed in npm. That's not an accident. Npm is the largest registry. It moves fast, and its culture of small, deeply nested dependencies means one compromised package can sit invisibly under thousands of applications.

The part that made me sit up was the research on update automation. GitGuardian showed this year that when teams take the human out of the loop, any automated update tool can end up carrying a malicious version downstream. Look at the mechanics, though. When a bad version of a legitimate package ships, an update bot does exactly what it was built to do: It opens a pull request and waits for a review. That pull request is the safety mechanism.

Dependabot doesn't even offer auto-merge; we removed that option back in 2021 on the principle that a dependency deserves a look before it lands. The exposure comes from teams wiring merges to happen anyway, through repository settings or their own workflows, so malware rides in with nobody reading the diff. The research is correct. But the failure it describes isn't the bot. It's the plumbing teams build around it to skip the review.

Any automation that moves code into a repository is a channel, and channels carry whatever they're given.

We added another layer in March: Dependabot now flags npm dependencies that match known malware advisories, a capability the company paused in 2022 when false positives buried teams in noise and brought back once the advisory data was strong enough to trust. My team built it, so weigh my judgment accordingly. It catches known malware before it ever reaches a build. What it can't do, what nothing on the market can do, is catch malware nobody has identified yet. Advisories trail creation everywhere in this industry. That gap is structural, and closing it takes layered defenses, not any single feature from any single vendor.

The second shift of 2025 has nothing to do with registries. Veracode tested more than 100 large language models on common coding tasks and found security flaws in 45% of the code it produced. Adoption isn't waiting for that number to improve. Most engineering organizations I talk to already have AI-generated code in production, and few review it more strictly than human-written code. Many review it less.

Stranger still is what happens when the models cite dependencies. A study presented at USENIX Security 2025 had 16 code-generation models produce 2.23 million samples and found that nearly one in five recommended installing a package that doesn't exist. The fake names were consistent, too: Forty-three percent of them reappeared every time the prompt was rerun. Attackers now register those hallucinated names and fill them with malware, a tactic that's picked up the name slopsquatting. It works because developers trust a confident suggestion more than they should, and it works often enough to persist.

Here's what I'd actually do, based on watching this from the inside. Keep the automated updates; they close known vulnerabilities faster than any manual process will. If you've wired auto-merge around those pull requests through repository settings or a custom workflow, unwire it for anything that touches install scripts, credentials or the network. The bot proposes; a person decides. That's the division of labor the tools were designed for. Treat your software bill of materials as a query tool rather than a compliance artifact, because when the next worm lands, the question that matters is whether you can map your exposure in minutes. And check that every package an AI assistant suggests actually exists and has a history before it enters a build.

None of this is glamorous. All of it is cheaper than an incident.

There's evidence the boring work pays. PyPI, the Python registry, made two-factor authentication mandatory and rolled out trusted publishing, and malware detections there fell 43% last year even as npms climbed. Attackers didn't lose interest in Python. The doors got harder to open.

I don't know whether 2026 brings a worm worse than Shai-Hulud, though I'd bet on it. The attacks are automated end to end now. The honest question for most engineering organizations isn't whether their tools are modern but whether any human still reads the code between the registry and production. If the answer is no one, that judgment has already been outsourced to the attacker's patience.

Disclosure: The author leads the GitHub team that builds Dependabot, one of the tools discussed in this article.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?