Nobody Broke In. We Let Them In.

A closer look at how supply chain attacks turned everyday trust into the biggest hole in modern security

A weird kind of break-in

Ask someone to picture a hacker at work and they’ll probably imagine a hooded figure typing furiously, trying password after password until a firewall gives way. That’s not really how the scariest breaches of the last few years have gone. In a lot of the worst cases, nobody “broke in” at all. They just waited for the front door to be opened for them, by someone who had every reason to think they were doing something perfectly normal.

That’s the strange, slightly unsettling logic of a supply chain attack. Instead of going after a company directly, an attacker goes after something the company already trusts: a piece of software it installs without a second thought, a vendor it’s used for a decade, a tiny code library some developer pulled in on a Tuesday afternoon to save themselves an hour of work. The target doesn’t get hacked so much as it gets handed the malware, wrapped up in something familiar.

SolarWinds, or: how a routine update went very wrong

If you want to understand why this style of attack scares security people more than almost anything else, it’s worth sitting with what happened to SolarWinds. It’s a company most people outside IT had never heard of before 2020, but its network monitoring software was quietly running inside thousands of organizations, including some pretty serious government agencies.

The attackers here didn’t bother trying to breach those thousands of organizations one at a time. Way too slow, way too risky. Instead, they got into SolarWinds itself, worked their way into the software build process, and slipped malicious code into what looked like an entirely ordinary update. That update got signed, packaged, and pushed out the normal way. Customers installed it the same way they’d installed dozens of updates before it, because why wouldn’t they? It came from SolarWinds. It was signed. It looked exactly like it was supposed to.

And then it just… sat there. Quietly. For a while. No loud alarms, no obvious weirdness. That patience is honestly the part that gets me — this wasn’t a smash-and-grab. It was someone willing to plant something and wait, betting correctly that nobody would think to double-check a routine vendor update. By the time it came to light, the damage had already spread far beyond anything a traditional firewall could have stopped, because the firewall was never the thing that failed.

The organizations that got hit didn’t screw up. They did the responsible thing

— kept their software updated — and got burned for it anyway.

Meanwhile, the same thing happens every week in open source

SolarWinds got headlines because of who it hit. But a smaller, quieter version of this same problem happens constantly in the world of open-source code, and honestly it might matter more, just because of sheer volume.

Here’s the thing about modern software: almost nobody writes it from scratch anymore. A developer building an app will reach for dozens, sometimes hundreds, of free code packages from public repositories — npm if you’re doing JavaScript, PyPI if you’re in Python — rather than reinventing something that already exists. It’s a genuinely great system most of the time. It’s also a huge, mostly unguarded door.

One trick that keeps working is what’s called typosquatting — an attacker publishes a fake package with a name that’s one letter off from something popular, betting that a developer typing fast will fat-finger the install command and grab the wrong one without noticing. Another, honestly nastier approach: attackers target the popular package itself. Sometimes that means compromising a maintainer’s account. Sometimes it’s even simpler — a lot of these hugely important packages are maintained by one exhausted volunteer in their spare time, and an attacker just offers to “help out” and take over maintenance. Either way, once they’re in control, they slip malicious code into what looks like a normal update, and because thousands of other projects automatically pull in that package, the poison spreads almost instantly, with basically nobody watching.

What makes this so hard to get a handle on is just the scale of it. A single app might depend, directly or through a chain of other dependencies, on a couple thousand separate packages, most written by people the developer has never met and never will. Nobody’s reading all of that code line by line. Nobody realistically can. And attackers absolutely know it.

Why this isn’t going away anytime soon

It would be nice to treat each of these incidents as a one-off, a fluke, a lesson learned. But the pattern keeps repeating because it’s not really about any one company slipping up — it’s baked into how software gets built now. Everything is assembled out of other people’s parts, and the whole system runs on trust that mostly goes unexamined. A signed update is trusted because it’s signed. A popular package is trusted because it’s popular. Neither of those things actually proves the code is safe. They just feel like proof, because checking every dependency by hand isn’t realistic when software ships this fast.

There’s also just… better math for attackers here. Compromise one popular package, or one trusted vendor’s build process, and you might get access to thousands of downstream victims in one move. Compare that to attacking companies one at a time, the old-fashioned way. It’s not even close, which is a big part of why this style of attack has become the go-to move for more sophisticated groups, including ones believed to have state backing.

So what actually helps

There’s no clean fix for a problem this structural — I wish there were. But the organizations that handle this reasonably well tend to share a few habits. They actually know what software and dependencies they’re running, which sounds obvious but a lot of teams genuinely can’t answer that question with any confidence. They scan for known vulnerabilities before code reaches production instead of after something’s already gone wrong. And they pay attention when something about a trusted package changes unexpectedly — a new maintainer nobody recognizes, a permission request that doesn’t fit, code that doesn’t line up with the version history.

None of that requires paranoia or grinding development to a halt. It’s really just about building a little bit of skepticism into a process that currently has almost none. Pinning dependency versions instead of blindly grabbing the latest release. Checking signatures instead of assuming they mean what they used to mean. Having some kind of plan for the day a trusted component turns out not to be trustworthy — because for a lot of organizations, that day eventually comes.

The uncomfortable takeaway

What supply chain attacks really expose is how little of modern software is actually self-contained. Every app is a tangle of dependencies and vendors and trust relationships that stretch out further than most people realize, and honestly further than most companies could map even if they tried. That’s also exactly what makes software so fast and cheap to build now, so it’s not like the answer is to go back to writing everything from scratch.

The real lesson from SolarWinds, and from the steady drip of npm and PyPI incidents that never quite make the news the way SolarWinds did, is that trust can’t just be granted once and forgotten about. It has to be checked, again and again, because the moment it isn’t is exactly the moment someone’s waiting for.