A reviewer should confirm why each new dependency is needed, who maintains it, its scope, its license, any known advisories, how many transitive packages it brings, and that the lockfile matches the manifest. Seven questions, most answered in a few minutes from the dependency diff.
Where the data comes from
GitHub's dependency review shows added, removed and updated dependencies on a pull request, with release dates, usage counts, and for lock files the indirect dependencies too. It also reports known vulnerabilities in added or updated packages. The dependency review action can fail a check on severity, license lists or denied packages. Use those results as the starting point, then add human judgement.
The checklist
- Purpose. Does the description say why this package is needed? Could the standard library or an existing dependency do it?
- Maintainer and activity. Who publishes it, when was the last release, is anyone responding to issues? Abandoned packages become tomorrow's problem.
- Scope. Is it a runtime or development dependency? A tool added to the runtime list ships to production.
- License. Is it on the approved list? A copyleft license can bring obligations for how you distribute.
- Known advisories. Does the check show vulnerabilities? If so, is there a fixed version, and is the vulnerable code reachable?
- Size of the change. How many transitive packages come with it? A small library that pulls in dozens deserves a second look.
- Lockfile integrity. Does the lockfile diff match the manifest change, and are the integrity values present?
A table for quick decisions
| Finding | Reviewer action |
|---|---|
| No stated purpose | Ask before approving |
| Unknown or new publisher | Check registry history, ask the author |
| Runtime scope for a dev tool | Request a move to development scope |
| License off list | Block until legal or the policy owner agrees |
| Serious advisory with a fix | Request the fixed version |
| Large transitive tree | Ask whether a lighter option exists |
| Lockfile unchanged but manifest changed | Request regeneration |
Keep the review proportionate
Version bumps of existing packages by a bot, with passing checks and a clean diff, need a light touch. New direct dependencies need the full list. Do not apply the full checklist to everything, or reviewers will stop doing it.
Write it into the template
Put the seven questions in the pull request template as checkboxes that apply only when the diff touches dependency files. Link to your approved license list and your exception process. People follow what is in front of them.
Know what review cannot do
A reviewer cannot read the whole source of every dependency. The checklist reduces risk, it does not remove it. Pair it with automated scanning and runtime controls.
Safeguard offers dependency scanning with gates and policies that can run on pull requests, and reachability analysis to rank findings. See your own project on the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice which pull request checks run before a human sees the change.
Quick check
Do bot generated update pull requests need the full checklist?
Usually not. Review them lightly when checks pass, and apply the full list to new direct dependencies.
Where should the checklist live?
In the pull request template, shown when dependency files change.
Sources
Last reviewed: 19 October 2026.
