Look at recent commits and issue activity, whether the project has a security policy, whether releases are signed, and whether it uses a dependency update tool. No single signal proves a project is healthy, but several together give a fair picture. OpenSSF Scorecard automates many of these checks.
Why this matters to a user
Many apps are built on open source parts. If one of those parts is no longer looked after, a flaw found tomorrow may never get a fix. You might not choose the part yourself, but you can ask whether the apps you use rely on projects that are alive.
Five signals to look at
- Recent activity. Does the project still receive changes and answer issues?
- A security policy. Is there a SECURITY.md or similar file saying how to report problems?
- Signed releases. Do releases come with signature files?
- Reviewed changes. Are changes approved by someone other than the author?
- Update routine. Does the project use a tool to keep its own dependencies current?
How Scorecard measures them
OpenSSF Scorecard documents a set of automated checks. Several map directly to the signals above:
| Check | What it looks at |
|---|---|
| Maintained | Recent project activity. Archived projects get the lowest score. The top score needs at least one commit per week over the previous 90 days. The check only works for GitHub projects older than 90 days |
| Security-Policy | Whether a SECURITY.md file explains how to report vulnerabilities |
| Signed-Releases | Whether release assets include signature files. It does not verify the signatures |
| Code-Review | Whether recent changes were approved by someone other than the committer |
| Dependency-Update-Tool | Whether Dependabot or Renovate is enabled. It does not confirm their pull requests get merged |
| Vulnerabilities | Whether the OSV database lists open, unfixed vulnerabilities in the project or its dependencies |
Read the score with care
A weekly commit rule suits a busy project. A small, finished library may change rarely and still be fine. Low activity on a stable tool is a prompt to look closer, not an automatic fail.
The reverse also holds. Frequent commits do not mean careful work. The Vulnerabilities check is often the most telling single item, because open, unfixed flaws are the ones that can hurt you today.
A quick manual routine
- Open the project page and look at the date of the latest release and the latest commit.
- Scan the open issues for security reports with no reply.
- Look for a security policy file.
- Check whether releases are signed.
- Search for the project name plus the word advisory to see whether past flaws were fixed promptly.
- If you depend on it for something important, decide in advance what you would switch to.
Where Safeguard fits
Safeguard maintains an inventory of the open source components in your software through dependency scanning and SBOM generation. Policies and gates can block components that are archived, unmaintained or carry critical flaws, and reachability analysis shows which findings your code can actually trigger. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a few components and note which ones you would want to look at more closely.
Quick check
Is an old project always unsafe?
No. A small stable library can go years without changes. Check whether it has open unfixed flaws and whether anyone still answers reports.
Does a high Scorecard score mean the software is safe?
No. It measures project practices, not the absence of every flaw. Treat it as one input.
Sources
Last reviewed: 19 October 2026.
