Your Software Is Mostly Other People's Code (and Some of It Got Poisoned This Month)

Here's something most people don't know about custom software, and it's the whole point of this post: when you pay a firm to build you an app, they don't type out every line from scratch. Nobody does. They assemble a lot of it out of free, pre-made building blocks that programmers all over the world share and download — millions of times a day. Your shiny custom thing is, under the hood, maybe ten percent the work of the people you hired and ninety percent parts pulled off a giant communal shelf.

That shelf is wonderful. It's the reason a small team can build something in months that used to take an army years. It's also, this month, the thing that got attacked.

What just happened

In the first couple weeks of June, a piece of malware quietly worked its way into more than a hundred and seventy of those free building blocks — the popular ones, the kind that get downloaded by the truckload. It even slipped into packages published under a well-known enterprise brand's name, so they looked completely legitimate. And here's the nasty part: it spread on its own. A developer downloads a poisoned block to do their job; the malware quietly grabs their passwords, keys, and access tokens; then it uses those to poison the next batch of blocks, which the next developer downloads. A worm, basically, crawling through the supply that everyone's software is built from.

This isn't a one-off. It's the loudest example of a pattern that's built all year — poisoned packages, stolen developer credentials, breaches riding in through a tool nobody knew they depended on. The attackers figured out something simple: why break into a thousand companies when you can poison one ingredient they all use?

Why this lands on your desk

You'll never see any of this. You don't pick the building blocks; your developers do. But the risk flows downhill to you, because those blocks end up inside the software running your business, touching your data and your customers.

So there's a question worth adding to your list when you hire someone to build software, and it's not one most buyers know to ask. Not "are your developers good" — assume that. The new one is: what do you actually do to keep poisoned parts out of my software?

The honest version of the answer

Let me tell you what a careful answer does not sound like: "Don't worry, we review everything." Nobody reviews everything. A normal app leans on hundreds, sometimes thousands, of these shared parts, each leaning on more. Reading every line, every time one updates, isn't humanly possible — and any firm that claims they do is either confused or fibbing.

The honest version is about containment — making sure that when a bad part slips through, and eventually one will, it can't do much. In plain terms, that's a few unglamorous habits. Pinning the exact versions of every part so a poisoned update can't sneak in overnight while everyone's asleep. Running automatic scans that flag known-bad packages before they're used. Keeping the keys and passwords off the machines where this code gets assembled, so a worm that lands there finds an empty drawer. And — the boring favorite — using fewer parts in the first place.

That last one matters more than it sounds. Every building block you add is another door into your software, sourced from someone you've never met. A simpler app with two hundred parts is genuinely safer than a flashier one with two thousand, the same way a house with three doors is easier to lock than one with thirty. A lot of "let's add this cool feature" decisions are quietly also "let's add forty more doors" decisions, and almost nobody prices it that way.

Where we sit

We use the communal shelf like everyone else — we'd be slow and silly not to. What we don't do is pretend we've personally vetted the entire internet. We pin our versions, keep the secrets off the build machines, scan what we pull, and lean toward fewer parts and simpler builds even when a bigger pile of dependencies would check a flashy box faster.

And sometimes the honest call is to talk you out of a feature — not because we can't build it, but because the only way to build it drags in a sprawl of third-party code that isn't worth the doors it opens for what you'd actually get. That's not a sentence that bills many hours. We say it anyway, because "we shipped you the exciting version and a worm rode in with it" is a much worse conversation to have later.

The question worth asking this week

You don't need to understand any of the technical machinery to use this. Next time someone's building or maintaining software for you, ask them plainly: "Most of this is made of other people's code — so what stops a poisoned piece of it from ending up in mine?"

If they walk you calmly through how they keep the bad parts out and contained, good. If they wave it off with "we've got it handled," remember that a hundred and seventy trusted building blocks got handled this month too — by the attackers.