The code nobody on your team wrote

Ask who wrote a company's website and the answer is usually a name or two. A developer, an agency, maybe a small team. It is almost never the true answer. Most of the code running a modern site was written by people nobody at the company has met, published to a public registry, and pulled in automatically the moment the project was installed.

We measured this on one of our own builds. NURAO, the online store we engineered end to end, depends directly on 46 packages. Each of those 46 was chosen on purpose. Installing them pulls in 1,353. The 1,240 distinct package versions in that tree can be published by 909 different accounts, and roughly half of them, 614, are maintained by a single person. Seven run their own scripts on the build machine the moment they install. None of this is unusual. It is what a careful build looks like today, and most builds are not careful.

For years that arrangement mostly worked, because trust held. This year it stopped holding. In August, a self-spreading worm Microsoft named ChainDrop moved through the npm registry, compromising more than 1,300 package versions with roughly two billion combined monthly downloads, according to Singapore's Cyber Security Agency. Its method was simple. Steal one maintainer's publishing token, inject malware into every package that maintainer owns, publish a new version, and wait for the world to install it. The payload ran at install time, collected cloud keys, GitHub tokens and other secrets from the machine, and used them to reach further. Two months later the pattern had not slowed: between 26 and 28 October alone, GitHub's advisory database logged 106 malicious npm and PyPI packages, from crypto miners to credential stealers.

What makes this different from the usual security story is where it lands. The website itself may never look broken. The damage happens on the developer's laptop and the build server, where the keys to the hosting account, the database and the payment provider live. A business can do everything right on the visible side and still be exposed through a package three layers down that nobody on the team has ever opened.

The common reaction is to file this under developer problems. It is a business problem with a developer-shaped entry point. Whoever holds the keys to the build also holds, one step removed, the customer data, the payment flow and the domain. A compromised build machine is a compromised business.

There is no version of modern software without dependencies, and rewriting everything in-house would trade one risk for a larger one. The answer is discipline around the trust that has to exist. Every dependency should earn its place, because each one is a door. Exact versions get locked in a lockfile, so a build installs exactly what was reviewed and nothing newer slips in silently. Brand-new releases wait a few days before they are allowed in, long enough for most poisoned versions to be caught and pulled. Install scripts stay off by default, with the few that genuinely need them allowed by name. Build machines hold only short-lived, narrowly scoped credentials, so a stolen token opens one door instead of every door. And in the browser, a strict Content Security Policy limits what any script, including a compromised one, is allowed to load or send.

Checking costs very little compared with not checking. When ChainDrop was disclosed, the first question for any team was simple: are any of the compromised versions in our tree? For NURAO the answer took seconds, because the lockfile records exactly what is installed. None of the affected packages appear anywhere in it. A team without a lockfile, or one that installs whatever is newest on every build, cannot answer that question with any confidence.

This is the part of engineering nobody sees, and it is exactly why it gets skipped. A rushed project ships the same features as a careful one. The difference only shows up the week a registry gets poisoned, when one team spends an afternoon confirming they are clear and the other spends a month finding out what left the building.

Software will keep being built from other people's code. The question worth asking of any website or app is not who wrote it. It is who decided what it was allowed to trust.