概述
依赖事故大多来自很小的改动：一次版本升级、一个新加入的开发工具，或被间接引入的传递依赖。对整棵依赖树做全量审查既慢又吵，而审查本次 diff 既快又能直接行动。GitHub 依赖审查会比较 base 与 head 的依赖图，把新增的漏洞包与许可证变化直接评论在 Pull Request 中，作者无需跳转页面就能看到问题。
步骤
- 配置依赖审查动作与严重级别、许可证策略：
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: actions/dependency-review-action@v4
with:
fail-on-severity: high
deny-licenses: GPL-3.0, AGPL-3.0- 在临时分支上安装一个已知存在漏洞的版本，验证门禁会失败：
npm install [email protected]
git commit -am 'test dependency gate'
git push- 验证只改锁文件的更新也会被审查：
npm update --package-lock-only
git commit -am 'refresh lockfile'
git push- 在分支保护中把该检查设为必需，确保合并必须等待它通过。
验证
预期 Pull Request 检查失败，并评论出问题包、advisory 编号与修复版本；只更新锁文件时同样会产生差异报告，若引入新的漏洞版本也会失败。分支保护生效后，合并按钮应保持禁用直到检查通过。若检查完全没有出现在 PR 上，先确认仓库已启用依赖图，以及工作流拥有 pull-requests: write 权限。
注意事项
- 只审查本次 PR 引入的变化，历史遗留的漏洞依赖仍需要单独的升级计划。
- 覆盖范围取决于 GitHub 的 advisory 数据库，可能落后于上游披露。
- 需要接受的风险应记录为带到期时间的例外，而不是把门禁改为 warn-only。
- 不支持的清单格式不会产生差异，这类生态需要额外的扫描任务。
- Fork 与 Dependabot 触发的运行权限受限，需要单独确认行为。