基于风险的漏洞优先级排序：超越单一评分的决策逻辑

我们先看一个假设性的对比。发现项A在技术严重性评分中被评为「严重」级别。它位于一个内部报表服务中，只能从管理网段访问。该服务不处理个人数据或支付数据，也没有任何已知证据表明有人正在利用这个漏洞。发现项B被评为「中危」。它位于一个面向互联网的客户门户所使用的第三方库中，该漏洞已被列入记录在野利用证据的漏洞目录，而客户正是通过这个门户管理自己的账户。这两个例子都是虚构的：它们不描述任何真实系统或事件，只是为了让决策逻辑更直观。

如果只按严重性给积压问题排序，排在前面的是发现项A。但如果团队追问：谁能接触到每个缺陷？攻击者现在是否已经在利用它？一旦被攻破会损失什么？那么优先处理发现项B的理由就会充分得多。问题不在于严重性评级没有用，而在于一个数字无法同时容纳五个不同的答案。

本文是一份面向CISO、CTO和研发负责人的编辑指南，讨论基于风险的漏洞优先级排序。文章说明如何把技术严重性、利用可能性、在野利用证据、资产暴露面和业务影响作为彼此独立的输入来考虑，依赖链和补偿性控制如何改变判断，以及修复负责人、例外到期和复测如何把一份排序变成闭环。本文讨论的是通过授权测试、扫描和代码审查得到的发现项，不包含任何利用方法。

为什么单一评分无法承载决策

优先级决策回答的是一个实际问题：在工程时间有限的情况下，团队究竟应该修复什么、在哪个资产上修复、按什么顺序修复。单一评分之所以诱人，是因为它便于排序。问题在于，一个合理决策背后的各项输入衡量的是不同的东西。把它们相加，或乘以权重后再合并，得到的数字事后没有人能解释清楚它的含义。

技术严重性、利用可能性、已知利用、暴露面和业务影响回答的是不同的问题。只要它们保持分开，审查者就能看出某个发现项为什么排在当前位置，可以质疑其中一项输入而不必改写其他各项，并在某个事实变化时更新决策。一旦它们被合并成一个数字，任何一项输入的变化都会淹没在总分里，讨论也会从事实本身变成对公式的争论。

综合评分还会带来虚假的精确感。设定一个阈值，声称低于它的发现项可以暂缓，就会诱使人们争论零点几分的差异，而不是讨论资产是否可达、它保护着什么。把各项输入分开并不意味着放弃结构。组织仍然需要一致的规则、书面的政策和可比较的决策。只是规则作用于明确命名的事实，例如「存在在野利用且可从互联网访问」，而不是作用于一个看不出由哪个事实决定结果的不透明总分。

每个信号回答的是什么问题

技术严重性：缺陷可能造成什么

技术严重性描述的是缺陷本身的属性：攻击者通过利用可以达到什么目的，利用的复杂程度如何，以及需要什么权限或用户交互。CVSS等评分体系让这种描述在不同产品和供应商之间保持一致，这对初步分诊和沟通都很有帮助。

严重性属于缺陷，而不属于你的环境。同一个库漏洞，无论位于隔离的测试工具中，还是位于生产服务的支付流程中，其基础评分都相同。因此，严重性作为输入之一效果很好，作为唯一输入则效果很差。应把它看作对「原则上可能有多糟」这一问题的回答，并记录评分体系版本和所依据的假设，以便日后的审查者在同等条件下进行比较。

一个有用的做法是，把公开发布的严重性与自己对具体实例的评估区分开。如果团队认为公开评级在自身环境中高估或低估了缺陷的危害，相应理由应连同证据写入暴露面、影响或控制措施字段，而不是悄悄修改严重性数值。

利用可能性与在野利用证据

可能性和证据相互关联，但它们是不同的信号。前者是前瞻性的估计，后者是对已观察到情况的记录。把两者混为一谈会导致两种相反的错误：把预测当作证据，把记录缺失当作可以放心的理由。

EPSS：概率估计，而非影响度量

由FIRST维护的漏洞利用预测评分系统（Exploit Prediction Scoring System，EPSS）估计的是某个漏洞在未来30天内被利用的概率。因此，当大量发现项在其他方面难以区分时，它有助于排出先后顺序，也有助于发现预期利用活动正在上升的漏洞。

EPSS并不衡量对特定组织的业务影响。一个没有人能接触到、也不保护任何重要内容的组件，即使概率很高，也不会因此比一个对外暴露且存有敏感数据的系统更重要。由于EPSS是针对一个时间窗口的估计，应把数值连同获取日期一起记录下来，并在重新审视决策时再次核对。

KEV：利用证据，而非安全清单

CISA的已知被利用漏洞（Known Exploited Vulnerabilities，KEV）目录收录的是有在野利用证据的漏洞。这类证据可以有力地影响优先级排序：一旦知道某个漏洞正在被利用，问题就从「这能被攻击吗？」变成了「我们的实例是否可达，是否受到保护？」

有两个局限需要注意。第一，漏洞没有列入KEV并不意味着它是安全的：目录记录的是已收集到的证据，而利用可能在条目加入之前就已开始，甚至可能始终没有对应条目。第二，与KEV相关的修复期限适用于美国联邦机构的情境，并不是对所有国家组织普遍适用的法律要求。你的修复时限应由本组织政策以及真正适用于你的规则来确定。

受影响资产的暴露面与可达性

暴露面回答的是谁能接触到易受攻击的组件、通过什么路径接触。面向互联网的服务、可从合作伙伴网络访问的接口，以及只能从受限管理网段访问的组件，即使缺陷完全相同，给攻击者带来的机会也截然不同。

可达性应当有证据支撑，而不是凭假设。有用的证据包括与实际相符的网络拓扑图、防火墙和负载均衡器配置、云安全组规则，以及能显示从外部实际可见内容的外部攻击面评估结果。在暴露面得到确认之前，应记录较为谨慎的值。对网络分段的乐观假设，是优先级在无人察觉的情况下被降低的最常见原因之一。

暴露面也会变化。一次新的集成、迁移到不同的托管模式，或一次临时的防火墙规则调整，都可能把内部组件变成可从外部访问的组件。暴露面的任何变化都应触发对相关发现项的复审，无论它们当前处于什么优先级。

业务影响：组织可能失去什么

业务影响描述的是哪些流程、数据集或义务依赖该资产，以及资产被攻破后会发生什么。这项输入只有组织自己才能提供。没有任何公开目录知道某台报表服务器为监管报送提供数据，也不知道某个看似次要的服务存放着支付集成的凭据。

业务影响应由资产所有者确认，并记录在资产登记册或风险治理配置文件中。NIST网络安全框架2.0旨在帮助组织理解和管理网络安全风险，CSF配置文件很适合用来记录哪些资产和成果是关键的。常见的影响类别包括敏感数据泄露、业务记录完整性受损、面向客户的服务可用性丧失，以及失去对某个可被用来进一步接触其他系统的系统的控制。

影响不取决于可能性，可能性也不取决于影响。一个关键资产上难以触达的缺陷，和一个次要资产上正被积极利用的缺陷，是两类不同的问题。正是把影响单独记录，管理层才能看到真实的权衡，而不是一个数字。

依赖链：当中等发现项打开攻击路径

发现项很少孤立存在。一个中等程度的信息泄露可能暴露内部主机名；一处身份配置错误可能让人从一个账户转移到另一个账户；依赖树深处的某个易受攻击组件，可能只是因为公开入口把数据传递给它才变得可达。在所有这些情况下，风险存在于整条链中，而不在任何单个环节。

因此，优先级排序时应追问：这个发现项是否是通往更有价值目标的一步？以下问题会有帮助。这个发现项是否提供了另一个发现项所需的访问权限、凭据或信息？易受攻击的库是否被可达的代码路径调用，还是仅仅存在于构建产物中？修复其中一个环节能否打断整条链，哪个环节修复成本最低？

渗透测试在这里尤其有用：在约定范围内并取得书面授权后，测试人员可以展示各个发现项如何组合在一起。依赖链应作为发现项之间的关联关系记录下来，这样关闭一个环节时会触发对其他环节的重新评估，而不是想当然地认为整条路径已经消失。

补偿性控制：经过验证、范围明确、临时有效

并非每个紧急发现项都能立即修复。在安排修复期间，补偿性控制可以合理地降低风险，但前提是它确实适用于该漏洞。例如，内容安全策略（Content Security Policy）允许网站限制浏览器可以加载哪些资源，有助于缓解某些跨站脚本和数据注入攻击。网络访问限制、Web应用防火墙规则和关闭相关功能，也可以对其他类别的缺陷起到类似作用。

补偿性控制要可信，需要满足三个条件。第一，必须经过验证：授权测试应确认该控制能阻断相关行为，因为来源列表过宽的策略或可被绕过的规则可能几乎起不到保护作用。第二，范围必须明确：记录中要写明它针对哪个发现项、哪个资产和哪条攻击路径。第三，必须是临时的：原发现项保持打开状态并设定复查日期，因为控制措施只能降低可能性或影响，并不能消除根本原因。

如果某个产品缺陷只能靠客户侧的变通措施来缓解，这一点也应记录下来。CISA「设计即安全」（Secure by Design）的立场是，安全负担不应不成比例地落在客户身上，这类情况对于供应商管理和未来采购都是有用的依据。

不依赖综合评分的决策逻辑

决策逻辑用明确的问题取代算术运算。团队不去计算总分，而是围绕明确命名的事实提出一组简短的问题，并记录每个问题的答案。最终得到的是优先级类别、修复路径和负责人，以及得出这些结论的理由。

下面的模式说明了这种做法如何运作。它们是需要结合本组织政策进行校准的起点，而不是普遍适用的规则：

• 存在已知利用、实例可达且没有经过验证的补偿性控制时，无论严重性标签如何，通常都有理由立即采取行动。
• 资产已确认不可达且影响较低时，即使严重性较高，往往也可以纳入正常的发布周期，前提是不可达的证据已被记录，并在环境变化时复审。
• 对外暴露且影响较大的资产，如果利用可能性估计在上升，即使尚未出现利用证据，也应提前作出决策。
• 属于已被演示的攻击链的发现项，应按照这条链最终能触达的目标价值来确定优先级，而不是按其自身评级。
• 利用证据、暴露面或影响的任何变化，都会让决策重新打开。

1. 确认事实分别记录严重性、可能性估计、已知利用、暴露面和业务影响，并为每项输入注明来源和日期。
2. 检查攻击路径确认实例是否可达，以及它是否属于通往更有价值资产的依赖链。
3. 选择处理路径在修复、经过验证的补偿性控制或有时限的例外之间作出选择，并指定修复负责人。
4. 验证结果在明确的条件下复测具体的修复或控制，并在关闭前附上证据。
5. 变化时复审当利用证据、暴露面、业务影响或例外到期日发生变化时，重新审视决策。

这种做法的价值在于可追溯。当管理层问为什么一个中危发现项比严重级发现项先修复时，记录会显示决定这一结果的事实。如何把这套逻辑嵌入发现、评估和关闭的常规循环，可参阅关于如何建立漏洞管理流程的指南。

修复负责人、例外与到期

没有负责人的优先级只是一种愿望。每个没有立即关闭的发现项，都需要一位明确的修复负责人、一条选定的处理路径，以及作出下一次决策的日期。

指定修复负责人

修复负责人是真正能够修改受影响系统的个人或团队：应用代码由产品团队负责，共享基础设施由平台团队负责，修复依赖供应商时由供应商管理人员负责。负责关系应依据资产登记册确定，而不是由碰巧报告该发现项的人承担。如果修复涉及多个团队，依赖链往往就是这种情况，应指定一位协调负责人，并记录参与的各个团队。关于如何把这些工作一直跟踪到完成，可参阅关于漏洞修复管控的文章。

设定到期日的例外

有时正确的决定是暂不修复：系统即将下线，修复需要等待供应商发布新版本，或者业务方决定在一段明确的时间内接受该风险。这类决定可以记录为有时限的风险接受；其是否符合适用法律、合同和监管要求，必须另行评估。例外记录应写明由谁接受、依据什么权限接受，适用哪些补偿性控制，哪些条件会使例外失效，以及何时到期。

到期日是必需的。没有截止日期的例外会变成永久且不可见的风险接受。例外到期后，该发现项应回到队列中，依据最新证据重新作出决策。修复时限和例外期限由组织政策确定；本文所审阅的公开来源并未规定具体天数。

复测与验收证据

发现项应当依据证据关闭，而不是依据工单状态关闭。复测确认的是某项具体修复或控制在明确的条件下有效：测试的版本、环境、测试方法和日期。它不能证明风险永久消失，不能证明其他地方不存在类似缺陷，也不能证明后续变更不会让问题重新出现。

验收标准最好在修复开始之前就达成一致，这样负责人知道需要什么证据才能关闭发现项。方法一致也有帮助：基于OWASP Web安全测试指南（WSTG）和NIST SP 800-115的测试程序，能让复测与原始测试具有可比性。关于这种验证的实际步骤，可参阅关于如何证明渗透测试后的修复真正有效的文章。无论是渗透测试还是优先级排序流程，都不是认证、鉴证或安全保证意见：它们提供的是特定时间点、针对特定发现项的证据。

弱点类别与标准：从发现项到根本原因

对单个发现项排序是必要的，但同一类别的发现项反复出现，说明存在根本原因，而这是再快的补丁速度也无法消除的。MITRE的CWE Top 25榜单列出了在已公开CVE记录中严重且普遍的弱点，MITRE还发布了基于KEV目录的弱点排名。前者反映整个行业中常见的问题，后者反映攻击者已经在使用的弱点。两者都不描述你的环境，因此它们有助于根本原因治理，但不能取代你自己的背景信息。

把每个发现项映射到CWE编号，并把Web发现项映射到OWASP Top 10类别和OWASP ASVS要求，可以为开发人员和管理者提供共同语言。ASVS建议在引用要求编号时同时注明标准版本，因为编号可能随版本变化。在工单中使用这种格式，可以让决策长期保持可追溯。

如果积压问题中有相当一部分属于同一类别，例如注入问题或内存安全问题，那么通过架构、更安全的框架或安全默认配置来消除整类问题，通常比加快单个修复带来更大收益。用这样的语言向管理层汇报，即哪些类别反复出现、出现在哪些资产上、紧急发现项保持打开多久，能为资助结构性改进提供依据。

如何选择漏洞优先级排序服务或工具

决策逻辑清楚之后，评估商业产品就容易多了。目标是采购对自身模型的支持，而不是把风险的定义交给供应商的公式。

可以向任何平台、托管服务或测试服务商提出以下问题：

• 该方案能否针对每个发现项展示决定其优先级的各项独立输入，并导出这些理由？
• 它是否把严重性、利用可能性估计、已知利用、暴露面和业务影响保存在各自独立的字段中，而不是合并成一个不透明的数字？
• 它能否导入你的资产登记册、暴露面数据和负责人信息，而不是套用通用数值？
• 它是否记录带有负责人和到期日的例外，并在例外失效时发出提醒？
• 它是否支持复测和基于证据的关闭？
• 对于测试服务：工作是否在约定范围内、取得书面授权并按照公认方法开展？

对无法验证的说法要保持谨慎。如果供应商给出风险降低数字或模型准确率，应索取方法和数据，并在你的环境中得到验证之前，把该数字视为供应商的自述。询问供应商是否作出过CISA「设计即安全」承诺（Secure by Design Pledge）之类的公开承诺是合理的，但承诺不是认证，应与其实际做法一并权衡。

从积压到决策：实践下一步

当每项决策背后的事实始终可见时，基于风险的漏洞优先级排序才能真正发挥作用。严重性告诉你缺陷可能有多严重；可能性估计告诉你近期出现攻击活动的概率有多大；已知利用告诉你已经观察到了什么；暴露面显示谁能接触到资产；业务影响则说明利害所在。依赖链和经过验证的控制会修正这一判断，而负责人、到期日和复测则让它保持真实可信。

一个务实的起点是：选取积压问题中的一小部分，为每个发现项分别记录这五项输入，指定负责人，并商定关闭每一项所需的证据。如果你需要关于可达性、攻击链或修复有效性的独立证据，可以说明需要与Pentest.red合作测试的系统和限制条件，并在工作开始前商定测试边界。