Intro
If you missed the news this week: OpenAI confirmed that two of their employees got compromised through a supply-chain attack on TanStack, a popular open source library used across the JavaScript ecosystem.
The numbers are worth pausing on:
84 malicious versions pushed in a 6-minute window
Detected by a researcher within 20 minutes
Long enough to compromise developer machines at one of the most security-conscious AI companies in the world
Credentials stolen, internal source code repos accessed, signing certificates now being rotated
Read that again. OpenAI – a company with a serious security team, threat modeling maturity, and resources most of us will never have – got hit because a dependency they trusted got hijacked upstream.
This Is the New Normal
This isn't an isolated incident. In the last 18 months we've seen:
- March: North Korean actors hijacked Axios, potentially exposing millions of developers
- May: Chinese actors compromised Daemon Tools, hitting thousands of Windows machines
- This week: TanStack → OpenAI
The pattern is consistent: attackers no longer chase the fortress. They poison the supply line.
And if you ship software in 2026, your supply line is your package.json, your requirements.txt, your go.mod, your Cargo.toml.
The Uncomfortable Question
How many of you can answer these right now, without checking?
How many direct dependencies does your main project have?
How many transitive dependencies does that translate to?
When was the last time any of them were audited?
Do you have alerting if a dependency you use suddenly publishes a version with new network behavior?
Would you notice if a malicious version got pulled in during a routine npm install?
For most teams I talk to, the honest answer is: no, no, never, no, and probably not.
Not because developers are careless. Because the modern dependency graph is genuinely too large for human review, and "trust the registry" has been the default for a decade.
What Actually Helps
A few things that move the needle, ranked roughly by effort:
Low effort:
Pin your dependencies. Lock files exist for a reason. Use them.
Enable Dependabot/Renovate with manual review on major bumps – not auto-merge.
Audit lockfile diffs in PRs the same way you audit code diffs.
Medium effort:
Run continuous dependency scanning. Not once a quarter – continuously. Vulnerabilities get disclosed daily.
Track maintainability and code smell trends. Compromised packages often introduce code that looks structurally different from previous versions.
Establish a "dependency budget." If you don't need it, don't pull it in.
Higher effort:
SBOMs (Software Bill of Materials) for everything you ship.
Internal mirrors with delay windows – let new versions soak for 24-72 hours before they're available to your builds.
Code signing verification at install time.
The Takeaway
If OpenAI's developer machines can get owned through a dependency, yours can too. Probably more easily.
The era of treating open source dependencies as "free, trusted infrastructure" is over. They are infrastructure – but they're not free, and trust has to be continuously verified.
Audit your package.json this week. You'll find something.
Top comments (0)