To vet an open source maintainer, check five things in about 30 minutes: recent activity, how releases are built and signed, how past vulnerabilities were handled, whether more than one person can ship, and what the repository's automation can do. Score each, then decide to adopt, adopt with conditions, or pass.
Why a rubric beats a gut feeling
Most adoption decisions today are made on stars, download counts and a quick look at the README. None of those say anything about whether the people behind the code can ship safely, respond to a report, or hand over the project if they leave.
A rubric does two jobs. It makes the review repeatable, so two engineers reach similar answers. It also leaves a record you can show an auditor or a customer who asks how you choose dependencies.
This post gives the overview. Other posts in this series go deep on each row.
The five-row rubric
| Area | What you look at | Where to find it |
|---|---|---|
| Activity | Last release date, recent commits, issue response | Repository insights, release page |
| Release practice | Built in CI, provenance, signed releases | Registry page, workflow files |
| Vulnerability handling | Published advisories, time from report to fix | Advisory database, SECURITY.md |
| Continuity | Number of people who can publish, org or foundation backing | Contributors, registry owners |
| Automation risk | Workflow permissions, install scripts, pinned actions | .github/workflows, package manifest |
Give each row 0, 1 or 2 points. A project with 8 or more points is usually a clean adopt. Between 5 and 7, adopt with conditions such as pinning and monitoring. Below 5, look for an alternative or plan to vendor the code.
These cutoffs are a starting point of our own, not an industry standard. Tune them to your risk.
Start with the automated signals
The OpenSSF Scorecard project runs a set of checks against a repository, including Maintained, Code-Review, Branch-Protection, Security-Policy, Signed-Releases and Vulnerabilities. Each check scores 0 to 10, and the aggregate weights critical and high risk checks more heavily. You can run it yourself with scorecard --repo=github.com/OWNER/REPO or look up precomputed results through its public API.
Treat the output as a prompt for questions, not a verdict. See our post on how to read the score.
Then check the human parts
Automated tools cannot tell you whether the one maintainer has a successor, or whether the project is a side effort that may stop next month. Read the governance file if one exists, look at who has merged code in the last year, and see whether the project belongs to an organization.
Also remember what a good result does not prove. A package with verified npm provenance can still contain malicious code, because provenance shows where and how it was built, not that the code is safe. See valid provenance is not the same as safe.
Write the decision down
Record the date, the version reviewed, the score per row, the conditions, and the reviewer. One paragraph is enough. When the project changes hands or has an incident, you can compare against what you knew at adoption.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
How long should a maintainer review take?
About 30 minutes for a typical library, longer for something that runs in your build pipeline or handles credentials.
Do I need to review every dependency this way?
No. Apply the full rubric to new direct dependencies and to anything with install scripts or broad permissions. Transitive dependencies get a lighter check through automated scanning.
Sources
Last reviewed: 19 October 2026.
