Run OpenSSF Scorecard against the library's repository and read the individual checks: Maintained, Code-Review, Vulnerabilities, Binary-Artifacts, Security-Policy, Signed-Releases, Pinned-Dependencies and Dangerous-Workflow. Treat the results as triage for a deeper look, not a verdict, and pair them with your own review of what the library loads and runs.
What Scorecard is
OpenSSF Scorecard is a project of the Open Source Security Foundation. Its site describes it as a way to quickly assess open source projects for risky practices. You can run it as a GitHub Action on code you own, or from the command line on someone else's project.
Each check looks at one practice and carries a risk level in the project's documentation. Machine learning libraries are a good use case, because they are often young, fast moving and loaded with native code.
Eight checks worth reading first
| Check | What the docs say it looks at | Why it matters for an ML library |
|---|---|---|
| Maintained | Whether the project is active, with at least one commit a week over 90 days scoring highest | Unpatched libraries stay unpatched |
| Code-Review | Whether human review is required before merge | Catches unintended bugs and injected code |
| Vulnerabilities | Open, unfixed vulnerabilities in the project or dependencies, using OSV | Known problems you would inherit |
| Binary-Artifacts | Generated executables in the source repository | Non-reviewable code |
| Security-Policy | A SECURITY.md file | Tells you how to report a problem |
| Signed-Releases | Cryptographic signing of release artifacts | Provenance of what you install |
| Pinned-Dependencies | Hash pinned dependencies in build and release files | Resistance to a swapped dependency |
| Dangerous-Workflow | Risky patterns in GitHub Actions workflows | A compromise route into the project |
The documentation lists Dangerous-Workflow as critical risk, and Code-Review, Vulnerabilities and Signed-Releases as high. It also notes that some checks, such as Signed-Releases and Pinned-Dependencies, are currently limited to repositories hosted on GitHub.
How to use the results
- Find the library's source repository from its package page, and check that the link is real.
- Run Scorecard and save the output with the date.
- Look at low scores on high-risk checks first. A low Maintained score is not always bad. The docs themselves say a small utility may not need constant updates.
- Compare two candidate libraries for the same job, if you have them, by the checks that matter for your use.
- Decide: adopt, adopt with extra review, or choose another.
What the scores cannot say
Scorecard looks at repository practices. It does not read the library's code, and it does not tell you what the library does at install or import time. For ML libraries, add questions of your own.
- Does it load model files, and in which formats? Does it run code from them?
- Does it download anything at import or at first use?
- Does it ask you to enable a trust option for remote code?
- Does its dependency tree include packages with known advisories?
- Who maintains it, and what happens if they stop?
Also note that the docs say the Maintained check only succeeds for a GitHub project older than 90 days. A brand new library gets no assessment, so inspect it by hand.
Record the decision
Write down what you checked, the date, the scores and who approved the library. Pin the version with hashes, and set a reminder to re-run the check at each major upgrade. A separate post on this blog covers pinning an ML stack with hashes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the dependency inventory view and pick the package you would investigate first.
Quick check
Is a high Scorecard score a reason to skip review?
No. It reflects repository practices, not the behavior of the code. Still review what the library loads and runs.
What if the library is not on GitHub?
Some checks are limited to GitHub hosted repositories, so you will have fewer signals. Do more manual review.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and reachability analysis, which helps show whether a vulnerable function in a library is actually called by your code. A free scan is available.
Sources
- OpenSSF Scorecard, read 19 October 2026.
- Scorecard checks documentation, read 19 October 2026.
Last reviewed: 19 October 2026.
