Before adding a dependency, spend five minutes on five things: known vulnerabilities, maintenance health, license, source repository and what it pulls in. A Gold package page and the free scan cover most of it. If anything is unclear, pick a different package or write the code yourself.
Minute 1: find the exact package
Typosquats exist. Search the directory for the name and confirm the ecosystem and spelling. Compare the repository link with the project you expect.
Minute 2: vulnerabilities and Gold checklist
Open the package page. Check the vulnerability count and the Gold checklist: no high or critical vulnerabilities, license, provenance and malware screening. Read each sentence under the item, not just the mark.
Minute 3: health
The health grade comes from OpenSSF Scorecard where one is published. Scorecard is built from heuristics and its own documentation says it can produce false positives and negatives, and that an aggregate does not show which practices are followed. Look at the weak checks. A zero on fuzzing matters less than a low maintenance score for a small library.
Minute 4: license and repository
Confirm the license in the repository. The Gold page may show it blank. Check that the repository is active, has recent commits and more than one maintainer if the package matters.
Minute 5: what it brings along
Look at the direct dependencies listed. A tiny helper that pulls in twenty packages is a cost. Then run your manifest with the new entry through gold.safeguard.sh/scan to see whether anything in the set has known vulnerabilities.
Questions worth asking yourself
- Could I do this in a dozen lines instead?
- Does the license fit how we ship?
- Who maintains this, and what happens if they stop?
- Do we pin the version?
When to stop and escalate
New package from an unknown publisher, install scripts that run code, no source repository, or recent ownership change. Raise these with your security team rather than deciding alone.
Make it a habit
Teams that do this well put it in the pull request template. Safeguard policies and gates can enforce parts of it automatically on pull requests, such as blocking a package with a high severity known issue.
Quick check
Is a popular package always safe?
No. Popularity helps, but popular packages are also worth attacking. Check the page and pin your version.
Do I need to do this for dev dependencies?
Yes, though with less urgency. Build tools run on developer machines and in CI.
Sources
Last reviewed: 19 October 2026.
