【背景】
我做了 8 年分布式系统的安全加固，最头疼的不是"怎么修漏洞"，而是"修哪个、先修哪个"。
说个真实场景：安全团队每周一早上甩来一份扫描报告，20 个"高危"，红字加粗，附带一句"本周五前完成修复"。开发团队一个迭代 2 周，光日常需求就排满了。结果你猜怎么着——报告在飞，漏洞在堆，安全团队觉得开发不重视安全，开发觉得安全团队"不懂业务、拿着扫描器当裁判"，最后变成两边在群里扯皮，PM 拍板"先放一放"。
更离谱的一次：扫描器报了一个 Spring 依赖的高危反序列化漏洞。我拉了攻击路径分析，那个方法在整个调用链里只有内部定时任务会触发，没有外部输入能走到，而且入口前面还有 API 网关做鉴权 + 参数白名单。安全团队说"高危就是高危"，开发说"你倒是帮我确认一下攻击面啊"。最后我写了 3 页的可达性分析报告，安全团队说"行，那降级为中危，下季度修"。
【常见分歧——我见过四种"流派"】
-
安全绝对派："高危就是高危，48 小时，没有商量。扫描器标红的就是需要修的。" → 问题：把"理论最大影响"当成了"实际风险"。就像小区门口贴了个"禁止停车"的牌子，你非要说"万一有人把车停这儿砸到玻璃呢"——理论成立，但你得问一句：这个小区门口 500 米内有停车场，谁会把车停你门口？
-
开发实用派："扫描器 50% 是误报，另外 30% 在我这里根本触发不了，剩下 20% 里有一半有 workaround。" → 问题：用"够不着"来合理化"不修"。够不着是今天，网络拓扑变了、新加了一个代理、升级了一个中间件，可能就够着了。
-
管理折中派："定个 SLA 嘛——高危 7 天、中危 30 天、低危下季度。" → 问题：按等级一刀切，忽略了"同一个高危在不同服务上风险差 10 倍"的事实。
-
安全左移派："把 SAST/DAST 塞进 CI，红了不让过。" → 问题：理想很美好，但"扫描器红了但业务不能停"的矛盾只是被推迟了——而且推迟到发布窗口，压力反而更大。
【我的倾向：按「攻击可达性 × 业务影响」分诊，而不是按「漏洞等级」】
我打一个比方：急诊分诊不是按"看起来多红"排队的，是按"哪个会死人"排队的。一个手背擦伤（看起来很红）和一个内出血（外表看着没事），谁先治？
落到漏洞分诊上，我会分三步：
第一步：可达性分析（能不能走到？）
- 这个漏洞的触发入口，在现有网络拓扑下，攻击者需要绕过几层防线才能碰到？
- 有没有鉴权、参数校验、WAF 规则、网络隔离在中间挡着？
- 具体做法：我画一张"攻击路径图"，从外部入口到漏洞触发点，每一跳标注"攻击者需要满足什么前置条件"。如果任何一跳需要"已经是内网 + 有服务账号 + 知道特定 API 路径"，那实际风险就比扫描器报的"高危"低一个量级。
第二步：业务影响评估（走到了能怎样？）
- 最坏情况下，攻击者能拿到什么？（读数据 / 写数据 / 拒绝服务 / 横向移动？）
- 影响范围多大？（单租户 / 全量数据 / 仅元数据？）
- 有没有兜底？（数据加密 / 操作审计 / 自动回滚？）
- 这一步决定了"能不能先用缓解措施扛住，再慢慢修"。
第三步：修复 vs 缓解，排优先级
- 能彻底修的：排进正常迭代，按业务影响排先后。
- 短期修不了但风险可控的：上临时缓解（WAF 规则、网络策略、feature flag 关掉入口），同时排期根治。
- 风险不可控的（比如公网直接可达 + 能拖全量数据）：这个才是真正需要"48 小时"的。
关键一句话：不是"高危就 48h"，而是"不可达的高危可以排期，可达的高危才需要紧急响应"。
【想听大家聊的】
- 你们的"漏洞分诊"有没有明确流程？还是靠安全工程师和开发口头扯皮、最后 PM 拍板？
- 有没有遇到过"安全团队坚持修一个实际不可达的高危，开发坚持不修"最后怎么收场的？谁赢了？代价是什么？
- "安全左移"（CI 集成扫描）落地时，你们怎么处理"扫描器红了但业务不能停"的矛盾？是硬卡发布，还是给一个"带险上线"的审批通道？
- 你们有没有给漏洞"分级"之外的维度？比如"攻击面可达性"、"数据敏感度"、"影响租户数"？怎么量化的？
抛砖引玉，期待各位拍砖。