Analysis · Published 27 Aug 2026

Your Open-Source Supply Chain Has a Bus Factor of One, and Your Scanner Can't See It

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

Dependency scanners inventory the code in your stack. They say nothing about the humans who turn a reported flaw in that code into a fix, and that human layer is where the real single point of failure lives.

Listen10 min

Key takeaways

The security posture of an open-source dependency rests not just on who writes the code but on who triages, forwards and tracks its incoming vulnerability reports, and that coordination job can quietly carry a bus factor of one.
SBOMs and dependency scanners answer 'what code is in my stack', never 'how many humans stand between a reported flaw and a fix', so the coordination layer never appears on the risk register.
The 'many eyes' assurance is a claim about attention, not headcount; when attention narrows to a single unpaid person who can name an end date, the model has already failed while the marketing built on it carries on.
The fix is a new line in dependency due diligence: for every component you lean on, name who coordinates its vulnerabilities, how many they are, whether anyone pays them, and what happens the day that number hits zero.

Every board now asks for a software bill of materials. Almost none ask who reads the email when a flaw is reported in the code on that bill. That second question is where open-source supply chain risk actually lives, and no scanner you own is pointed at it.

Here's the mechanism, because the mechanism is the whole argument. A vulnerability in a widely used component does not fix itself. Someone has to receive the report, judge whether it's real, route it to whoever can patch it, and track the fix until it ships. That work is coordination. It rarely shows up in a commit history, it almost never has a budget line, and it often rests on one person doing it out of habit and goodwill. The Linux Foundation's Census II of the most widely deployed open-source libraries put numbers on how thin that layer runs: a large share of the components holding up modern software are maintained by only a handful of contributors, and a meaningful share by a single unpaid developer.

One person is a bus factor of one. The phrase is grim engineering shorthand: how many people would have to be hit by a bus before a system loses knowledge it cannot recover. Applied to code, it's a familiar worry. Applied to security coordination, it's almost never measured, and it can fall from one to zero without a single line of code changing and without any tool registering an event. This is not hypothetical, and the sharpest recent lesson ran the other way round. In the xz-utils backdoor disclosed in March 2024 (CVE-2024-3094), a hostile contributor spent roughly two years earning the trust of an exhausted solo maintainer, then used that hard-won coordination role to slip a backdoor into a compression library shipped by most Linux distributions. It was caught by luck, by one engineer chasing a fraction of a second of unexplained latency. The danger was never only that the maintainer might leave. The single human seam where trust and coordination meet is itself the asset, whoever happens to occupy it.

What does a dependency scanner actually miss?

A scanner is very good at one question: which of these components has a known, published vulnerability with an identifier attached. That is worth having. But every part of that question describes the output of human coordination that already happened. Someone judged the flaw real, someone chose to publish it, someone assigned the identifier. The scanner sees the finished paperwork. It is blind to whether the office that produces the paperwork is still staffed.

An SBOM has the same shape of blindness. It is an inventory of ingredients and licences, a genuine improvement on not knowing what you ship. But an inventory of parts tells you nothing about the supply chain that maintains those parts. You can hold a complete, accurate SBOM for a product whose most critical dependency has exactly one unpaid human standing between a private vulnerability report and a public fix, and your SBOM will look identical the day before that person walks away and the day after. The document cannot represent the risk because the risk is not a property of the code. It is a property of the people, and people are not in the file format.

This is the part that should worry anyone who has signed off a due-diligence process on the strength of tooling. The tools measure what is cheap to measure. Coordination capacity is expensive to measure, so it goes uncounted, and uncounted risk has a way of being assumed to be zero.

The 'many eyes' claim was always about attention, not headcount

The reassuring folklore of open source is that with enough eyes, all bugs are shallow. It gets quoted as though it were a law. It's better read as a claim about attention: enough people paying enough attention will surface and resolve problems faster than a closed team could. The word doing the work there is attention. A component can ship in a billion devices and still have exactly one person reading its incoming security reports, and the users who never look contribute nothing to the eyes that matter.

So the honest test of the many-eyes assurance is not how many people use a component or even how many have ever committed to it. It's how many are paying attention to its incoming security reports this quarter. When that number is one, the folklore has already quietly inverted: you don't have many eyes, you have one, and that one can announce a leaving date. The marketing that rests on the assurance keeps running long after the assurance stopped being true, because nobody updated the folklore when the staffing changed.

The AI report flood makes a thin layer thinner

Now add pressure. Machine-generated vulnerability reports are cheap to produce and expensive to dismiss, because a plausible-looking false report costs the sender nothing and costs the triager real minutes to disprove. curl is the clearest case where a maintainer names the cause outright. Its lead maintainer, Daniel Stenberg, has publicly documented a rising flood of AI-generated 'slop' security submissions arriving through the project's bug-bounty channel: plausible enough to demand a human's attention, and, in every case he walks through, bogus. AI is only part of it. Triage volume is climbing for ordinary reasons too. When the Linux kernel became a CVE Numbering Authority in February 2024, with kernel developers Greg Kroah-Hartman and Sasha Levin running the assignment process, it began issuing CVE records at a rate of thousands a year, enough to rank it among the largest single sources of CVEs. That volume is a standing triage load in its own right, no automated slop required. Point enough submissions of any kind at open-source projects, and you crowd the exact chokepoint this argument is about: the single human doing triage.

Watch how a rational maintainer responds to that pressure, because the second-order consequence is the interesting part. It has already played out, and it has a name. In May 2025, Nick Wellnhofer, the largely solo and unpaid maintainer of libxml2, a parsing library embedded in browsers, operating systems and countless applications, announced he would stop treating security reports as confidential and handle serious flaws as ordinary public bugs, because coordinating them privately had become more unpaid work than one overwhelmed person could carry. A diffuse public good became a narrow, conditional, withdrawable service, offered by whoever still has the patience for it, on whatever terms they can bear. Faced with more noise than they can process for free, a volunteer can reasonably decide to serve fewer projects, to stop forwarding reports they can't verify, or to close the queue. Each of those is a sensible individual choice. Each shrinks the surface of security work that gets done at all, and every one of those choices lands downstream, on everyone who depends on the component without ever contributing to it.

How do you audit vulnerability coordination?

You add a line to your dependency risk register that your current tooling will not fill in for you. Call it the coordination bus factor. For each component your security posture genuinely leans on, and be honest about which those are, answer four questions. Who triages its incoming vulnerability reports? How many humans is that, really? Is any of them paid to do it, by anyone, or is it goodwill? And what is your plan on the day that number reaches zero?

Most organisations cannot answer the second question today, which is the finding. If you don't know whether a critical dependency's security queue is watched by a team, a person, or nobody this month, you are managing that risk on faith rather than on evidence. Getting to an answer is ordinary diligence work, the same discipline you'd apply to a sole-supplier component in any other supply chain, and it belongs in the same conversation as the rest of your technical strategy and risk assessment rather than bolted on after an incident.

The uncomfortable corollary is about money. Enterprises earning real revenue from products built on community software have learned to fund the code: sponsorships, paid maintainers, contributions sent upstream. Far fewer fund the coordination layer beneath it, the unglamorous work of triage and forwarding and tracking, because it isn't a feature and doesn't demo. That is a foreseeable single point of failure sitting unbudgeted under a flagship product, and 'foreseeable and unbudgeted' is the exact phrase that turns up in the post-incident review. If you're serious about the resilience of systems you don't own, funding the humans who coordinate their security buys down a risk your scanner has been hiding from you. It's the same logic we apply when we help clients design systems that keep a human in control of the loop: automation is only as trustworthy as the human process it can't replace.

The code in your stack is inventoried, licensed and scanned. The people who defend it are none of those things. For every dependency that matters, that headcount is answerable today, and it costs far less to answer it now than to learn the answer in the middle of an incident.

Questions people ask

What is a bus factor in software security?

It's the number of people who would have to become unavailable before a system loses knowledge or a function it can't recover. In security coordination it means how many humans stand between a reported vulnerability in a component and a shipped fix. When that number is one, a single person leaving ends the function, and unlike a code change it leaves no trace in any scanner or repository, so nothing in your monitoring flags it.

Why doesn't an SBOM or a dependency scanner catch this risk?

Because both tools measure the code, not the people who maintain it. An SBOM inventories which components and licences you ship; a scanner flags components with known, published vulnerabilities. Both describe the state of the code. Neither can represent how many humans are available to triage the next report, because that is a property of staffing and goodwill, not of the software, and staffing has no field in the file format.

How can a business assess the human resilience of a critical dependency?

Add a coordination bus factor to your dependency risk register. For each component your security genuinely relies on, identify who triages its incoming vulnerability reports, how many people that actually is, whether any of them are paid to do it, and what your contingency is if that number reaches zero. If you can't answer the headcount question, that gap is itself the finding, and funding or backing up that human layer is a real control rather than a nice-to-have.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.