Much of the open source your software uses depends on very few people. A Linux Foundation and Harvard study found that in about a quarter of the widely used projects it reviewed, one developer wrote most of the code added in a year. Manage that with inventory, pinning and monitoring, not by abandoning open source.
This explainer relies on that study and on CISA's alert about XZ Utils. It makes no prediction about future events.
What does the data say about concentration?
Census II of free and open source software application libraries was produced by the Linux Foundation and the Laboratory for Innovation Science at Harvard, with OpenSSF, using data from software composition analysis companies. It looked at what is most used in production applications.
In a review of 49 of the top 50 non-npm projects, using commits from 2021, the authors found that 23 percent of projects had one developer accounting for more than 80 percent of lines of code added. 94 percent had fewer than ten developers accounting for more than 90 percent. Across those 50 projects, 136 developers accounted for more than 80 percent of lines added. The report says this runs against the common belief that thousands or millions of developers maintain such projects.
It also notes that many top packages are hosted under individual developer accounts, which raises the importance of securing those accounts.
Treat these figures as a snapshot of one sample from 2021. They are not a measure of how any given project is run.
What does a single point of failure look like?
It is not only a lone maintainer. Four patterns recur.
A person: one maintainer who writes most of the code and holds the release keys.
An account: a package published under one personal login on a registry.
A build or release path: a single script or machine that produces the artifacts.
A shared component: a small library that sits underneath many others, so a flaw spreads through indirect dependencies.
The Census II context section recalls Heartbleed in OpenSSL in 2014 and Log4Shell in log4j in December 2021, noting that widely used projects with smaller maintainer bases can have flaws slip by unnoticed.
What did the XZ alert show?
On 29 March 2024 CISA reported that XZ Utils, a data compression library that may ship in Linux distributions, contained malicious code that could allow unauthorised access. It named versions 5.6.0 and 5.6.1 and recommended downgrading to an uncompromised release such as 5.4.6, checking systems for malicious activity and reporting positive findings. The alert is a good example of a compromise in a small, widely embedded component. It was handled in public by the community and by CISA, and teams with a current inventory could answer the first question quickly: do we run those versions?
How do you reduce your exposure?
You cannot fix the maintainer base. You can know where you depend on it.
Inventory every direct and indirect dependency so you can answer "do we run X?" in minutes. Pin versions and use lockfiles so an update is a decision, not an accident. Watch for signals such as one author on a package, long gaps between releases, and missing project health indicators; the Census report points to OpenSSF Scorecard and badge data as examples. Mirror critical packages internally so a registry or account problem does not stop your builds. Protect your own publishing accounts with MFA.
What to do
- Produce a dependency inventory for your top five applications, including indirect dependencies.
- Flag the packages that have one maintainer or no recent release.
- Pin versions and require review for upgrades of those flagged packages.
- Mirror the packages you could not rebuild without.
- Turn on MFA for every account that can publish.
- Write down who answers "do we run version X?" and how fast they can.
Quick check
Does one maintainer mean a project is unsafe?
No. It means the project depends on one person. Treat it as a risk factor, and check other signals such as release activity and security practices.
Which XZ Utils versions did CISA name?
Versions 5.6.0 and 5.6.1, with advice to downgrade to an uncompromised release such as 5.4.6.
Open the full demo at /demos/sca-dependency-inventory.
Sources
- Linux Foundation and Harvard: Census II of free and open source software, application libraries (PDF)
- Linux Foundation research page for Census II
- CISA: reported supply chain compromise affecting XZ Utils, CVE-2024-3094
Last reviewed: 18 October 2026.
