A good library checklist covers four areas: license terms you can accept, security signals such as a disclosure policy and advisory history, maintenance health, and an exit plan. Rate each item pass, ask or stop, and adopt only when nothing is a stop and every ask has an answer.
Why a checklist beats gut feeling
Teams usually pick libraries by search ranking, familiarity or a blog post. That works until the library goes quiet, changes its license or ships a vulnerable release. A checklist takes ten minutes and turns an opinion into a record you can revisit.
The checklist
| Area | Check | Where to look |
|---|---|---|
| License | A license is published and its terms fit your use | LICENSE file, package metadata |
| License | Identifier is a recognised SPDX one, or the text is reviewed | SPDX License List |
| Security | A security policy says how to report a flaw | SECURITY.md in the repository |
| Security | Past advisories were fixed and released, not left open | OSV, repository advisories |
| Security | Releases are signed or carry build provenance, where the ecosystem supports it | Registry page, release assets |
| Maintenance | The repository is not archived | Repository banner |
| Maintenance | Recent releases, or a stable and finished scope | Release list, changelog |
| Maintenance | More than one person can publish | Contributor and owner lists |
| Footprint | You know what it pulls in transitively | Dependency graph viewer |
| Exit | You could replace it within a sprint or two | Your own code structure |
How to run it
- Open the repository and registry page side by side.
- Fill the table. Write the evidence next to each row, not just a tick.
- Mark any row where you cannot tell as "ask" and send one question to the maintainers or your legal contact.
- Mark a stop for an archived repository when you need ongoing fixes, for a missing license, or for terms your counsel rejects.
- Save the filled table with the pull request that adds the dependency.
Reading the signals honestly
Some signals are tools, not verdicts. The OpenSSF Scorecard project says a low maintenance result is a prompt to investigate, since small utilities may be finished rather than neglected. Its Security-Policy check looks for a SECURITY.md that explains how to report a vulnerability privately, and its License check notes that a missing license impedes security review and creates legal risk for users.
Provenance helps with where a package came from, but npm's own documentation states that provenance does not guarantee a package has no malicious code. It is one row, not the whole answer.
Related reading: measuring project health and the single maintainer risk framework.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive components are listed, which is the footprint row of the checklist.
After adoption
The checklist is a snapshot. Safeguard's SBOM and dependency scanning, plus policies and gates, can keep the decision honest by flagging new advisories and enforcing rules in pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
How long should a library evaluation take?
Ten to thirty minutes for a small utility, a few hours for a core framework. Scale effort to how hard the library would be to remove.
Who should own the checklist?
The engineer adding the dependency fills it in, and a reviewer signs off. Security or legal join only for asks and stops.
Sources
Last reviewed: 19 October 2026.
