CVE 修复优先级：按 CVSS 分排序 vs 按「实际暴露面 × 可利用性」排序，你们团队到底听谁的？

【背景】

做了 3 年安全加固，最近半年最大的体感是：CVSS 分已经成了「责任转移工具」。

• 安全团队把 CVE 按 9.x / 8.x / 7.x 排好优先级推给业务，业务说「我们这条链路根本没人调用，为什么 7 天必须修」；
• 业务反过来把 CVSS 5.3 的库直接当 P0 修，结果花了一周改核心依赖，上线后线上 P99 抖了 2 小时才被回滚；
• 审计来问「为什么 CVSS 7.5 的 log4j 同类问题拖了 20 天」，安全说「因为那个 API 我们只在内网调用，没有公网暴露面」，但审计表上这一栏只认 CVSS 分。

一句话：CVSS 分是「上游视角的严重度」，不是「我们这台机器上的严重度」，但流程里大家越来越倾向于只认前者。

【常见分歧 / 几种做法】

我见过团队里大致分三派：

1. 纯 CVSS 派：分高先修，7.x 以上 7 天、8.x 以上 3 天、9.x 以上 24 小时，流程简单、审计友好，代价是「修了不该修的、拖了该修的」。
2. 暴露面派：先问「这个包是不是在公网可达路径上？是不是被实际调用？有没有可利用 PoC / 已披露利用链？」，再决定 SLA。代价是需要 SBOM + 调用链数据支撑，小团队基本做不全。
3. 混合派（我所在团队）：CVSS 决定「要不要进修复队列」，暴露面 + 可利用性决定「SLA 多紧」。具体是：
   • 公网可达 + 有 PoC → 24h
   • 公网可达 + 无 PoC → 7d
   • 内网 + 有 PoC → 3d
   • 内网 + 无 PoC + 核心链路 → 14d
   • 内网 + 无 PoC + 非核心链路 → 进季度 backlog 代价是需要维护一份「核心链路 / 公网可达清单」，维护成本不低。

【我的倾向与理由】

我倾向第 3 派，但承认它的真正难点不在规则本身，而在数据：

• SBOM 不全（动态加载、反射、SPI 的依赖根本扫不出来）；
• 「公网可达」这个判断在 K8s 里很模糊——Service、Ingress、NodePort、跨集群 mesh，到底算不算？
• 可利用性判断需要人，而安全团队的人永远是瓶颈。

所以我的真实主张是：CVSS 分应该作为「下限 SLA」（不能比这更松），暴露面 × 可利用性只允许「收紧」、不允许「放宽」——这样审计好交代，业务也不会被无差别 P0 压垮，同时避免「我判断你不需要修」这种主观空间被滥用。

【想听大家怎么选】

想听三种场景下的真实做法：

1. 小团队（< 10 人）、没有专职安全：你们怎么把 CVE 优先级从「CVSS 一刀切」里拉出来？有没有一个最小可用的暴露面清单？
2. 中大型团队、有 SBOM 但没调用链：「公网可达」你们到底怎么定义的？Ingress 后面、Service 后面、跨集群 mesh 里，分别算不算？
3. 审计 / 合规压力大的公司：你们怎么把「暴露面 × 可利用性」这套判断写成审计能接受的文档？有没有现成的模板或字段结构可以贴出来？

另外顺带一问：你们有没有遇到过「CVSS 分被当作政治工具」的场景——比如安全拿 CVSS 推责、业务拿 CVSS 反向压 SLA？怎么破的？

欢迎把你们团队的真实规则贴出来，哪怕只有三条，也比我这里的「教科书式」清单有用。