How much of the open-source software ecosystem has effectively been abandoned It sounds like the kind of question that should produce a number. It doesn't.
New research from the Value Chain Risk Institute found that the answer can change dramatically depending on something as basic as what researchers mean by “maintained.” In some software ecosystems, choosing one reasonable definition over another can produce abandonment rates several times higher or lower.
That is arguably the most important finding in VCRI's Q3 2026 State of Supply Chain report, authored by Joshua Marpet and Cairn Viktor.
The researchers set out to expand their earlier analysis and begin measuring changes in open-source maintenance risk over time. Instead, they discovered that the underlying measurement wasn't stable enough to justify that kind of precision.
Their conclusion is unusually straightforward:
“The honest unit for this measurement is a band, not a number.”
It's a finding that reaches beyond open-source maintenance. Cybersecurity has no shortage of percentages purporting to quantify risk. But when a methodological choice can move a number by a factor of two, three or even four, the problem isn't necessarily the data. It's the confidence we place in the number produced from it.
13.1 million packages didn't solve the problem
VCRI's previous quarterly report examined roughly the top 10,000 packages in each software ecosystem. For Q3, Marpet and Viktor went considerably bigger, expanding the corpus to 13.1 million packages across the eight ecosystems included in the report.
You might expect that enormous increase in data to dramatically improve the researchers' picture of open-source abandonment.
It didn't.
Because VCRI weights its analysis according to how many repositories depend on a package, the packages carrying the most dependency risk remain largely the same whether researchers analyze the top 10,000 or the full corpus. The resulting risk-weighted figures generally landed within roughly one percentage point of calculations using the smaller dataset under the same classification rule.
The researchers instead found that how they classified packages mattered much more than how many packages they analyzed.
Their problem was deceptively simple: How do you distinguish software that has been abandoned from software that simply hasn't needed to change?
A package that hasn't had a release in two years may be abandoned. Or it may be stable, finished software doing exactly what it was designed to do.
So VCRI calculated two boundaries.
The upper bound considers a package out-of-band if it hasn't had a release in 730 days. That risks labeling stable, complete software as abandoned.
The lower bound also requires no repository commit during that period. But that creates another problem: a dead package living inside an actively maintained monorepo can appear to be maintained because unrelated portions of the repository continue changing.
Neither definition is entirely right. Neither is entirely wrong.
The researchers therefore argue that the actual abandonment rate lies somewhere between them.
The difference isn't small
Look at Maven. Using VCRI's commit-aware lower bound, 7.6% of its dependency weight is out-of-band. Using release recency, that number becomes 33.8%. Same ecosystem. Same underlying corpus. Very different picture of its maintenance risk.
The ranges are substantial elsewhere:
- npm: 35.7% to 52.4%
- Go: 33.2% to 57.9%
- NuGet: 27.6% to 52.2%
- Maven: 7.6% to 33.8%
- PyPI: 10.6% to 24.5%
- RubyGems: 19.7% to 38.5%
- Cargo: 11.1% to 24.8%
- Packagist: 15.3% to 19.2%
For Maven, that's a factor of 4.4 between the lower and upper bounds. Whether roughly one-third of its dependency weight should be described as abandoned depends heavily on whether activity in a parent monorepo is considered evidence that an individual child artifact is still maintained.
That's not statistical noise. It can fundamentally change how a CISO, software security team, policymaker or regulator interprets the health of an open-source ecosystem.
The authors explicitly warn regulators against constructing requirements around a single abandonment percentage. Under equally defensible definitions, they note, the same ecosystem might be described as having an abandonment rate of 8% or 34%.
The problem isn't that one number is necessarily dishonest. It's that presenting one number without the methodological uncertainty behind it creates a degree of certainty that the data doesn't support.
The risk is real even if the percentage is fuzzy
None of this means abandoned open-source software isn't a serious software supply chain problem.
That's where the second half of VCRI's analysis gets more concrete.
Rather than simply count old or inactive packages, the researchers identified packages that are both out-of-band and have a verified history of security advisories, then ranked them according to the number of dependent repositories.
Those results are much harder to dismiss as an argument over methodology.
Among the npm packages is uri-js, with roughly 4.7 million dependents and a history that includes a regular-expression denial-of-service vulnerability. Other npm packages on the watch list include set-value, websocket-driver, websocket-extensions, deep-extend, sockjs, rc and eslint-utils.
Go includes gopkg.in/yaml.v2, the collapsed jwt-go, the superseded first version of the AWS SDK for Go, gogo/protobuf and src-d/go-git.v4.
PyPI includes pycrypto, which the researchers describe as collapsed and carrying eight advisories, while Maven's list includes log4j 1.x, commons-collections, old mysql-connector-java coordinates, Apache Derby, dom4j and jackson-mapper-asl.
Other ecosystems contain similarly familiar dependencies, including swiftmailer and the abandoned zendframework family in Packagist.
The report isn't claiming every current installation of those packages contains an exploitable vulnerability. Its compromise measure is based on security history rather than an intersection between advisory version ranges and the versions currently installed. That's an important limitation.
But the watch list makes the broader issue tangible.
Organizations don't necessarily need to know whether precisely 24%, 35% or 52% of an ecosystem is abandoned to take action. They need to know whether their applications depend on load-bearing packages that no longer have a reliable maintenance path.
VCRI recommends comparing its watch list against an organization's own SBOM and treating matches as migration candidates.
Malware dominates the numbers, but not the dependency risk
Another finding buried deeper in the research reinforces the same argument about how cybersecurity risk gets measured.
The researchers found that the npm vulnerability feed in OSV contains 219,723 packages with advisories. Of those, 216,506, or 98.5%, are malicious-package reports involving such activity as typosquatting, dependency confusion and account-takeover spam rather than traditional CVEs.
PyPI isn't far behind at 86%.
Those numbers sound alarming. Then VCRI weighted them according to dependencies, and the picture effectively flipped.
The hundreds of thousands of malicious npm packages have almost no dependents because many are throwaway package names that legitimate developers aren't intentionally installing. Not one made VCRI's dependency-weighted watch list.
As the researchers put it, malware is dominating the feed by count while disappearing by weight.
That's an important distinction for security teams consuming vulnerability intelligence. A feed containing hundreds of thousands of malicious packages doesn't necessarily mean those packages represent the dominant risk to actual production software.
Raw counts measure volume. They don't necessarily measure exposure.
The denominator matters
That may ultimately be the thread tying the report together.
Count abandoned packages and you can exaggerate risk by treating obscure, unused software the same as dependencies supporting millions of repositories.
Count malicious packages and you can create another distorted picture by giving a throwaway typosquat the same statistical weight as software sitting underneath a significant portion of the ecosystem.
Even counting repository activity isn't straightforward because monorepos make it difficult to determine whether activity reflects maintenance of a particular package.
The more useful question is not simply how many?
It's how much of the software people actually depend on is affected?
That's why VCRI uses dependent-repository counts as its risk weighting. As the authors put it, a million abandoned packages with no dependents matter less than ten abandoned packages carrying enormous dependency loads.
When the scary finding doesn't survive verification
There is another reason this report is worth paying attention to.
Marpet and Viktor describe several points during the research where they appeared to have found something much more dramatic.
A maintainer-turnover analysis initially appeared to reveal a potential package-takeover signal. Further examination found mostly benign churn.
An alarming npm abandonment number turned out to be inflated because stable, complete micro-packages were being counted as abandoned.
And a popular legitimate package was initially flagged as malicious because its name collided with a typosquatting malware package. The package did have a real historical CVE and belonged on the researchers' watch list, but the malware designation was wrong.
They documented those failures rather than quietly removing them.
“A report that only survives if you don't check its work is not research,” the authors wrote.
That's probably the larger lesson here.
The cybersecurity industry isn't suffering from a lack of numbers. Vendors, researchers, analysts and security teams generate enormous amounts of data about vulnerabilities, malicious packages, dependencies and software supply chain risk.
The harder problem is determining what those numbers actually mean.
There is clearly abandoned and unsupported software sitting underneath modern applications. Some of it has known security history. Some of it has millions of dependents. Organizations should find it and determine how to get off it.
But saying precisely how much open source is abandoned? For now, the most accurate answer may be the least satisfying one. It depends how you count.
