依赖审查查什么
依赖治理包含两类检查：许可合规与已知漏洞。许可方面生成依赖清单，识别传染性许可与商业限制；漏洞方面使用各生态的扫描工具，把结果纳入 CI 并设定处置时限，而不是等到发版前才看上一眼。直接依赖和传递依赖都在治理范围内。
基本信息
| 许可检查 | pip-licenses、license-checker 之类工具生成清单 |
|---|---|
| 漏洞检查 | npm audit、pip-audit、govulncheck |
| 策略 | 按严重级别阻断，并设定修复时限 |
| 覆盖范围 | 直接依赖与传递依赖都要纳入 |
典型使用场景
- 引入新依赖：先看许可与维护活跃度，再决定是否采用
- 例行巡检：按周或按发版节奏扫描已知漏洞
- 合规审计：输出许可证清单交给法务确认
- 紧急披露：高危漏洞公布后快速定位受影响范围
- 升级评估：判断升级是否带来破坏性变更
发现漏洞后的处置顺序
- 确认受影响版本范围与实际调用情况
- 有补丁的优先升级，并跑一遍回归测试
- 没有补丁的评估可利用性，必要时加缓解措施
- 把决策与理由记录下来，避免反复讨论
常见命令
常见命令
npm audit --audit-level=high
pip-audit
pip-licenses --format=markdown
govulncheck ./...两类检查对照
| 维度 | 许可检查 | 漏洞检查 |
|---|---|---|
| 目标 | 合法合规地使用第三方代码 | 已知缺陷与安全问题 |
| 输出 | 许可证清单与风险标记 | 漏洞编号、级别与受影响版本 |
| 频次 | 引入依赖时与发版前 | 例行巡检与披露事件之后 |
| 责任 | 法务与工程共同确认 | 工程修复，必要时加缓解 |
扫描结果按可利用性分级处理：没有补丁的传递依赖要评估是否可接受，并把决策记录下来。
在评审中的用法：新增依赖的改动里附上许可与漏洞扫描结果，评审者就不必逐个手工去查。
把扫描接进流水线时要区分直接依赖与传递依赖：前者可以直接升级，后者往往要等上游发版。
只在发版前扫一次：新披露的漏洞在下个版本之前一直没有感知。