Check that it is authentic, maintained, handles security reports well, has clear licensing, behaves safely when run, and survives a quick code read. OpenSSF's concise guide lists 36 steps. An hour on the highest value ones catches most obvious problems before you adopt a project.
How the guide is organized
The OpenSSF guide organizes its steps into groups: initial assessment, maintenance and sustainability, security practices, usability and security, adoption and licensing, practical testing and code evaluation. Where a step lacks its own rationale, the group's rationale applies.
A one hour routine
Minutes 0 to 10, authenticity. Confirm the project is the real one, not a personal fork or a lookalike. The guide suggests checking the name, the website link, fork relationships, foundation affiliation, creation date and popularity, as a defense against typosquatting.
Minutes 10 to 20, maintenance. The guide looks for significant commits and a release within the past 12 months, more than one maintainer (ideally from different organizations), and version strings that signal instability such as a leading 0, alpha or beta.
Minutes 20 to 35, security practices. Check how fast security bugs are fixed, whether older releases get fixes, whether the project has an OpenSSF Best Practices badge, and what the Scorecard result shows. Look for existing security audits and verify the findings were fixed. Confirm there are instructions for reporting vulnerabilities.
Minutes 35 to 45, licensing. Every component should have a license, an OSI license for open source, and one that fits your use. The guide also asks you to check whether a similarly named, more popular package exists.
Minutes 45 to 60, practical test. Add the dependency as a test, preferably in an isolated environment, and check for data exfiltration. Look at indirect dependencies for anything unexpected, including development or test packages leaking into production.
Two steps people skip
First, necessity. The guide's first step asks whether existing components can cover the need, because each new dependency and its transitive dependencies adds attack surface. Second, suitability. The guide says to avoid choosing software just because large companies use it or because it is trendy.
What the guide cannot tell you
It is a checklist for human judgment. It does not give a pass mark, and it was written for evaluating libraries, though the same questions apply to any open source tool you plan to run in your pipeline. Pair it with the signals described in the OpenSSF badge, Scorecard and Baseline compared.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a dependency's known vulnerabilities and status are shown, since the guide asks you to confirm the current version has no important known issues.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning and policies and gates, which help enforce rules like these on the dependencies you allow. A free scan is available at gold.safeguard.sh/scan.
Quick check
How recent should commits and releases be?
The guide looks for significant commits and a release within the past 12 months.
Is popularity enough?
No. The guide says not to choose software just because large companies use it or because it is trendy.
Sources
Last reviewed: 19 October 2026.
