Bus Factor: The Dependency Risk Hiding Behind Healthy-Looking Repos

The bus factor is the number of people who would have to be hit by a bus before a project can no longer be maintained. It is the bluntest metric in software, and for open-source dependencies it is routinely the most important one — because it is invisible in every number developers usually check.

A repository can have 40,000 stars, a green CI badge, weekly releases, and a Discord with ten thousand members, while 90% of the commits in the last year came from one person. Stars measure the audience. Bus factor measures the cast. Audiences are large and interchangeable; a cast of one cancels the show the day they burn out, change jobs, or get a life.

## When a low bus factor becomes a security hole

The canonical case is xz-utils. For years the compression library — a transitive dependency of practically every Linux system — was maintained by a single volunteer who openly wrote about being overwhelmed. A patient attacker operating as “Jia Tan” spent roughly two years doing helpful maintenance work (while sock-puppet accounts pressured the maintainer to share the load), earned commit access, and in early 2024 shipped a backdoor targeting OpenSSH, tracked as CVE-2024-3094 with a maximum CVSS score of 10.0. It was caught essentially by luck, when a Microsoft engineer investigated a half-second SSH slowdown.

The xz backdoor was not a code vulnerability. It was a bus-factor vulnerability: a project too important to fail, maintained by one person too exhausted to say no.

The non-malicious version happens constantly. In 2020 the sole maintainer of core-js — polyfills sitting under a huge share of the web — went to prison after a traffic accident, and development stalled for over a year. No attacker required; the dependency risk was the org chart.

## Why healthy-looking repos hide it

Nothing on a GitHub repo's front page surfaces contributor concentration. The contributors tab shows lifetime totals, which flatter projects that used to have a team. The signals that matter are recent and distributional:

• -Share of recent commits by the top committer. Look at the last 6–12 months, not all time. Above ~70–80% from one person, you are effectively depending on an individual, whatever the org name says.
• -Reviewer diversity. If every PR is merged by its own author, there is no second person who understands the code well enough to review it.
• -Maintainer transitions. A new name suddenly doing most of the merging is sometimes succession working as intended — and sometimes the opening move of a supply chain attack. Either way it deserves a look.

## What to do about a bus factor of one

A low bus factor is not an automatic veto — half the best libraries you use are one person's labor of love. It is a risk to be priced in:

• -Prefer the boring alternative when two candidates are close and one has a real contributor base.
• -Pin versions and review updates for single-maintainer dependencies in sensitive positions — install scripts, auth paths, build tooling.
• -Have a fork plan. Could your team maintain a frozen fork for a year if the maintainer walked away? If the answer is no and the dependency is load-bearing, that is a finding.
• -Fund the maintainer. The cheapest supply chain security money you will ever spend.

## Check it in seconds

The TrustOSS deep scan computes bus factor from recent commit concentration and reports it as an OK/WARN/RISK finding alongside CI health, known vulnerabilities from OSV, and real dependents from deps.dev. Run any repository through the analyzer before you depend on it — and if you are choosing between candidates, put them in a side-by-side comparison and see which one is a team and which one is a hero holding the roof up alone.