Open source is just where you can see it.

Two stories broke on the same day. Google said it caught hackers using AI to find and exploit a previously unknown vulnerability for the first time. That same day, an attacker pushed 84 malicious versions across 42 npm packages in the TanStack project. Twelve million people install one of those packages every single week.

That timing isn't a coincidence. It's the new normal.

I've been building on open source since the early days of the web. My first websites were hand-coded HTML stitched together with libraries I pulled off random forums. Almost everything we build at Red Barn sits on top of open source. PHP,Apache, Linux, Node packages. Without open source, the internet looks completely different. Smaller. Slower. More expensive. Less innovative.

I don't want anyone walking away from this post thinking open source is the problem. It isn't.

Here's the part I want to make clear up front. Open source is where you see these stories. The code is public. The build pipelines are public. The post-mortems are public. That visibility is a feature.

Closed-source software has the same supply chain. It just runs out of view. When a vendor's build system gets compromised, you might never hear about it. SolarWinds is the cautionary tale everyone remembers. There are plenty of others you've never heard of.

So when I talk about open source attacks in this post, I'm using them as the visible example. The lesson applies to every piece of software your business runs on. Free or paid. Open or closed. SaaS, on-prem, the stuff your team logs into every morning. All of it.

The pattern

Look at what's been happening.

A self-replicating worm called Shai-Hulud tore through npm, hitting packages with over 2.6 billion weekly downloads combined.

Then the Axios HTTP library got compromised. 70 million weekly downloads. Attributed to a North Korean state actor.

Then Bitwarden's CLI tool got hit. So did Aqua Security's Trivy scanner. So did core SAP developer packages.

Then TanStack. 84 malicious versions across 42 packages, with over twelve million weekly downloads on one of them alone.

Around the same time, Google announced AI-discovered zero-days are no longer theoretical.

These aren't isolated incidents. They're a pattern. And the pattern tells you something important.

What the attackers are actually attacking

None of these attacks found a flaw in the source code of the package. The code wasn't the problem.

The TanStack attackers didn't steal any credentials. They didn't need to. They exploited a GitHub Actions workflow, poisoned a build cache, and pulled an OIDC token straight out of the runner's memory during a build. Then they used the project's own legitimate release pipeline to publish malicious versions. The packages even had valid cryptographic provenance attached.

Read that again. The packages were cryptographically signed as legitimate, because they came from the legitimate publishing pipeline. The attackers didn't break the lock. They walked in through a side door nobody knew was open.

This is the shift, and it isn't specific to open source. Attackers aren't going after the code. They're going after the trust chain. The build process. The CI/CD pipeline. The signing keys. The maintainer accounts. The cache. The publish workflow. The vendor's release infrastructure.

A closed-source vendor has all of the same plumbing. Build pipelines, signing keys, CI runners, release infrastructure, credentials with publish access. The attack surface is identical. The difference is you can't see it.

The code is fine. The plumbing around the code is what's leaking.

Why AI matters here

Before AI, finding these chains was hard. It required deep understanding of GitHub Actions, npm internals, OIDC token flows, vendor build systems, and how they all interact at the seams. That's a small group of people.

When AI can read documentation, map systems, and surface the gaps between trust boundaries faster than any human, that small group just got a lot bigger. Effectively infinite.

This is the part I keep saying. AI didn't replace the skill. It made the skill cheaper to apply. Anyone with a goal and a little patience can now throw AI at a problem and find weaknesses that used to take years of specialization to spot.

What does that mean for software in general? The same thing it means for the old cPanel box nobody patched. The threshold for "worth attacking" just dropped to zero, and the speed of attack just went up by an order of magnitude. Open source. Closed source. Your CRM. Your accounting platform. The marketing software your team logs into every day. All of it.

What this actually means

If you write software, here's what changes.

You can't just install a package and forget it. You need to know what's in your supply chain. Every direct dependency. Every transitive one. Pinned versions, not floating ones. Lock files committed. Install scripts disabled by default where you can get away with it.

You need to assume the publish pipeline is part of your security perimeter, not separate from it. Two-factor on every account that can push code. Tokens scoped narrowly. OIDC bindings reviewed. Build processes treated like production systems, because that's exactly what they are.

You need to slow down updates. Most of these compromises were caught quickly. CISA now recommends not installing any package that hasn't been published for at least seven days. That sounds like a small change. It will catch the vast majority of these attacks before they reach you.

If you run a business that depends on software but doesn't build it, here's what changes.

You're in a supply chain whether you know it or not. Every tool you log into runs on code somebody else wrote, built on a pipeline somebody else maintains. When that pipeline gets compromised, you inherit the problem.

Ask your vendors about their supply chain. Not their security policy. Their supply chain. Where do their dependencies come from? When do they update? Who has access to push code? How do they verify a build is what they think it is?

If they can't answer those questions, that's the answer.

What hasn't changed

The fundamentals.

I've been saying this my whole career, and it's still true. Know what you own. Patch what you use. Don't trust what you can't verify. Two-factor everything. Least privilege everywhere. Keep things simple enough that you can actually understand them.

These rules apply to every piece of software your business touches. Free or paid. Open or closed. The ones you write and the ones you buy.

The attackers got faster. The plumbing got more complicated. The basics are still the basics.

Open source isn't broken. The trust around it needs work. So does the trust around everything else we run on. That's a fixable problem. It's also a permanent one. Trust isn't something you build once. It's something you maintain.

We're going to look back on this period as when software supply chains grew up. The technology was already mature. The operational practices around it weren't. They will be, because they have to be.

Keep building. Just pay attention to what you're building on.