漏洞被修好了，但"谁来背锅"没被修好：跨团队漏洞的归属之争

先说背景：做了 15 年安全，我越来越觉得，漏洞本身其实好修，真正难修的是漏洞背后的"归属问题"。

打个比方：一栋楼着火了，消防队（安全团队）把火灭了，可第二天大家吵的不是"为什么着火"，而是"这层楼的物业到底算谁的"。我见过太多团队，漏洞单在工单系统里来回踢皮球三个月，最后不是被修掉，而是被"升级成已知风险"草草关单——火是灭了，但烟还在。

我观察到的几种典型场景，大家看看自己团队更像哪种：

1. 第三方组件漏洞：Spring/Log4j 这类 CVE 一出，使用方团队说"这是上游的事"，上游团队说"我只是库，怎么知道你怎么用的"，安全团队说"谁调用谁负责"。三方互相指，漏洞挂在"待评估"状态两周起步。
2. 依赖方服务漏洞：A 服务调 B 服务，B 有越权问题，但暴露面在 A 的网关上。A 说"我加了鉴权"，B 说"我信任内网"，安全说"纵深防御两边都要补"——两边都补一半，等于都没补。
3. 历史遗留代码：漏洞在三年前写的老服务里，原作者已离职，接手的人不敢动，动就要重构，重构就要排期，排期又要等版本窗口。
4. 多租户 SaaS：漏洞影响"某些配置组合下的租户"，但没人说得清哪些租户命中，影响面评估成了无底洞。

我的倾向：归属不该按"代码是谁写的"算，而该按**"谁能以最小成本闭环修复"算——谁离数据最近、谁改完影响面最小、谁有回滚能力，谁就该主修。安全团队的角色不是背锅，而是裁判 + 计时器**：判定主修方、定 SLA、超期就升级到双方共同上级。这套逻辑的关键不是"罚谁"，而是让漏洞单上永远有一个唯一的责任人字段，禁止"协作处理"这种看起来人人有责、实际人人无责的写法。

但我也承认这套有盲区：跨 BU 的漏洞，"共同上级"这个抓手可能就失效了。

想听大家聊：

• 你们团队的漏洞归属，实际是按"代码 owner"、"服务 owner"、还是"业务 owner"划的？
• 有没有过"漏洞修好了但归属吵了三个月"的经历？最后怎么收的场？
• 安全团队在你们组织里，是"裁判"还是"另一个干活的人"？这个定位是怎么来的？
• 第三方组件漏洞，你们有没有过"使用方和上游都改了、但谁也没测全"的翻车案例？

欢迎贴具体场景（脱敏即可），越具体越好聊。