Before you open a pull request that changes dependencies, run seven checks: review the lockfile diff, confirm each new package is intended, scan for known vulnerabilities, check for known exploitation, look at install scripts, check licenses, and run the same gate your pipeline will. It takes about ten minutes.
The checklist
- Lockfile diff is small and intended. For npm, the lockfile records the exact tree, so changes show up as readable diffs. If the diff touches hundreds of unrelated lines, regenerate carefully or split the change.
- Every new package has a reason. Write one line per package in the pull request description: what it does and why not a smaller option.
- Scan the new tree. Run your scanner on the changed manifest and compare with main. Only new findings are your responsibility in this change, but note existing ones.
- Check known exploitation. CISA's Known Exploited Vulnerabilities catalog is the authoritative source for flaws exploited in the wild. A match changes the urgency of a finding.
- Look at install scripts. In the npm lockfile, a
hasInstallScriptflag shows that a package runs code at install. A new one needs a quick read. - Check licenses. A new dependency can bring a license your company cannot use. Catch it now, not at release.
- Run the gate locally. If your pipeline blocks on certain findings, run the same policy first so the pull request does not fail for a predictable reason.
Why local first
A pipeline failure costs minutes of waiting and a context switch. A local check costs seconds. More important, pull request reviewers read a clean change faster and trust it more.
It also keeps reviewers focused. If they must spend their time pointing out a vulnerable version your scanner would have caught, that is attention not spent on design.
What to write in the description
Keep it short and consistent:
- Dependencies added or updated, with versions.
- Scan result summary, with the date.
- Any finding you chose not to fix, with the reason and a review date.
Consistent descriptions make audits and incident reviews far easier, because the evidence is in the history.
When the checks disagree
Sometimes the local scan is clean and the pipeline finds something. Usually the cause is a different advisory snapshot or tool version. Check both versions and times, and decide which result is authoritative. The post on where scans should run covers that choice.
Automate what repeats
If you run the same seven checks on every dependency change, script them. Keep the human steps, items 2 and 5, as a prompt in your pull request template.
The demo below shows how a gate evaluates a pull request.
Where Safeguard fits
Safeguard provides policies and gates that can evaluate pull requests, plus a CLI and IDE extensions for local runs. The free scan at gold.safeguard.sh/scan can check a manifest with no login.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to fix every existing finding in my pull request?
No. Be responsible for what your change adds, and note the existing ones.
Which checks should be automated first?
The scan, the exploitation lookup and the gate run. Keep reasoning about new packages as a human step.
Sources
Last reviewed: 19 October 2026.
