Start with the SBOM's direct dependencies, score each for maintenance health and exposure, and replace the ones that are both unhealthy and close to untrusted input. OpenSSF Scorecard gives a repeatable health signal, such as whether a project is actively maintained.
Why not replace on advisories alone
Advisory counts tell you about past flaws. They say little about whether the next one will be fixed. A library with one advisory and a fast patch may be healthier than one with none and no maintainer. So combine two views: what you depend on (SBOM) and how well it is looked after (health signals).
What Scorecard is
OpenSSF Scorecard is an automated tool that assesses a number of heuristics, called checks, for open source projects. Its stated purpose is to help maintainers improve their security practices and to help consumers judge whether their dependencies are safe. One check, Maintained, looks at whether the project is active: an archived project gets the lowest score, and at least one commit per week over the previous 90 days gets the highest. The project documentation describes inactivity as a risk because a project that is not active might not be patched.
Treat a score as a prompt to look, not a verdict. A small, finished library can be quiet and fine.
A shortlisting method
- Export direct dependencies from the SBOM, with version and ecosystem.
- Look up each one's repository and run or read its Scorecard result.
- Add exposure: does it parse untrusted input, handle auth, or run in a privileged place?
- Add effort: how many call sites use it?
- Rank.
| Health | Exposure | Action |
|---|---|---|
| Poor | High | Plan replacement now |
| Poor | Low | Watch, set a review date |
| Good | High | Keep, stay current |
| Good | Low | Leave alone |
Before you swap
Check whether the standard library or an existing dependency already covers the need. Check that the replacement is itself healthy, and run it behind your tests. If replacement is too costly, options include pinning and monitoring, vendoring with a named owner, or contributing a fix upstream.
Record the decision in your SBOM notes or backlog so the next review does not repeat the research. For related reading, see abandoned open source project risks.
Keeping the shortlist honest
Revisit the ranking every quarter. Health changes, and so does exposure: a library that moved from an internal tool to a customer facing path jumped a row in the table above. Keep the reasons next to each decision, so a new team member can see why one package stayed and another went. When you do replace something, regenerate the SBOM and confirm the old package is gone from every service that used it.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a stored inventory is checked again as new information arrives.
Safeguard's SBOM and dependency scanning keep the inventory current, so the shortlist starts from fresh data. A free scan shows what a repository depends on.
Quick check
Is a low Scorecard score a reason to remove a library?
Not by itself. Look at exposure and alternatives, then decide.
Do I check transitive dependencies too?
Start with direct ones, then check the transitive ones that handle untrusted input.
Sources
Last reviewed: 19 October 2026.
