Treat the scanner as a dependency and assess it the same way you would any critical library. Run OpenSSF Scorecard against its repository, read the Maintained, Security Policy and Signed Releases results, and add manual checks for release cadence, issue response and who funds the work.
Why check the scanner itself
A scanner runs in your pipeline, often with read access to source and tokens. It also decides what your team believes is safe. If the project stalls, your coverage quietly decays. Many teams evaluate features and skip this step.
What Scorecard tells you
OpenSSF Scorecard runs automated checks on public projects. It has 18 checks across holistic security, source risk and build risk. A few matter most here.
- Maintained. Per the Scorecard documentation, a full score needs at least one commit per week over the previous 90 days. Archived projects score lowest. The documentation notes that a low score may simply reflect a mature, stable project, so you must judge it.
- Security Policy. Looks for a SECURITY.md file with a reporting address and some disclosure detail.
- Signed Releases. Looks for signature files on recent releases and gives a higher score for provenance files. It checks for the presence of signatures, not their validity.
- Dangerous Workflow, Token Permissions, Branch Protection and Code Review. Signs of how carefully the project guards its own build.
The five step check
- Run Scorecard against the scanner's public repository using the command line tool, with a GitHub token that has the public_repo scope.
- Record the aggregate and the five checks above. Do not chase a number. Look for red flags such as a Critical risk result.
- Read the last ten releases. Is there a steady cadence? Do release notes mention data or engine fixes?
- Open the issue tracker. Pick five recent bug reports and see how long until a maintainer replied.
- Find out who pays for the maintenance. A company, a foundation or a handful of volunteers each imply a different continuity risk.
Turn it into a decision
| Finding | Interpretation | Action |
|---|---|---|
| Active, signed releases, named sponsor | Lower continuity risk | Adopt, review yearly |
| Active but one maintainer | Bus factor risk | Adopt with an exit plan |
| Quiet for months, no policy file | Stalled or finished | Ask whether you need an owner who can fork, or choose another route |
| Archived | Unmaintained | Plan a replacement |
Repeat it
Put the check on the calendar for each year or after any major change in the project. Pair it with a note of who on your team would patch the scanner if upstream stopped.
Safeguard is a managed option if you would rather not own this risk, and a free scan at gold.safeguard.sh/scan shows how it reports on your code.
Quick check
Does a low Maintained score mean the project is dead?
Not necessarily. The documentation says the check reports activity and you should judge whether the software needs ongoing maintenance. For a scanner with a moving database, activity usually matters.
Does Signed Releases prove a release is safe?
No. The check looks for signature files and does not verify them. You still need to verify the signature yourself.
Sources
Last reviewed: 19 October 2026.
