To vet a new open source package in ten minutes, confirm the exact name, check who maintains it and how recently, read what runs at install time, check the license, scan for known vulnerabilities, and look at the project's security practices. If any step looks off, choose another package or write the function yourself.
Why ten minutes is the right budget
Every new dependency adds code you did not write and often more packages below it. A fast, consistent check catches the common problems: look alike names, abandoned projects, surprising install behaviour. Deep audits are for packages that touch secrets or sit in critical paths.
In a first enterprise deal, this routine is also evidence. A reviewer who asks "how do new dependencies get in" is glad to hear there is a short, repeatable check.
The checklist
- Name. Compare the spelling with the project's own documentation or repository link. Look alike names are a known trick, and the cheapest defence is copying the name from the official docs.
- Source. Does the registry page link to a real repository, and does that repository match the package contents?
- Maintenance. When was the last release and commit? How many maintainers? A single maintainer is not a failure, but note it.
- Install behaviour. Does the package run scripts at install time? Read them, or disable install scripts in your package manager where practical.
- Dependencies. How many packages does it bring? A tiny helper that pulls fifty others deserves a second look.
- License. Does it fit your policy? Note copyleft terms early.
- Vulnerabilities. Run your scanner and check advisories for the version you will pin.
- Practices. The OpenSSF Scorecard project runs automated checks on open source repositories and can be run on someone else's project from the command line, giving a quick read of risky practices.
Scoring it
| Result | Action |
|---|---|
| All clear | Add it, pin the version, note it in the change |
| One yellow flag | Add it with a comment explaining why, and a review date |
| Install script you cannot explain | Do not add it |
| Abandoned or unknown maintainer for a security sensitive role | Pick an alternative |
A Scorecard result is a signal, not a verdict. Plenty of excellent small projects score modestly, and a high score does not prove the code is safe.
Make it part of the pull request
Add a short template to any pull request that changes a manifest: package name, reason, alternatives considered, check results. Ask the reviewer to confirm the lockfile diff matches what was intended. Automatic checks that block new dependencies with critical advisories or disallowed licenses save reviewer effort.
Keep a record
Store the checklist result with the pull request. Later, when an auditor asks how a package got in, you can replay it. Our auditor walkthrough script shows how to present this.
What the check cannot do
It cannot detect a maintainer who turns malicious next year. That is why scanning must continue after adoption, and why you should be able to find every use of a package quickly. Continuous monitoring and an accurate inventory handle the long run.
Safeguard scans dependencies and can gate pull requests on policy, covering the vulnerability and license steps automatically. Try the free scan.
Quick check
Is a popular package always safe?
No. Popularity makes a package a bigger target. Still run the same checks.
Should every dependency get this check?
Yes for direct ones. For transitive ones, rely on scanning and consider the check when a transitive tree grows suddenly.
Sources
Last reviewed: 19 October 2026.
