To make a pull request prove a new dependency was vetted, add a short checklist to the pull request template, require a link to the adoption record, and run an automated dependency review check that must pass before merge. The reviewer then confirms evidence rather than relying on memory.
The problem this solves
Dependencies arrive in pull requests that are really about something else. A reviewer sees a feature, a one-line manifest change and a long lockfile diff. Nobody asked who maintains the new package. A template and a check turn that blind spot into a visible step.
Part 1: the template
Add a section that triggers when the manifest or lockfile changes:
- Package name, version and ecosystem.
- Why this package, and what alternatives were considered.
- Link to the adoption record.
- Registry owners and repository match checked: yes or no.
- Install scripts present: yes or no.
- Provenance present: yes or no.
- Conditions attached, such as pin and monitor.
Part 2: the automated check
GitHub's dependency review shows, on the Files changed tab for pull requests that modify manifests or lock files, which dependencies were added, removed or updated, with release dates, how many projects use each, vulnerability data, and changes to indirect dependencies in lock files.
The dependency review action enforces it in a workflow. By default the check fails if it finds vulnerable packages, and if the branch requires that check, the pull request cannot merge. You can set the severity that causes failure and define license allow or deny lists. It is available for all public repositories, and for private ones with GitHub Code Security or Advanced Security. Organization owners can require it across repositories using rulesets.
For what it catches and misses, see dependency review on pull requests.
Part 3: what automation cannot decide
| Question | Who answers |
|---|---|
| Does it contain a known vulnerability? | Automated check |
| Is the license allowed? | Automated check with a policy list |
| Who runs it and can they be trusted? | Reviewer, using the record |
| Does it add install scripts? | Reviewer or custom check |
| Is the package a lookalike? | Reviewer |
Part 4: make the gate enforceable
- Mark the dependency check as required on protected branches.
- Use CODEOWNERS or a similar mechanism so a security-aware reviewer must approve changes to manifests.
- Agree on a short exception path: a documented reason and an expiry date.
- Review exceptions monthly.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what happens when a pull request fails the gate, and what the author sees. A clear message is what makes a gate tolerable.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Will this slow developers down?
Slightly for new packages, which are rare. Version bumps of approved packages should pass automatically.
Does the template need to cover transitive dependencies?
No. Let automated checks cover them, and reserve the checklist for direct additions.
Sources
Last reviewed: 19 October 2026.
