No. A package health score such as OpenSSF Scorecard measures how a project is run, not whether the code is safe or whether it suits your use. It is a useful input for approving a dependency, but it should sit beside known vulnerabilities, maintenance activity, license, and how you plan to use the package.
What Scorecard measures
OpenSSF Scorecard runs automated checks and gives each a score out of 10 along with a risk level. Its documentation lists checks across areas such as vulnerabilities, maintenance, code review, branch protection, pinned dependencies, token permissions, signed releases, and whether the project has a security policy. It aggregates these into one overall score and offers remediation prompts.
Notice what this is: a view of the project's practices. It is evidence about process.
What it does not tell you
- Whether the specific version you use has a known vulnerability. The Vulnerabilities check uses OSV, but your SCA scan is the right place to ask about your version.
- Whether the code does anything you do not want.
- Whether the maintainers will respond to a report next month.
- Whether the package is the right choice for your problem.
- Anything about packages hosted outside the checked repositories, since scores apply to projects Scorecard can analyze.
A high score can sit on a project with a recent flaw, and a low score can sit on a small, careful library. Treat the number as a prompt for questions.
A simple approval rubric
| Signal | Where to get it | What to look for |
|---|---|---|
| Known vulnerabilities | SCA scan | None unpatched in the version you will use |
| Practice score | Scorecard | No critical risk checks failing without explanation |
| Maintenance | Release and issue history | Recent releases, responsive maintainers |
| License | Package metadata | Compatible with your policy |
| Fit | Your team | Needed, and no lighter alternative already in your tree |
| Transitive weight | Dependency tree | Not dragging in a large number of new packages |
Set a policy, not a threshold
Avoid a rule like "score above 7". Write a rule that names the checks that matter to you. For example: require a security policy, no checked-in binaries, and pinned dependencies, and send everything else to a human. Then record exceptions with reasons.
Run it at the right moment
Check when a package is first added, and again when you upgrade across a major version. Do not rely on a single check from years ago.
A worked example: two candidate libraries
You need a library to parse a configuration format. Two candidates look similar.
Candidate A has a high overall Scorecard score. It has a security policy, requires code review, pins its build dependencies, and signs releases. It had its last release fourteen months ago, and open issues show a reported parsing bug without a reply.
Candidate B has a lower score. It lacks a security policy file and does not sign releases. It has a recent release, active maintainers who reply within days, and a small, readable code base with no transitive dependencies.
The score alone would pick A. A fuller picture, including maintenance and fit, may favor B for your use. Neither answer is automatic, and that is the point: the score is an input, and the decision is a judgment you can write down.
Step by step: approve a dependency
- State the need in one sentence and check whether you already have a library that does the job.
- List two or three candidates.
- Run your SCA tool against each candidate's latest version and note any known vulnerabilities.
- Look up the Scorecard result and read which checks failed, not just the total.
- Check the release history, issue response, and number of active maintainers.
- Look at the transitive dependency list that each candidate would add.
- Check the license against your policy.
- Choose, and write down the reasons and any risks you accept.
- Pin the version and add the package to the monitored inventory.
Reading the individual checks
Some checks matter more for some uses. For a dependency that runs in your build, signed releases and pinned dependencies matter because a compromised build can change what you ship. For a dependency in a runtime service, the vulnerabilities and maintenance checks matter more. Scorecard's documentation assigns risk levels to each check, such as critical for dangerous workflows and high for branch protection, which helps you decide where to look first.
A check that cannot be evaluated may appear as inconclusive. Treat that as unknown, not as a pass.
Do not forget the supply path
A healthy project can still be attacked through its publishing account or registry. Scorecard looks at project practices. It does not confirm that the package you download matches the source you reviewed. Controls such as pinning exact versions, using lockfiles, and checking provenance where available address that part.
Make it a lightweight routine
For small teams, a ten minute checklist run when a dependency is added is enough. For larger teams, automate the lookups and send a summary to a reviewer on the pull request that introduces the package. Keep the decision record with the pull request, so the reasoning travels with the code.
When to re-evaluate
Re-check when a maintainer changes, when a project is archived or goes quiet, when your use changes, or when a new advisory lands. A dependency approved years ago deserves a fresh look if the project has gone quiet.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a component and look at its version and findings. This is the per-version evidence a health score cannot give you, so check both before you approve a package.
Quick check
Does a high Scorecard score mean a package is secure?
No. It reflects project practices. Scan the specific version for known vulnerabilities as well.
Should a low score block a dependency?
Not automatically. Look at which checks fail, and decide whether those matter for how you will use the package.
Should I require a minimum Scorecard score in policy?
Prefer naming the checks that matter to your use over one threshold. Route unclear cases to a person and record exceptions with reasons.
Sources
Last reviewed: 19 October 2026.
