Don’t Deploy Another AI-built App Without Monitoring Its Dependencies
This attack passed all checks designed to stop it. Farida Khalaf shares a practical system for catching it the biggest security mistake AI-assisted builders make after deployment.
TL;DR On May 11, attackers used TanStack’s own GitHub Actions pipeline to publish 84 malicious versions across 42 npm packages, all carrying valid SLSA Build Level 3 provenance. The paperwork was real. The code was poison. Farida Khalaf shares two scripts for locking a dependency baseline, detecting changes, verifying integrity, and flagging silent updates. Her Supply Guard Deployment Gate prompt then turns the reports into a plain-language GO/NO-GO check before deployment.
On May 11, 2026. 19:20 UTC, something changed inside the TanStack project on GitHub. Theoretically, nothing broke. No warning lights flashed.
And yet.
During the 6 minutes that followed, one of the most sophisticated open-source supply chain attacks ever documented fooled even seasoned builders. 84 malicious versions appeared across 42 npm packages in the TanStack ecosystem.
The packages, trusted by many, checked every box. They had valid SLSA Build L3 provenance (their origin could be traced) and passed most standard integrity checks. By every measure builders normally use to separate legitimate files from suspicious ones, they looked legitimate.
Could these builders have avoided the attack?
Farida Khalaf, an AI and cybersecurity systems builder, analyzed the defences we can put in place beyond writing secure code and heeding warnings. And even better, she wrote and generously shared scripts and a prompt you can use today.
I’ve featured Farida before. Her guide, Vibe Coding x Cybersecurity, has been used and praised by many of my readers ever since. If you haven’t read it yet, do. My cybersecurity reading list on Substack has two non-negotiables: Farida Khalaf and ToxSec. I read both greedily. You’ll learn loads if you do the same.
Hey, I’m Karo Zieminski 🤗.
I’ve been smuggling ethics into tech since 2019 and spent the last several years working at the edge of AI product development, ethical AI, and AI-assisted building.
I also build with AI myself and write Product with Attitude, an AI newsletter for tens of thousands of readers across 146 countries, helping them develop critical AI literacy the only way it sticks: through practice.
Farida’s words below.
What happened to TanStack on May 11, 2026
On May 11, 2026, a group of hackers pulled off a heist on a software toolkit used by web developers worldwide: TanStack.
Rather than breaking down the front door, they slipped in through a side entrance. They created a GitHub account, forked the TanStack repository, and submitted what looked like a normal code contribution. They even gave the fork a boring name: zblgg/configuration. Easy to overlook in a list of forks. The attacker's code ran inside TanStack's trusted environment, with TanStack's keys, even though it came from a stranger on the internet. The PR itself didn’t need to get merged, just opened. That alone triggered the next step.
Three targets: passwords, cloud keys, secret tokens. developer or CI system that installed an affected Router/Start package version during that window got malware that hunted for them. Other TanStack package families remained clean.
Twenty-six minutes later, an external researcher noticed that something was wrong and filed a bug report. A human caught what enterprise tooling missed. Sobering.
Why AI-assisted builders are more exposed
Security is often treated as a matter to be settled during the build. The code is cleaned up, and credentials are kept out of source code; after that, you ship and assume you’re done. Wrong.
Deploying gives us that pleasing air of finality. But our builds remain tied to npm libraries we used. And their automated updates. Meaning that our code can change even if we don’t touch it ourselves. So the assumption that what worked yesterday is still safe today is wrong. And that’s what supply chain 1 attacks exploit.
1. When you build with AI, you don’t write everything from scratch. You borrow hundreds of pre-built components (libraries made by other developers) and your product depends on them to function. That’s the supply chain: not your code, but all the code your code relies on.
The TanStack attack arrived with immaculate paperwork of valid SLSA provenance. A legitimate GitHub Actions runner published them using legitimate OIDC tokens. Every official signal said all was well.
That means that being careful at install time is no longer enough. We need a system that follows our dependencies after deployment.
The System: Lock, Monitor, Verify, Alert
You don’t need complex infrastructure. A modest setup will do, provided four parts work together: a locked baseline, change detection, integrity verification and alerts for silent updates.
Two Scripts
The code is too long to include directly in the article, so Karo has made both scripts available to copy for free from this Notion doc.
Run the script for your stack before your first deployment to establish a baseline. Then schedule it to run after every dependency update in production.
The Prompt: Supply Guard Deployment Gate
The scripts produce a technical security report. Don’t worry if you can’t understand it yourself. Copy the complete output, paste it into Claude together with the prompt, and let it explain each finding in plain language. You’ll see what needs attention, and get a clear GO / NO-GO recommendation before you deploy.
Copy the prompt from this free Notion doc.
The New Security Boundary
The largest supply-chain attacks of 2026 share a dependence on trust. We routinely accept code from Github, especially when it comes from projects we already recognize. Modern software can’t function without it.
But as we learned from the TanStack example, visibility after release now forms the meaningful security boundary.
The scripts I shared can’t make your build invulnerable. But they shorten the time between a dependency changing and somebody noticing. Supply-chain attacks thrive during that delay.
Build with your eyes open and monitor your builds as though compromise is already active.
Statistically, in 2026, it may be.
— Thank you for reading, Farida.
Keep reading
Support my mission to spread critical AI literacy and help keep high-quality, human-authored content like this open and free by subscribing to Product with Attitude.










“The largest supply-chain attacks of 2026 share a dependence on trust. We routinely accept code from Github, especially when it comes from projects we already recognize. Modern software can’t function without it.”
this is absolutely a great way to put it. 2026 has been wild with supply chain attacks. i don’t think i’ve ever seen a time where we get them weekly and sometimes daily!
great article :)
Passing every provenance check and still being malicious is the scary part of this whole story.