When you add an open source library to your product, the code works today. The real question is what happens next: will security patches arrive while your customers still use the version you shipped? Will breaking changes land without warning? Will someone still maintain the project? These questions together make up the maintenance risk of the dependency.
Maintenance risk is the chance that a project stops being maintained, responds slowly to security issues, or changes in ways that force you to do unplanned work. It is different from the risk that the code has bugs today. A library can be technically excellent and still be a bad dependency if its only maintainer is burned out and its security fixes arrive six months after a vulnerability is disclosed.
The reliable signals are maintainer concentration, release cadence, vulnerability response time, and security policy. CI discipline and the project’s own dependency hygiene are the other two. Popularity signals such as GitHub stars and download counts tell you how many people depend on the project, but not whether anyone is maintaining it. Automated tools such as OpenSSF Scorecard give you a fast starting point, but you still need to read the repository and release history yourself.
Why GitHub Stars and npm Downloads Don’t Measure Maintenance
Safeguard’s risk-assessment guide makes the distinction sharply: GitHub stars, npm downloads, README quality, and last-commit recency measure popularity and activity, not health. A healthy dependency is one that will receive timely security patches, will not introduce unexpected breaking changes, will not be abandoned without notice, and will not become a vector for supply chain compromise. None of those properties show up in a star count.
The File Browser project is a concrete example. In June 2025, its maintainer reported that the project grew from about 3,000 GitHub stars in 2018 to about 30,000 stars almost 10 years later, but that the current maintainers do not have much time and the project sort of feels like abandoned. He moved it to maintenance-only mode with no new features and only bug fixes, and said that if no one steps up to actively maintain it, he will need to decide whether to archive it.
Raw issue counts, commit frequency without context, and code coverage percentages are similarly unreliable. A project with many open issues may simply have many users; a project with frequent commits may be churning without direction. You need the maintainer structure and release history to interpret these numbers.
Start With OpenSSF Scorecard, Then Check Maintainer Structure
OpenSSF Scorecard is an automated tool that checks a repository for security and maintenance signals, such as branch protection, continuous integration, signed releases, and a security policy. Safeguard calls it the best currently available starting point for automated health assessment, while noting that it is not perfect and can produce false positives or miss nuanced issues. Use the score to triage. A very low score tells you where to look, and a high score does not prove the project is safe.
The signal that matters most is maintainer concentration. A project with one maintainer has a bus factor of one: if that person becomes unavailable, the project can effectively stop receiving security patches, vulnerability triage, and responses to reports. Look for at least two active maintainers with merge permissions, and verify that commit activity is distributed across them rather than concentrated in one person.
Research on free and open source software maintainers found that high centralization in projects such as Rust Analyzer and Cargo may worsen burnout risk by placing undue pressure on key contributors. The same study describes the invisible labor maintainers do beyond code: user support, building trust, and managing relationships with other projects. When that work falls on one or two people, the project becomes fragile in ways that a commit graph does not show.
Governance style matters as well. The same research found that transparent and participatory governance increased contributors’ confidence and engagement, while projects led by a single "benevolent dictator" often frustrated contributors due to limited collaborative decision-making. A project with a published governance model and a path for new maintainers is easier to rely on than one where all decisions flow through one person.
Unresponsive maintainers also block progress. In the OpenBMC community, a technical oversight issue reports that some maintainers do not respond to code review or design documents quickly enough because they are busy or on vacation, and that unresponsive maintainers make it difficult for new features and new maintainers to advance. A project that cannot bring in new maintainers is a project whose risk grows over time.
Sustainable maintenance is possible, but it is a deliberate choice. Long-time CakePHP maintainer Mark Story reports staying active for 15 years by prioritizing endurance and burnout prevention over high throughput. When you evaluate a project, look for signs that the maintainers have built the same kind of sustainable rhythm.
Read the Release History for Cadence and Vulnerability Response
Release cadence matters more than release frequency. Predictable releases indicate process discipline, while sporadic bursts followed by silences may indicate maintainer burnout. When you evaluate a dependency, look at the last two years of releases and ask whether they follow a pattern you can plan around.
Security releases should be separate from feature releases. If a project bundles security fixes into large feature releases, you are forced to accept new functionality and its associated risk in order to get the patch. That coupling turns every security update into a potential migration.
Vulnerability response time is the most direct measure of security health. Consistent sub-30-day response times for critical issues are well above average, while a project that takes six months to address a critical vulnerability leaves you exposed for those six months. Check the project’s security advisories and see how much time passed between disclosure and fix.
Also check which versions the project supports. If fixes only land on the latest major version, you need to know whether your upgrade path is realistic before you adopt the dependency, not after a critical advisory appears.
Check the Project’s Own Dependency Hygiene
A project that is multiple major versions behind on its own dependencies is not actively managing its supply chain. Its lock file or dependency declarations can reveal accumulated transitive vulnerability debt: vulnerabilities in the dependencies of your dependency that you inherit by adoption.
Your dependency’s dependencies are part of your attack surface. Lineaje AI Labs reports that 95% of vulnerabilities stem from open-source dependencies, and attacks on open source and commercial software have grown, according to Secureframe’s summary of ReversingLabs’ 2025 report. When you review a candidate dependency, skim its dependency manifest and check whether the versions it pins are current and whether it updates them regularly.
Look for a Security Policy and CI Discipline
The absence of a security policy file, usually named SECURITY.md, is a reliable negative signal. A SECURITY.md file is not a guarantee of good security outcomes. Without one, reporters have no place to go, so vulnerabilities may sit undisclosed or unreported.
Look for automated testing and continuous integration (CI) practices: tests running on every pull request, security-specific checks, branch protection that requires CI to pass before merge, and signed releases produced by CI. Signed releases give you a way to verify that the artifact you install came from the maintainers and was not tampered with. Reproducible builds, where the same source produces an identical artifact, are the strongest form of this verification. At minimum, look for signed releases. NIST’s Secure Software Development Framework, published under Executive Order 14028, includes mechanisms for verifying software release integrity as part of secure supply chain practice.
Weigh the Signals Against Your Own Migration Effort
The assessment only matters relative to your usage. A dependency with perfect maintenance signals is still a bad choice if its API changes constantly and your code is deeply coupled to it. Consider how much of your code calls this library’s API, how often the project makes breaking changes, and whether you can upgrade quickly when a fix lands.
If the project bundles security fixes with breaking changes and your code is deeply coupled, every security patch becomes a migration project. That is a maintenance risk you create for yourself, independent of the maintainers’ behavior. Conversely, a stable, complete library that is no longer actively developed may be acceptable if you have reviewed it and it has no known vulnerabilities, because you are not depending on it for new features. One industry report argues that unmaintained open-source components might be less risky than commonly thought, a claim that runs against the usual assumption and should be weighed against your own review.
Know the Limits of Automated Scores
OpenSSF Scorecard is a starting point, not a verdict. It can produce false positives and miss nuanced issues, and no single metric or threshold decides whether a dependency is safe. The "at least two maintainers" guidance is a heuristic, not a standard. A project with three maintainers can still have a slow vulnerability response, and a project with one maintainer can be exemplary.
The UK government’s commissioned review of open source supply chain practices found that none of the formal OSS maturity models it examined were widely used, and that most developers judge maturity by their own discretion and experience rather than a formal organizational process. Trust in open source is subjective and based on the end developer’s perception, with quality the most discussed factor. Build your own repeatable review, document the signals you checked, and revisit the dependency on a schedule.
The same review recommends that organizations establish an internal open source policy and create a software bill of materials (SBOM) to track components and dependencies. For continuous supply chain monitoring, it recommends a software composition analysis (SCA) tool. An SBOM is a list of every component in your software; an SCA tool checks that list against vulnerability databases and alerts you when a dependency you already use needs attention. Automating these checks is a low-cost way to make the review repeatable. The review also recommends actively engaging with the open source community, which is how you learn about a project’s direction before it appears in release notes.
A practical review takes about an hour. Run Scorecard first to get a list of red flags, then open the repository and check the maintainer list, the last two years of releases, the security advisories, and the SECURITY.md file. Finish by reviewing the CI configuration and the dependency manifest. Write down what you found and the date, because the next review will compare against it.
Maintenance Risk Signals to Check
- Read the maintainer structure first: A project with one active maintainer has a bus factor of one. Look for at least two maintainers with merge permissions and distributed commit activity.
- Treat stars and downloads as popularity, not health: Popularity raises the stakes but says nothing about whether security patches will arrive.
- Measure vulnerability response time: Sub-30-day fixes for critical issues are well above average; a six-month response leaves you exposed for six months.
- Check the project’s own dependencies: A project multiple major versions behind is not managing its supply chain, and you inherit its transitive vulnerability debt.
- Use OpenSSF Scorecard to triage, not to decide: Automate the first pass, then read the release history, security policy, and CI practices yourself.
