The Software Nobody Owns—and Everyone Uses

The library sat four levels deep in the dependency tree, under the SDK, the framework, and everything else. It had 40 million downloads a week and two maintainers. One had stopped responding in March.

Nobody on the platform had heard of it. Everyone was running it in the payment path, the session layer, and the build that shipped that morning. When the review asked who owned it, we traced it to the team that imported its parent years ago. The real question was who owned the code, and the honest answer was a stranger, unpaid and unresponsive to email.

This is the standing condition of modern platforms, not an anomaly. The software nobody owns runs everything, everywhere, including the systems your regulators audit and your customers trust. The problem isn’t that this software exists. The problem is what your organization does with the fact, which at most companies is nothing.

The Misfiled Problem

Ask an engineering organization how it manages dependency risk, and it will show you a scanner: software composition analysis, CVE feeds, and a dashboard with severity colors. These are useful and necessary but answer the wrong question. Scanners report vulnerabilities in shipped code. They’re trailing indicators disguised as controls.

The question they cannot answer is the one that matters: who owns this code? Who reviews its changes before they become yours? What happens when the person who understands it leaves or hands the keys to whoever asks nicely?

The XZ Utils backdoor was the proof case. That compromise was not a bug that got through; it was an ownership transfer. A patient attacker spent years befriending an exhausted volunteer maintainer, earned commit rights, and inherited a dependency embedded in half the world’s servers. No scanner detected it because there was nothing to scan until there was, and the world got lucky. The vulnerability wasn’t in the code. It was in the ownership structure, and nobody monitored that because ownership isn’t a field in the CVE database.

Dependency risk is filed under security. It is actually an ownership problem, and misfiling it means your controls watch the code while the real attack surface, the people and governance around the code, goes unmonitored.

The Org Chart Ends at the Manifest

Inside your walls, every line of code has an owner: a team, a review gate, an on-call rotation, someone whose name comes up when it breaks. You built that accountability deliberately because unowned code inside the walls is unacceptable.

Then someone types import, and the structure stops.

Past the manifest, there is no team, no gate, no rotation. There’s a repository, a display name, and your assumption that popularity implies stewardship. Every dependency is a hire you never interviewed—with commit access to the path that imported it. Transitive dependencies are worse: hires your hires made. Your direct manifest lists a few dozen names you chose. Your lockfile lists thousands you’ve never read, and your accountability model covers none of them.

The scale of that gap is easy to demonstrate but routinely ignored. Most engineering leaders can name their vendors, contractors, auditors, and every external party with platform access except the largest category: the strangers who wrote what ships inside the binary.

Governing What You Don’t Own

You cannot own the upstream. You can own the boundary. Five decisions, each requiring an accountable name, none requiring a new tool first.

Inventory is a live system, not an audit artifact. An SBOM generated annually for compliance is a photograph of a moving object. The useful version is queryable on demand: what do we run, where does it sit, and what depends on it? If answering “are we exposed to X?” takes longer than a coffee break, you don’t have an inventory—you have paperwork.

Tier by blast radius, not popularity. The dependency in the payment path and the one in the linter do not warrant the same scrutiny. Pretending they do creates scrutiny theater. A small tier-one list that someone watches is better than total coverage nobody reads.

Adoption is an architecture decision, not an import statement. Today, adding a stranger’s code to a regulated path is a one-line diff any engineer can merge. That’s a hiring decision made without an interview, background check, or signature. For tier-one paths, adoption needs an owner who says yes on the record, not a committee but one accountable person with authority to say no.

Watch health, not just CVEs. Maintainer count, bus factor, release cadence, responsiveness to reports, and issue-tracker quality are leading indicators of the failures that matter: abandonment and capture. None appear in a vulnerability feed. The scariest signal in open source isn’t a critical CVE. It’s a tired maintainer asking if anyone wants the keys.

Have an exit before you need one. For every tier-one dependency, the question “what do we do if this dies tomorrow?” should have a written answer: vendor it, maintain fork-readiness, or fund it into health. Deciding under incident pressure means the answer will be chosen for you—and it’ll be the most costly one.

On one regulated platform, running this exercise produced an uncomfortable surprise: the scariest item on the tier-one list wasn’t the cryptography library everyone worried about. That one was audited, funded, and institutionally maintained. It was a small utility, four levels down under a payments SDK, with one maintainer and no succession plan. The formal risk register included the crypto library, but the actual risk had never been written down anywhere.

The Cheapest Control Is a Paycheck

One more decision belongs on the list, and it sounds like philanthropy until you price it. If a revenue-critical path depends on a volunteer, the exposure isn’t the code but the volunteer’s circumstances: burnout, a new job, or a persuasive stranger offering to help. Funding the maintainer, contributing engineering time, or sponsoring the project isn’t generosity. It converts an unmanaged single point of failure into a relationship with obligations. Companies pay six figures for vendor SLAs on software that matters less. The cost of keeping a load-bearing maintainer solvent is a rounding error compared to the incident it prevents.

Own the Boundary

The software nobody owns will keep running your platform either way. That part isn’t a decision you get to make. It’s been made by every dependency choice in your history, and it renews itself with every build.

What remains yours is the boundary: knowing what crosses it, tiering what matters, naming who answers for it, and paying for what can’t be allowed to fail. Nobody owns the software. Someone has to own the dependency.

Start with your manifest. Read the whole thing once. You won’t like its answers either.