The OpenSSF Concise Guide for Evaluating Open Source Software asks five maintenance questions: has there been activity in the last 12 months, are there recent releases or announcements, is there more than one maintainer, was the last release within 12 months, and does the version signal instability. Use them as a quick screen, not a verdict.
The five questions
| Check | What the guide asks |
|---|---|
| Activity level | Significant recent activity, such as commits, within the previous 12 months |
| Communication | Recent releases or announcements from the maintainers |
| Maintainer diversity | More than one maintainer, ideally from different organizations |
| Release recency | Last release within the previous 12 months |
| Version stability | Whether the version string suggests instability, such as starting with 0 or including alpha or beta |
The guide's premise is that most software needs continuous maintenance, and unmaintained software is also likely to be insecure. It adds a fair caveat: even strong open source may do poorly on some questions, and many widely used projects have one maintainer.
How to answer each one
- Activity. Open the commit history and look at dates and authors, not just totals.
- Communication. Check the releases page, changelog and any project blog or mailing list.
- Maintainer diversity. Count people who merged changes recently. Check whether they work for different organizations.
- Release recency. Look at the registry page and the tag list, since the two can differ.
- Version stability. Read the version and the project's own statement about stability.
How to read a mixed result
A stable library may have few commits because it is finished. A new project with a 0.x version may be well run. Neither failure is automatically disqualifying. The useful step is to name the reason.
| Result | Question to ask next |
|---|---|
| Quiet for 12 months | Is the project feature complete, or has it stalled? See is a last commit two years ago abandoned |
| One maintainer | Can others release, and is there a backup? |
| Version 0.x | Does the project document its stability and breaking changes? |
| No announcements | Where do security notices appear? |
Where the guide goes next
Beyond maintenance, the guide covers security practices such as branch protection, security audits, security response and a vulnerability reporting route, plus adoption and licensing checks. The maintenance section is the cheapest to do first, because it needs no tooling.
Using it in a process
Turn the five questions into a form attached to your dependency approval step. Record the answers, the date and the reviewer. For a related approach using automated checks, see what OpenSSF Scorecard measures.
Try it yourself
Click through it at your own pace, or open it full screen. Pick a component and think about which of the five questions you could answer for it.
Safeguard can help with the inventory part. Its SBOM and dependency scanning lists what your projects actually pull in, so you can see which components you depend on and decide where to look closer. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a project with no commits in a year always unsafe?
No. The guide treats it as a risk signal to investigate, since a finished project may be quiet.
Does the guide say one maintainer is disqualifying?
No. It asks for more than one, ideally from different organizations, and notes that many widely used projects have one.
Sources
Last reviewed: 19 October 2026.
