案例库 · 第四类：定级 / 研判场景
这一类练什么： 一堆漏洞摆在面前，先修哪个。这是应用安全岗最核心的日常，也是你区别于”报漏洞的机器”的价值所在。
读法： 每个案例先自己拍个板——“我会先修哪个”，再看分析。定级没有标准答案，只有”你的判断依据充不充分”。
本类口诀： 分数是漏洞的，风险是环境的。定级 = 严重度 × 可能性 × 影响，后两个因子取决于”你的环境”，不是”漏洞本身”。
案例 16：9.8 的内网 RCE vs 5.3 的公网 SSRF，先修哪个？
问题： 两个漏洞同时出现，一个评分 9.8，一个评分 5.3，你怎么选？
案例： 漏洞 A 是 CVSS 9.8 的 RCE，但只在公司内网测试环境里用到这个组件；漏洞 B 是 CVSS 5.3 的 SSRF，出现在公网门户上，且已经有公开 PoC。安全值班的你，资源只够今晚先修一个。
一般人怎么想： “这还用想？9.8 当然比 5.3 严重啊，分数摆在那儿，先修 9.8。”
咱们怎么想： 分数是”漏洞”的属性，不是”你的风险”的属性。先修哪个，看的是”它打不打得到你、打中了疼不疼”，不是”它的牌面分”。
分析过程（走定级决策链）：
- 漏洞 A（9.8 RCE）：CVSS 很高，但逐条过——可达吗？测试环境用到了，可达。暴露吗？内网测试环境，公网打不到，暴露面极小。可利用吗？有 PoC，但攻击者进不来内网。→ 可能性低。
- 漏洞 B（5.3 SSRF）：CVSS 中等，但——暴露吗？公网门户，直接暴露。可利用吗？有公开 PoC。影响？门户背后能摸到内网/云元数据。→ 可能性高、影响高。
- 结论：先修 B。
一句话启发： 别让 CVSS 分数替你决策。真正的优先级 = 严重度 × 可能性 × 影响，而后两个因子取决于”你的环境”，不是”漏洞本身”。9.8 的洞打不到你，就是纸老虎；5.3 的洞敞着门，就是真威胁。定级是”环境相关”的，不是”漏洞相关”的。
案例 17：SCA 报了 500 个漏洞，怎么排优先级？
问题： 你的 SCA 工具扫出一个老项目，弹了 500 个漏洞，全是”高危”，怎么办？
案例： 一个上线五年的老系统，SCA 扫描结果显示 500 个组件漏洞，其中 200 个是”Critical”。研发一看就崩溃了：“这让我怎么修？全修等于重写。” 安全工程师把这份报告原样丢给研发，研发直接忽略，三个月后真的被打穿——打穿的恰恰是 500 个里”最不该漏”的那一个。
一般人怎么想： “扫描报告都出了，我把它发给研发不就完事了吗？我的工作做完了呀。”
咱们怎么想： 把原始报告丢给研发，等于”没做定级”。SCA 给的是噪音信号，不是风险信号。 你的价值，是把 500 个”噪音”翻译成一份”真正该修的 Top 10”。
分析过程：
- 为什么是噪音：500 个漏洞里，可能 90% 是”不可达”的（组件在，但代码不调用那个有洞的函数），还有一堆是”没暴露”的（内网、无 PoC）。SCA 不会替你想这些，它只会报”有这个洞”。
- 你的价值在哪：逐个过决策链——可达吗？暴露吗？有在野利用吗？影响核心资产吗？ 把 500 个压成”真正该今晚修的几个”。
- 先修什么：先修”公网可达 + 有在野利用 + 影响核心”的那几个，其余挂到迭代慢慢修。同时用可达性分析工具帮研发筛掉误报。
- 教训：这次被打穿，说明”把原始报告丢给研发”= “没做定级”。没有”想”这一环，“看”的结果就是废纸。
一句话启发： 安全工程师的核心产出，不是”一份漏洞报告”，而是”一份排好优先级、研发看得懂的修复清单”。翻译能力，就是你的价值。 500 个漏洞不可怕，可怕的是”500 个同等紧急”——那等于”没有一个紧急”。
案例 18：“不可达”的高危漏洞，为什么可以不急着修？
问题： 一个 9.8 分的反序列化漏洞，你们系统”用了”这个组件，为什么你可以理直气壮地说”低风险，随迭代修”？
案例： 你们系统用了一个 Java 组件，这个组件有个 9.8 分的反序列化 RCE（CVE 已公开）。研发很慌。但你做了可达性分析后发现：这个漏洞的触发点在组件的某个”导入 CSV”功能里，而你们的业务代码根本没用这个功能——也就是说，攻击者拿不到能走到那个反序列化逻辑的入口。
一般人怎么想： “9.8 分啊！高危！赶紧停服升级，一秒都不能等！”
咱们怎么想： 先分清一个关键区别——“组件有洞”和”你会被打”，中间隔着”可达性”这道鸿沟。 SCA 告诉你的是”组件级”结论，你要的是”代码级/调用级”结论。
分析过程：
- 看（组件级）：SCA 说”用了组件”，这是”组件级”的结论——它只看”你依赖了这个包”，不看”你用了有洞的那段代码吗”。
- 想（代码级）：你要的是”调用级”结论——“用到了有洞的那一段代码吗？” 这叫可达性分析（reachability）。功能没被调用 = 漏洞不可达 = 攻击者打不到。
- 做：给研发一个有依据的降级：这个洞对你们是”低风险”，随下个迭代升级组件即可，不用今晚停服。
- 守：但要记录在案——“不可达”是基于”当前代码没调用”的判断，将来如果新代码开始用这个功能，风险等级要重新评估。降级不等于遗忘。
一句话启发： “组件有洞”和”你会被打”之间，隔着”可达性”这道鸿沟。会做可达性分析，你就能把 90% 的”高危告警”变成”淡定”，把精力留给真正的那 10%。
案例 19：一个 PoC 刚放出、还没人利用的漏洞，你怕不怕？
问题： 一个漏洞，PoC 公开了但”在野利用还是 0”，它到底算不算紧急？
案例： 某天凌晨，你常用的一个中间件曝出 RCE，CVSS 9.0，PoC 已经公开，但目前还没有观测到在野利用（CISA KEV 里还没有它，EPSS 分数也不高）。你的系统公网暴露着这个中间件。要不要连夜爬起来修？
一般人怎么想： “还没人利用呢，EPSS 也低，KEV 也没有，说明暂时安全，明天再说吧。”
咱们怎么想： 这里要分清两个指标的性质——在野利用是”滞后指标”，PoC 是”领先指标”。 等你在野利用数据里看到它，往往已经晚了。
分析过程：
- 看：PoC 公开，说明”攻击门槛已经降到脚本小子都能打”。
- 想（关键判断）：PoC 公开了，但还没人用，这个窗口有多久？ 现实是——PoC 公开到”大规模在野利用”之间的时间差，正在越来越短（有时几小时）。因为攻击者现在都是”自动化盯着新 PoC，一出就打”。
- 做：对公网暴露 + 有 PoC 的 RCE，标准做法是当紧急处理——哪怕现在还没人打，PoC 公开这个信号本身就足够让你进入”连夜修”状态。用 WAF 临时规则先顶住，同时排补丁。
- 守：EPSS 低、KEV 没有，只能说明”此刻还没大规模利用”，不能作为”不修”的借口。
一句话启发： 在野利用是”滞后指标”，PoC 是”领先指标”。等你在野利用数据里看到它，往往已经晚了。对公网 RCE，看 PoC，别看”有没有人已经在用”。宁可过度响应，不要赌那个窗口。
案例 20：一个”低危”漏洞，为什么突然变成了最高优先级？
问题： 昨天还是”低危”的漏洞，今天为什么必须放下一切去修？
案例： 你系统里有个 CVSS 只有 4.3 的”中低危”漏洞，一直排在队列尾部。结果这天早上，威胁情报显示：这个漏洞被一个正在活跃的勒索组织纳入了攻击工具链，并且 CISA 把它加进了 KEV（已知被利用漏洞）目录。你的安全经理突然要求”今天必须修”。
一般人怎么想： “分数没变啊，还是 4.3，为什么突然要修？安全经理是不是被忽悠了？”
咱们怎么想： 变的不是”严重度”（脆弱性），是”可能性”（威胁）。定级是动态的——风险 = 严重度 × 可能性 × 影响，任何一个因子变了，风险就变。
分析过程：
- 看：漏洞本身的技术严重度没变，还是 4.3。
- 想：变的不是”严重度”，是”可能性”——从”理论可打”变成了”正在被打”。威胁情报（KEV、勒索组织动向）会实时改变一个漏洞的”可能性”因子。
- 做：立即提升优先级、当天修复或临时缓解（限制暴露面、加检测规则）。
- 守：这个案例说明”定级”不是一次性动作，要持续刷新——你需要一个机制，让”新的威胁情报”能自动触发”旧的定级重估”。这就是 SOAR/漏洞管理平台在”守”这一环的价值。
一句话启发： 风险 = 可能性 × 影响。影响不变时，可能性一变，风险就变。所以定级必须”跟着情报走”，而不是”定了就躺着”。
本类小结：定级的本质是乘法，不是排名
把五个案例串起来，你会得到一条清晰的”定级决策链”：
严重度(CVSS) × 可能性(可达？暴露？在野？PoC？) × 影响(打中什么资产？) = 真风险
记住三句话：
- 分数是漏洞的，风险是环境的（案例 16）——别让 CVSS 替你拍板。
- 翻译，是你的价值（案例 17、18）——把噪音翻译成 Top10、把”组件有洞”翻译成”代码不可达”。
- 定级是动态的（案例 19、20）——PoC 是领先指标、情报会改可能性，所以定级必须持续刷新。
定级，本质是”把一堆漏洞，变成一份’今晚先修谁’的决策”。 会写代码的人很多，能把 500 个漏洞翻译成 10 个行动项的人，才值钱。