A note before I start. I spent six years of my career on software supply chain risk. I don’t write doom posts for clicks. I believe everything is patterns, and if we barely caught these types of attacks before AI, then we will sure as shit miss them in the current AI boom.
In December 2020 the world found out about SolarWinds. Attackers got inside the build system of a company that made network monitoring software, slipped a backdoor into a routine update, and let SolarWinds sign it and ship it for them. Roughly 18,000 customers installed it, including Treasury, Commerce and Homeland Security. Those customers did everything right. They patched to the latest version. Auto-update, anyone?
I joined aDolus the year prior, working on cyber supply chain risk for OT and ICS (aDolus was later acquired by Exiger). SolarWinds turned our niche into a headline overnight. Boards wanted to know what was inside the software they ran, and SBOMs went from a conference talk to a federal requirement. The industry promised it would not get caught like that again, even though it had yet to create a clear mechanism to protect itself.
My prediction: within the next 24 months we will see a software supply chain attack at the scale of SolarWinds or worse. Probably more than one, and it will likely go undetected for MUCH longer. The cause is going to be vibe coding.
I’m not against vibe coding. I’m quite an advocate for it. But depending on how you use it, it can get scary pretty fast.
SolarWinds took a nation-state a lot of time and money. Russia’s SVR spent months inside one build pipeline waiting for the best time to drop SolarWinds.Orion.Core.BusinessLayer.dll, and the payload was pushed to people who trusted the vendor (and why wouldn’t they? Look at that dashboard!).
Now look at how people build software in 2026. Someone who has never heard of npm asks a model to build them an invoicing app. The model picks the packages, writes the install command and runs it. The human approves it by hitting enter, or the harness approves it for them. The lockfile goes unread because the builder doesn’t know what a lockfile is. The app goes live with a Stripe key in an environment file and four hundred dependencies the owner has never heard of. They don’t even know what a dependency is.
The human trusts the model, the model trusts the registry, and the registry trusts whoever published last. I have emailed npm about poisoned packages, and after nearly a month they still haven’t removed them. YIKES.
We already know this vector well.
A 2025 USENIX Security paper out of the University of Texas at San Antonio ran 576,000 code samples through 16 models. About 20% of the packages the models recommended did not exist. The made-up names also repeat. Ask the same question ten times and 43% of the fake names come back every time. A repeatable hallucination is a target. Register the name, publish something that works, and wait for the model to recommend it to the next thousand people. Researchers call it slopsquatting, and it needs zero hacking. You only have to be early. Yes, this is less likely in 2026 because the harnesses are better at checking their work. It is still possible, and open models are on the rise without the same safety mechanisms in place.
In August 2025, attackers pushed malicious versions of Nx, a build tool with millions of weekly downloads. They skipped writing their own search code. Their script checked whether Claude Code, Gemini CLI or Amazon Q was installed, then asked the victim’s own AI assistant to search the disk for crypto wallets and secrets. They used the AI as the burglar.
The next month, a maintainer behind chalk and debug got phished. Eighteen packages with roughly two billion weekly downloads between them shipped malware. Expect more of this. A week later came Shai-Hulud, a worm that stole npm tokens from each machine it landed on and used them to publish infected versions of that developer’s other packages. It spread by itself through hundreds of packages before anyone got it under control.
Those attacks hit careful engineers who read changelogs and turn on MFA. Now imagine millions of builders who can’t tell a real package from a fake one, who never see the install command scroll by, and who wouldn’t know what to look for if they did.
“The model will catch it.” WRONG. Today the only mechanism is a harness that blocks installs. Even then, the model tells the user they can run the command themselves (just change to manual mode!). The model has no way to know if a package is legit, short of downloading the source and checking it. Models with defensive capabilities only look when they are told to. The big labs likely won’t give them that directive, because it hurts the UX and makes their models feel slow (and of course you only get access to those expens… I mean defensive models if you apply for them). Case in point, this Anthropic blog post that came out after this post was first published, that says:
We encourage organizations to explore using Claude to analyze and reduce the attack surface of the software they depend on. We expect this to be one of the most practical ways that developers can measurably improve the security of the code the world already runs on.
The TLDR: Ask your bot to reduce the attack surface of the software you build.
Hey Janet from accounting, don’t forget to say “reduce the attack surface in my software” at the end of every session. Just like, don’t reuse the same passwords, just like don’t click on links in sus emails. Good luck.
SolarWinds had one vendor, one product and one update. Once someone found it (which took 9 months), they knew what to pull. The vibe-coded world has no single throat to choke. The blast radius is every app a model has ever touched, and the prize is much, much bigger than the app itself. The agent runs on the builder’s laptop next to their SSH keys (which they likely didn’t set up themselves), their cloud credentials (which are likely exposed in their chat sessions), their browser sessions and their email. An agent that installs packages on its own is a remote code execution feature the builder opted into.
The supply side is getting worse at the same time. Registries are filling with vibe-coded packages from maintainers who also don’t read the code. Publish tokens sit in plain text. The xz backdoor in 2024 took two years of social engineering to get commit rights on one project, and someone found it by complete fluke. If you’ve heard me talk about it, you know the many eyes theory has not proved itself to me. At 2.9 billion commits a month on GitHub, I think it is now impossible and we should stop pretending.
When the big one lands, the attackers will also stay hidden longer. SolarWinds sat undetected for 9 months inside companies with security teams. Code review used to be where a second person squinted at a weird line and asked why it was there. On most vibe-coded projects (and vibe coding is gaining ground in large enterprises) that step is gone. The people shipping these apps don’t know what a code review is, so they don’t miss it, or they have been told it’s no longer required. This is a closed and open-source software problem, and it’s also a new hole punched through corporate networks. “Why wouldn’t we let marketing use Claude, they are 20x’ing productivity right now!!”
The fixes are boring. Pin your versions. Let a new release sit for a week before you take it. Read the name of every package before it installs. Run the agent in a box that can’t see your keys. The people who most need these habits will never hear or learn about them. They don’t even know why. They have never felt the pain of a “breaking change.” They ask “why doesn’t it work?” and the model makes it work.
That leaves two lines of defense: tools that catch it before it installs, and maintainers who need to stay vigilant in an almost impossible time.
I have built detection tools for more than half a decade, and I can assure you that CVEs, antivirus and other detection tools are not equipped to find new attacks. 70% of all software supply chain attacks have nothing a known bad list will carry until AFTER the attack, and yet that’s where all the money flows. You might be thinking, “but ML and AI and sandboxing and...” blah blah blah. Did you know that most tools are STILL trying to figure out what open-source package was compiled into a program and then match that to a known bad list? Or reading your SBOMs and matching to CVEs? That is a joke, and it is security theatre at best.
Stopping the oncoming wave will take something serious, and it has to look different from the detection tools we are used to. SolarWinds needed a nation-state. The next one needs a package name, a model willing to recommend it, and millions of builders who don't know what npm is.