The OpenSSF Concise Guide for Evaluating Open Source Software organizes its checks into seven sections: initial assessment, maintenance and sustainability, security practices, usability and security, adoption and licensing, practical testing, and code evaluation. It is a menu of checks, not a score, so pick the ones that fit the risk.
The seven sections
| Section | What it asks |
|---|---|
| Initial assessment | Can you avoid the dependency? Is this the authentic project, not an impostor or unofficial fork? |
| Maintenance and sustainability | Recent activity and release in the past 12 months, communication from maintainers, more than one maintainer, version stability |
| Security practices | Best Practices badge, up to date dependencies, repository security, audits, security response, scores, tests, vulnerability status |
| Usability and security | Safe API design, interface stability, secure defaults, security guidance, vulnerability reporting instructions |
| Adoption and licensing | Clear license, name verification, real world use, suitability for your problem |
| Practical testing | Test it in isolation, check dependency impact |
| Code evaluation | Completeness, malicious code check, sandbox testing, secure coding evidence, reviews, static analysis, running tests |
Why it is useful
Most teams do some of this by instinct, in different ways for different people. A shared list makes decisions repeatable. It also stops the common failure of checking only the license and the star count.
Notice what the guide does not do: it gives no pass mark. It expects judgment. That is a feature, since a parser for untrusted input and an internal date helper should not face the same bar.
Turn it into a routine
- Pick a short core set for every new package, such as necessity, authenticity, activity, release recency, vulnerability status, reporting process and license.
- Add a deeper set for higher risk packages: audits, secure defaults, sandbox testing and code skim.
- Define high risk for your team. For example, packages that parse untrusted input, run at install time, or handle secrets.
- Record the answers in the pull request that adds the package.
- Revisit on upgrade or on a trigger, such as the project going quiet.
Where tools help
Several checks can be automated. Scorecard automates repository practices, deps.dev shows the dependency graph and known advisories, and an SBOM scanner covers vulnerability status. The human parts remain: necessity, suitability, and the call on what a flag means.
Do not treat the guide as a checklist to tick for compliance. The aim is to find the packages that deserve a closer look and to make the decision visible.
Keep it short enough to use
A guide with 30 items will be skipped. Start with the seven item core set and add items only when an incident or near miss shows a gap. For a ready made short version, see the 10 minute checklist before adding a dependency.
Try it yourself
Open the demo and look at the dependency inventory. Ask which seven checks you would run on each row.
Click through it at your own pace, or open it full screen.
Quick check
Does the OpenSSF guide give a pass or fail score?
No. It lists checks and expects you to apply judgment according to the risk of the package.
Do I need to run every check on every package?
No. Use a short core set for all packages and the deeper checks for higher risk ones.
Safeguard's SBOM and dependency scanning, vulnerability management and policy gates cover the automatable parts of this routine for your dependencies. Try the free scan.
Sources
- OpenSSF Concise Guide for Evaluating Open Source Software
- OpenSSF Scorecard checks documentation
- deps.dev documentation
Last reviewed: 19 October 2026.
