managing-vulnerabilities

管理漏洞

扫描器返回了 10,000 条发现结果，其中大多数评级为高危或严重，而团队每月只能修复几百条。漏洞管理的职责就是决定优先修复哪几百条——默认按 CVSS 从高到低排序，几乎是最糟糕的做法，因为 CVSS 衡量的是理论严重性，而不是该漏洞在该资产上遭到利用的概率。

这项工作的核心，是将一份不加区分的积压清单转化为合理、有据可依的处理顺序，让人手有限的团队也能切实执行。

适用场景

• 将漏洞扫描器的输出整理为修复顺序
• 在修复预算固定时决定先修复哪些漏洞
• 建立或审查基于风险的漏洞管理流程
• 解释为什么 CVSS 9.8 不是本周的首要任务
• 判断某项发现是否应申请例外，而不是修复

不适用场景

• 处理安全警报队列（EDR/SIEM 检测）——使用 triaging-security-alerts；那是已检测到的活动，而这里讨论的是潜在弱点
• 审计源代码以发现新漏洞——使用 auditing-code-for-vulnerabilities
• 处理云配置错误，而非软件 CVE——使用 hardening-cloud-posture
• 利用漏洞以验证其影响——使用相关的攻防技能

CVSS 衡量严重性，而非优先级

CVSS 基本分数回答的是“如果漏洞被利用，理论上会有多严重？”它并不回答“这个漏洞会在这里遭到利用吗？”——而修复顺序实际上取决于这个问题。证据十分明显：绝大多数 CVE 从未在现实环境中遭到利用，但大多数仍被评为高危或严重。按 CVSS 排序，会耗费团队有限的资源去修复永远不会被攻击的漏洞，而真正遭到利用的漏洞却只能排在它们后面。

将 CVSS 4.0 作为一个输入——即严重性指标——并结合反映利用概率和在当前环境中的影响的信号。

需要结合的三个信号

1. 是否正在遭到利用？——EPSS 和 KEV

• CISA KEV（已知遭利用漏洞）。 这是一个精选目录，收录了在现实环境中已确认遭到利用的 CVE。列入 KEV 是现有最有力的优先级信号：它不是预测，而是已遭利用的事实。环境中任何列入 KEV 的漏洞都应优先处理。对于美国联邦机构，KEV 还规定了有约束力的修复期限；即使你不受这些期限约束，也应将其视为合理的默认期限。
• EPSS（漏洞利用预测评分系统）。 这是一个每日更新的机器学习概率，取值范围为 0 到 1，用于预测某个 CVE 在未来 30 天内遭到利用的概率。它是预测，不是已观察到的事实；它表示概率，而非排名——0.90 表示可能性约为 90%，而大多数 CVE 的分数远低于 0.10。用它为尚未列入 KEV 的大量其他漏洞排序。由于 EPSS 每日更新，请重新获取分数；当漏洞利用工具出现时，CVE 的 EPSS 可能会迅速攀升。

KEV 和 EPSS 回答的是不同问题——“已知遭到利用”与“很可能遭到利用”——两者都不可或缺。KEV 是确定性的底线；EPSS 则为其余漏洞排序。

2. 漏洞是否可被触及？——暴露面和上下文

已存在但不可触及的漏洞，与攻击者能够触及的漏洞并不相同：

• 受影响的服务面向互联网、仅供内部使用，还是位于隔离网段？
• 是否实际调用了存在漏洞的代码路径，还是该依赖虽然存在、却从未被调用？（可达性分析——依赖相关情况请参阅 auditing-supply-chain。）
• 是否有补偿性控制——例如 WAF 规则、网络策略或已禁用的功能——能够破坏漏洞利用的前提条件？
• 利用漏洞是否需要身份验证、本地访问权限或用户交互，而这些条件因部署位置而不太可能满足？

一个面向互联网、无需身份验证、列入 KEV 的 RCE，与一个仅在内部可访问、需要身份验证且 CVSS 相同的漏洞，优先级并不相同，无论分数如何显示。

3. 它保护什么？——资产价值

域控制器、核心数据库和开发人员的一次性 VM 上存在同一漏洞，紧急程度各不相同。应根据资产关键性评估发现；没有资产清单的漏洞管理计划，就只能盲目排序。

使用 SSVC 决策，而非单一数字

与其把所有因素压缩成一个分数，不如采用决策树方法（SSVC——利益相关方特定漏洞分类），按顺序提出上述问题，最终得出行动方案：利用状态 → 暴露情况 → 可自动化利用 → 影响 → {跟踪 / 跟踪* / 处理 / 采取行动}。 这种方法的价值在于，团队可以向实际执行工作的人员和批准例外的风险负责人解释清楚每项决策，而“评分为 8.7”永远做不到这一点。

无论采用哪种框架，产出都必须是有序、可执行且标明责任人和日期的清单，而不是风险评分。该计划的成果应是完成修补的系统，而不是仪表板。

如实跟踪修复和例外

• 发现项在验证修复前始终处于开放状态，不能因为工单已关闭就算完成。重新扫描以确认；“已修补”和“不再检测到”是两种不同的说法。
• 例外是有责任人和到期日的决策，不是悄悄抑制发现项。“接受风险”却没有姓名和复审日期，正是 KEV 中的 CVE 会开放一年的原因。
• 漏洞复发说明流程存在问题。 修复后同一漏洞再次出现，意味着基础镜像、黄金模板或流水线又将其引入——应该修复源头，而不是修复实例，这与云防护措施胜过临时修补的道理相同。

应拒绝的说法

• “它的评分是 9.8，所以优先级最高。” CVSS 衡量的是严重性，而不是被利用的概率。一个不在 KEV 中、EPSS 较低且位于隔离内部主机上的 9.8 级漏洞，优先级低于一个已列入 KEV 且面向互联网的 7.5 级漏洞。
• “它只有 5.3，我们可以忽略。” 如果它已列入 KEV 且可被触达，就不能忽略。已观察到的利用情况优先于平平无奇的严重性评分。
• “我们会在 30 天内修补所有严重级漏洞。” 按严重性设定统一 SLA，会把预算花在错误的维度上。应在数日内修补已遭利用且可被触达的漏洞；未遭利用、无法触达的严重级漏洞可以稍后处理。
• “依赖项存在漏洞，所以我们也有漏洞。” 只有在易受攻击的代码路径可被触达时才是如此。存在但未被调用的代码确实会形成积压，但紧急程度不同于已被调用的代码。
• “EPSS 很低，所以很安全。” EPSS 是对未来 30 天的预测，而且会变化。应重新获取数据，并记住 KEV 的优先级高于 EPSS——已观察到的情况胜过预测。
• “我们关闭了工单。” 关闭工单不等于修复漏洞。应重新扫描并验证，否则漏洞仍处于开放状态。
• “这是已接受的风险。” 谁接受的？何时复审？没有责任人和到期日的例外，只是贴着标签、无人管理的漏洞。

阅读外部来源

以 Markdown 格式获取公开公告、规范和供应商报告：

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

这样可以剥离页面杂项——对于以文字为主的页面，令牌数大约减少 78%——并返回全文而非摘要，因此你可以搜索内容，也可以相信没有搜索结果这一结论。

它不适用于以下三种情况。应直接获取 JSON 和 API 响应，因为可读性提取会破坏结构化数据。应直接获取需要身份验证或由 JavaScript 渲染的页面，因为该工具会以匿名方式检索。切勿通过它传递对手基础设施（钓鱼链接、C2、恶意软件托管）、客户端拥有的主机或参与测试的网址——请求会离开你的机器并发送给第三方；对于正在使用的对手基础设施，这还会向操作者发出警报。

有些网站会拦截提取器并返回错误内容，而不是页面——例如 freedesktop.org 返回的 {"error":"Failed to fetch: 418 I'm a teapot"}。这表示获取请求遭到拒绝，并不代表来源网站声称相关内容不存在。在据此得出任何结论前，请直接重新获取该 URL。

参考

• triaging-security-alerts — 与这项潜在弱点工作对应的已检测活动；两者都会在容量有限的情况下按实际风险排序
• auditing-supply-chain — 依赖项可达性，是库 CVE 信号 2 的输入
• hardening-cloud-posture — 软件 CVE 的配置错误对应项
• reporting-security-findings — 向负责人传达经过优先级排序的风险