15. CI 的质量门禁 2：依赖安全（SCA）与许可证合规
依赖决定了风险面：漏洞、供应链、许可证。
本章目标
把依赖风险变成可治理系统：漏洞（CVE）与许可证合规都要进入 CI 门禁与运营闭环。
你会掌握
SCA 的定位与数据链路、漏洞修复优先级与 SLA、许可证策略（allow/deny/review）与可审计豁免。
真实收益
减少供应链事故与“上线后才发现违规依赖”的返工；让安全治理不靠临时抽查，而靠默认系统。
现代软件最大的“外包”不是外包团队，而是外包给依赖。
你写 10% 的代码，却运行 90% 的第三方代码。这意味着：你的风险面很大一部分来自依赖。
本章把依赖治理拆成两条主线：漏洞（SCA）与许可证合规，并告诉你如何在不扰民的前提下做到“默认安全”。
你写 10% 的代码，却运行 90% 的第三方代码。这意味着：你的风险面很大一部分来自依赖。
本章把依赖治理拆成两条主线：漏洞（SCA）与许可证合规，并告诉你如何在不扰民的前提下做到“默认安全”。
1) SCA 是什么？它和 SAST 有什么不同？
- SAST：看你写的代码逻辑是否存在安全缺陷（注入、XSS 等）。
- SCA：看你引入的依赖是否有已知漏洞、是否存在供应链风险、许可证是否合规。
一句话：SAST 关注“你写的”，SCA 关注“你用的”。
图 1：SCA 数据流（动态）
从 lockfile/SBOM 到漏洞库，再到门禁决策与修复工单：SCA 是一条数据链，不是一次扫描。
2) 漏洞治理：严重性不等于优先级
很多团队在 SCA 上踩的坑是：把“高危”当成“立刻阻断一切”。结果是噪声爆炸，团队开始绕过门禁。
专业做法是把优先级拆成三个维度：
- 严重性（Severity）：CVSS/评级
- 可达性（Reachability）：漏洞路径是否可被你的代码触发（是否真用到）
- 暴露面（Exposure）：是否公网可达？是否处理敏感数据？
现实策略：
高危 + 可达 + 暴露面大 → 阻断/紧急修；
高危但不可达 → 记录/观察/批量修复；
中低危 → 设 SLA（例如 30/60/90 天），定期收敛。
高危 + 可达 + 暴露面大 → 阻断/紧急修；
高危但不可达 → 记录/观察/批量修复；
中低危 → 设 SLA（例如 30/60/90 天），定期收敛。
图 2：漏洞 → 修复闭环（动态）
扫描只是开始，治理才是关键：分级、分派、修复、验证、回归与审计，才能让风险持续下降。
3) 许可证合规：不是法律恐吓，是工程规则
许可证问题常见“翻车点”：
- 引入了限制性许可证（例如某些 copyleft）但不自知
- 依赖的依赖带来许可证传染风险
- 发布时未满足许可证要求（声明、归档、源码提供等）
一个可落地的合规策略通常是三段式：
- Allow 默认允许：MIT/Apache-2.0/BSD 等（仍需保留声明）
- Review 需审核：LGPL/MPL 等（视使用方式与链接方式）
- Deny 默认禁止：在你组织策略中明确不允许的许可证
图 3：许可证门禁决策（动态）
合规不靠“临时查表”，靠“策略 + 门禁 + 审计”：允许/审核/禁止三段式能把复杂问题工程化。
4) 豁免与审计：允许例外，但必须可追溯
现实里总会遇到“暂时没法修”的漏洞或许可证争议依赖。成熟策略是：
- 允许豁免，但必须写清楚：原因、范围、到期时间、责任人。
- 把豁免当债务：定期盘点与清理，不允许永久豁免。
- 用门禁强制执行：过期豁免自动阻断。
本章小结：依赖治理是一门“运营学”
- SCA 要做成系统：数据链 + 分级决策 + 修复闭环。
- 严重性 ≠ 优先级：可达性与暴露面决定真实风险。
- 许可证合规要工程化：策略（allow/review/deny）+ 门禁 + 审计。
- 豁免必须可追溯且有期限：否则债务会滚雪球。