Before adding a dependency, check whether you need it, whether its license fits, whether it is maintained, whether it has unresolved vulnerabilities, and where it comes from. Record the decision in the pull request so the answer can be shown to a customer later.
Why vet at the door
Cleaning up a dependency after it spreads through a codebase is expensive. Reviewing it before first use is cheap. NIST SP 800-218 task PW.4.1 lists reviewing and evaluating third-party components in the context of their expected use, and repeating the review if the use changes substantially.
The six checks
- Need. Can the standard library or an existing dependency do this? Fewer packages mean fewer questions.
- License. Is the family on your allowed list, or does it need review?
- Health. Recent releases, responsive maintainers, more than one contributor. Automated checks such as OpenSSF Scorecard can supply a first pass.
- Known issues. Search OSV, the open vulnerability database that maps advisories to open source package versions, for the package and the version you intend to use.
- Provenance. Does the registry offer build provenance? npm describes provenance as a verifiable link to a package's source and build instructions, but states plainly that it does not guarantee the absence of malicious code.
- Footprint. How many transitive dependencies does it pull in?
A short review record
| Field | Example entry |
|---|---|
| Package and version | name, version |
| Reason | What it replaces or adds |
| License | Identifier and decision |
| Health notes | Release dates, maintainers |
| Advisories | None open, or list |
| Approver | Role and date |
Put it in the pull request description. Reviewers already read it, and the history is searchable.
Make it proportionate
A date formatting helper and a cryptography library should not get the same review. Define two or three tiers. Anything that handles authentication, parsing of untrusted input or secrets gets the deepest look.
Reply template
New dependencies go through a documented review covering need, license, maintenance health, known vulnerabilities and source. The review is recorded in the change request, and automated checks run on each pull request to catch unreviewed additions.
Common shortcuts to avoid
Teams usually skip vetting when a deadline is near, when the package looks popular or when a coding assistant suggested it. Popularity is a weak signal because widely used packages have been compromised before and lookalike names exploit trust. Treat urgency as a reason to use the lightweight tier of the review, not to skip it.
Another shortcut is vetting once and never again. Re-run the check when a package changes maintainers, changes license or is used in a more sensitive role.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a gate blocks a change that adds a risky package. That is the check that makes "reviewed before use" a statement you can prove.
Safeguard policies and gates can flag new dependencies on pull requests.
Quick check
Does a high Scorecard result mean a package is safe?
No. It summarizes practices of the project. It is one input, not a verdict.
Who should approve a new dependency?
A named role, often a tech lead for ordinary packages and a security reviewer for sensitive ones.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- OpenSSF Scorecard
- OSV, Open Source Vulnerabilities
- npm Docs, Generating provenance statements
Last reviewed: 19 October 2026.
