A dependency does not need a fixed number of reviewers. What you want to know is whether changes are reviewed by someone other than the author and whether the main branch is protected. For solo projects, a missing second reviewer is common and should lower your trust in proportion to the package's role.
What the three checks measure
OpenSSF Scorecard has three checks that bear on this.
Code-Review determines whether the project requires human code review before pull requests are merged. It looks at roughly the last 30 commits for an approval or for a merger who differs from the committer, which counts as implicit review. Reviews can detect unintentional problems and may detect or deter an attacker who subverted a contributor's account.
Branch-Protection checks whether the default and release branches are protected with branch protection or repository rules, which can require review or passing checks and prevent rewriting public history. Some settings it examines need an admin token to query, so a result without one may be partial.
Contributors checks for recent contributors from multiple organizations. Full marks require contributors from at least 3 companies in the last 30 commits, each with at least 5 of those commits. The check reads the Company field on GitHub profiles.
Read the result against project size
| Project shape | What to expect | How to treat it |
|---|---|---|
| Large, multi-company | High scores on all three | Strong process signal, still check provenance |
| Small team, one company | Review yes, Contributors low | Normal, low concern |
| Solo maintainer | Review low, protection varies | Raise scrutiny for risky roles |
| Bot only commits | Code-Review may be unclear | Look at who approves bot changes |
The Scorecard docs are direct about this. Some projects cannot meet the Contributors bar, such as small projects with one active participant, or projects with a narrow scope.
Compensate when review is thin
If the dependency has one maintainer and no review, you cannot fix the project, but you can limit your exposure:
- Pin an exact version and review upgrades before they land.
- Use a short wait before adopting new versions, so problems surface first.
- Prefer packages with a build attestation, which at least ties artifacts to a source.
- Avoid giving the package install time or build time access you would not give a stranger.
- Keep a replacement in mind and note it in your review.
Where this can mislead
Scores reflect a sample of recent commits and can swing with a few merges. A bot-heavy history can hide who approves what. Company fields on profiles are optional, so a healthy community can look thin. Take the check as an invitation to look at the repository's recent merged pull requests yourself for ten minutes.
Try it yourself
Click through it at your own pace, or open it full screen. It shows a pull request held by a gate, which is the same idea applied to your own repository.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for pull requests, plus SBOM and dependency scanning. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a solo maintainer a dealbreaker?
No. Many widely used packages have one maintainer. Adjust scrutiny to the package's role and add your own controls.
Does a high Code-Review score guarantee safe code?
No. It shows a practice, not an outcome. Reviewers can miss things.
Sources
Last reviewed: 19 October 2026.
