【国际视野】美国国家标准与技术研究院推出识别IT漏洞利用的公式

发布于2025年5月23日2025年7月19日作者:cve-20

【国际视野】美国国家标准与技术研究院推出识别IT漏洞利用的公式

原创天极智库天极智库 2025-05-23 10:31

“

天极按

近日，
网络安全和基础设施安全局（CISA）发布了《联合网络防御协作组织人工智能网络安全协作手册》（Joint Cyber Defense Collaborative (JCDC) Artificial Intelligence (AI) Cybersecurity Collaboration Playbook）。该手册是通过 JCDC 与联邦、国际和私营部门合作伙伴共同开发的，它为人工智能社区（包括人工智能提供商、开发商和采用者）提供了关于如何自愿共享可操作事件信息的基本指导，并介绍了主动共享信息如何能够加强操作协作和提高人工智能系统的复原力。

网络安全和基础设施安全局（CISA）通过联合网络防御协作组织（JCDC）与联邦、国际和私营部门的合作伙伴合作，牵头制定了人工智能（AI）网络安全协作手册。JCDC 是 CISA 内部的一个公私协作组织，利用国会在 2021 年《国防授权法案》（NDAA）中授予的权力，联合全球网络社区共同防御网络空间。JCDC 人工智能网络安全合作手册是 2024 年举行的两次桌面演习 (TTX) 的直接成果，这两次演习汇集了联邦、行业和国际合作伙伴。第一次桌面演习于 2024 年 6 月在弗吉尼亚州雷斯顿的微软公司举行，通过应对人工智能（AI）网络安全事件带来的独特挑战奠定了基础。这项基础性工作为操作手册的早期开发提供了参考。第二次
TTX 于 2024 年 9 月在加利福尼亚州旧金山的 Scale AI 总部举行，通过模拟金融服务领域的人工智能网络安全事件，帮助参与者进一步完善操作手册。CISA 将大约 150 名参与者（包括来自美国联邦机构、私营部门和国际政府组织的代表）的实时反馈纳入了游戏手册。这些演习强调了加强业务协作和信息共享的必要性，最终形成了操作手册的最终版本。

受众

本手册向网络安全操作专业人员（包括事件响应人员、安全分析师和其他技术人员）介绍如何与 CISA 和 JCDC 合作并共享有关人工智能相关网络安全事件和漏洞的信息。

背景介绍

CISA 作为美国的网络防御机构和关键基础设施安全与恢复能力国家协调员，在应对人工智能特定网络安全挑战方面发挥着至关重要的作用。通过 JCDC.AI，CISA 建立了公私合作伙伴关系，以改善信息共享并制定计划，促进协调应对针对软件系统（包括人工智能系统）的网络威胁。随着人工智能越来越多地融入关键基础设施，了解并应对其独特的挑战和复杂性，对于加强对恶意网络行为者的防御至关重要。

人工智能系统依赖于数据驱动的非确定性模型，因此具有独特的复杂性，容易受到恶意网络活动的攻击，如模型中毒、数据篡改和对抗性输入。CISA 与 JCDC 合作伙伴合作，利用共享的知识和能力来对抗恶意网络行为者并加强集体应变能力。

目的

JCDC 人工智能网络安全合作手册促进人工智能社区（包括人工智能提供商、开发商和采用者）自愿共享信息，以加强集体网络防御，应对新兴威胁。该手册旨在促进政府、行业和国际合作伙伴之间的业务合作，并将定期更新，以确保随着人工智能应用的加速，能够适应动态的威胁环境。该手册旨在：

指导 JCDC 合作伙伴如何自愿共享与人工智能系统相关的事件和漏洞信息。
概述 CISA 在收到共享信息后应采取的行动。
促进联邦机构、私营企业、国际合作伙伴和其他利益相关者之间的合作，以提高对人工智能网络安全风险的认识，并提高人工智能系统的复原力。

虽然该手册侧重于加强联合反恐委员会内部的合作，但也定义了适用于其他信息共享机制的关键信息类别（附录 C），如信息共享和分析中心（ISAC）。CISA 鼓励各组织采用该操作手册的指导意见来加强自身的信息共享实践，从而有助于采用统一的方法来应对关键基础设施中与人工智能相关的威胁。

关键定义

JCDC 人工智能网络安全协作手册纳入了关键立法和技术框架中的定义，为应对人工智能网络安全挑战奠定了基础。

人工智能系统：基于机器的系统，针对人类定义的特定目标，做出影响真实或虚拟环境的预测、建议或决策。这些人工智能系统使用基于机器和人类的输入来感知环境，通过自动分析将这些感知抽象为模型，并使用模型推理来提供信息或行动选项。
事件： “事件 “一词是指未经合法授权而实际或即将危及信息系统信息的完整性、保密性或可用性，或未经合法授权而实际或即将危及信息系统的事件。

根据这些定义，CISA 制定了人工智能网络安全事件的工作定义：“未经合法授权，实际或即将危及人工智能系统、人工智能系统启用和/或创建的任何其他系统或存储在任何这些系统上的信息的保密性、完整性或可用性的事件”。

网络安全事件通常源于软件或系统中的漏洞。美国国家标准与技术研究院（NIST）将漏洞定义为 “信息系统、系统安全程序、内部控制或实施中可能被威胁源利用或触发的弱点”，是人工智能系统网络安全的核心。该手册还有助于协调披露关键基础设施中与人工智能系统相关的漏洞。

信息共享：保护与机制

通过 JCDC 共享信息，公司可从加强协调和政府支持中获益，并获得在可信环境中就人工智能网络安全问题进行合作的能力。JCDC 为关键基础设施部门的重要网络安全问题提供了沟通机制，使企业能够讨论和应对人工智能网络安全方面的共同挑战。JCDC 的召集能力可帮助企业获得有价值的威胁情报、缓解策略和协作性网络安全环境。

通过共享信息，JCDC 加快了对网络威胁的协调响应，并帮助政府合作伙伴收集必要信息，以确定是否应启动国家事件响应机制。此外，JCDC 还制作和分发相关的网络威胁情报、漏洞管理见解和缓解策略，使公司能够更好地管理和消除新出现的威胁。

信息共享保护

《网络安全信息共享法案（2015）》（CISA 2015）为非联邦实体提供了保护，使其可以按照特定要求与政府共享网络威胁指标和网络安全防御措施，并规定尽管有任何其他法律，它们也可以这样做。这些保护措施包括不放弃特权、保护专有信息、免于根据《信息自由法》（FOIA）进行披露、禁止在监管执法中使用等。《网络安全信息共享法案（2015）》还要求国土安全部具备与联邦政府和私营部门实体共享网络威胁指标的能力和流程，并为通过该流程共享的信息提供责任保护。该法规还为按照法定要求与州、地方、部落和领地 (SLTT) 实体共享的网络威胁指标和防御措施制定了保护措施，包括根据 SLTT 信息自由法，这些信息免于披露。《网络安全信息共享法案（2015）》不涵盖法律规定的非网络威胁指标或防御措施的共享信息。与人工智能相关的信息只要符合网络威胁指标或防御措施的条件，就属于该法的管辖范围。

信息共享机制

CISA 制定了管理和保护 JCDC 合作伙伴共享数据的流程。

JCDC 内部的信息共享

CISA 利用交通灯协议 (TLP) 作为其主要的传播控制标记系统。JCDC 内部通过电子邮件共享的所有数据均应明确标注相关的 TLP 名称。同样，其他利益相关者也可通过电子邮件与 JCDC 共享信息，[email protected]，并遵循 TLP 标记系统。某些 TLP 标记要求在向组织外传播前获得信息来源的许可。所有组织都应在分享前寻求适当的许可。下文 “主动信息共享 ”和 “关于事件或漏洞的信息共享 ”部分提供了有关与 JCDC 共享的有价值信息类型的更多指导。

有时，JCDC 合作伙伴可能希望在不注明出处的情况下共享信息。在这种情况下，这些合作伙伴可直接与 CISA 共享，由 CISA 在不注明出处的情况下继续共享。合作伙伴在与 CISA 共享信息时，应提供有关如何处理其信息的详细说明，并指定信息使用的任何限制（如清单 1 所述）。有了这些保障措施和协议，CISA 可在 JCDC 内部营造一个共享关键网络安全信息的安全环境，鼓励积极参与并保护敏感数据。附录 A 提供了表 1 的填充示例。

表 1：信息处理限制与背景

新漏洞协调实践

要报告新发现的产品和服务中的网络安全漏洞，JCDC 合作伙伴应使用 CISA 的协调漏洞披露流程。合作伙伴可通过 CISA 协调漏洞披露页面上的 “报告漏洞 ”链接安全地提交漏洞。如果 JCDC 合作伙伴对此流程有疑问或担忧，请联系 JCDC 代表。该代表可将合作伙伴与 CISA 漏洞管理人员联系起来。

其他需要考虑的漏洞协调最佳实践：

制定并实施漏洞披露政策 (VDP)，以便安全研究人员和其他人员了解哪些类型的测试可用于哪些系统，以及向何处发送漏洞报告。有关 CISA 与联邦机构共享的 VDP 示例，请参阅 Binding Operational Directive 20-01。联合数据中心合作伙伴应酌情修改 VDP 模板。
如果在 JCDC 合作伙伴运营的系统中发现漏洞，各实体应按照该合作伙伴的 VDP，根据其特定指南报告问题。
如果 JCDC 合作伙伴发现已部署的联邦政府系统中存在漏洞，则应按照其 VDP 中的要求通知系统所有者。作为最后手段，可通过卡内基梅隆大学软件工程研究所 (SEI) CERT 协调中心向 CISA 报告这些问题。

事件报告

要报告事件，JCDC 合作伙伴应使用 CISA 的自愿网络事件报告门户。报告实体应在表格中提供的解释性文本框中描述事件中与人工智能相关的任何方面。

主动共享信息

JCDC
强烈鼓励合作伙伴尽早主动共享人工智能网络安全事件或漏洞的可操作信息。鉴于人工智能系统的复杂性以及在识别安全问题及其根源方面的挑战，
JCDC
合作伙伴应持续、主动地共享有关恶意活动、趋势、发布前出版物和评估的关键信息。持续的信息共享可使所有合作伙伴保持对不断变化的环境的态势感知，从而实现对关键威胁的早期检测、识别和修复。通过建立一个信息灵通、相互协作的网络防御网络，
JCDC
加强了对所有关键基础设施部门的人工智能系统的保护和恢复能力。

表 1 所列的主动信息共享类别有助于 CISA 和 JCDC 合作伙伴评估已观察到的相关信息，了解行动环境的复杂性，并就潜在的防御行动做出明智决策。另请参阅附录 B，了解鼓励合作伙伴主动共享信息的事件示例。

表 1：主动信息类别

共享有关事件或漏洞的信息

JCDC
合作伙伴应
表
2
，自愿共享有关人工智能网络安全事件或漏洞的信息。其他利益相关方可通过电子邮件与
JCDC
共享自愿信息，电子邮件地址为
[email protected]
。该核对表有助于突出可操作的数据，以简化
JCDC
与合作伙伴之间的共享流程。附录
A
提供了
表
2
的填充示例。
JCDC
鼓励合作伙伴遵循核对表，同时也欢迎共享任何相关信息，即使未满足核对表的所有要点。

此外，使用网络表格自愿报告事件或产品或服务中的漏洞是通过加密渠道向 CISA 提供所有相关信息的好方法。如果使用网络表格，JCDC 合作伙伴应通过电子邮件通知 JCDC 代表。

表 2：主动信息共享

CISA 的信息分析和业务使用

图 1：CISA集体行动方法

作为从 JCDC合作伙伴收集信息的中心枢纽，CISA管理和协调所需的集体行动（见图1）。当 CISA收到有关网络安全事件或漏洞（包括人工智能特有的事件或漏洞）的信息时，它首先会将信息输入中央跟踪平台进行汇总和验证。在此阶段，CISA会删除任何可能不构成威胁的合法或良性指标，并确保从数据集中删除任何可识别受害者身份的信息，以保护隐私。

接下来，CISA继续分析和丰富数据。这包括确认指标是否与特定合作伙伴（如云服务提供商或互联网服务提供商）相关，以酌情促进协调。可利用CISA 现有数据进一步丰富信息。CISA会进行额外的分析，通过透视相关信息来获取更多见解。

然后，CISA可考虑进行内部和外部协调，根据共享的信息采取适当的防御行动。收集、匿名和丰富的指标可输入入侵检测系统，以保护联邦文职行政部门（FCEB）机构、州、地方、部落和领土（SLTT）实体以及关键基础设施资产。在某些情况下，可为联邦文职行政机构实施域块，以应对威胁。

如其 TLP级别所示，信息还可与行业、美国联邦政府、SLTT和国际合作伙伴共享，以支持网络防御目的。在共享信息的过程中，JCDC合作伙伴可能会获得并进一步分享更多的见解，从而在所有相关合作伙伴之间形成多向信息流。这种丰富的信息流可促成分析交流、公共网络安全咨询（与JCDC 合作伙伴协调）以及更广泛的跨部门合作，共同应对网络威胁。

加强协作

图 3：CISA信息共享与协作流程

加强协调涉及在常规操作无法完全解决或理解网络安全问题时加强信息共享和扩大合作。在这种情况下，CISA和 JCDC合作伙伴可选择实施额外机制并增加沟通频率，以改进事件响应和补救工作。这些活动都是自愿的，并根据情况按需启动。

CISA 对合作伙伴共享的信息进行评估，决定采取何种行动，并根据情况的变化调整加强协调的程度。CISA在很大程度上依赖于与JCDC 合作伙伴的合作，以评估哪些事件值得进一步分析并确定加强协调的优先次序。附录B 中详述的PyTorch 依赖链受损事件就是一个需要加强协调的活动实例。

信息共享有助于 CISA采取各种有针对性的行动来加强网络安全。这些行动可以单独执行，也可以合并执行，具体取决于已识别威胁或漏洞的性质。这一过程本身是动态的，涉及多个利益相关者之间的合作，通常是同时进行的。CISA采用灵活、综合的方法，根据不断变化的威胁情况调整应对措施，包括但不限于：

为检测和预防目的共享信息：在美国政府机构、私营部门、SLTT、关键基础设施和国际合作伙伴之间传播关键威胁情报，以加强集体网络安全工作。
揭露并瓦解对手的战术和基础设施：通过公共网络安全咨询、TLP：CLEAR 或 TLP：GREEN 报告或小组共享，揭露并潜在地降低对手使用的战术、技术和基础设施所带来的风险。
协调应对恶意基础设施的战略：与相关合作伙伴合作，识别网络攻击中使用的由对手控制的基础设施，并制定有效的缓解策略。
识别并通知受害实体：识别受网络事件影响或可能受网络事件影响的组织，并及时发出警报，以便迅速采取保护措施。
共享检测能力：为 JCDC 合作伙伴提供策略，以提高其识别和缓解自身网络中的网络威胁的能力。
制作和分发相关的威胁情报产品：创建可操作的产品，如威胁咨询和情报报告，其中包括分析、缓解建议和当前威胁状况的更新。
提供主动服务和参与：主动与合作伙伴接触，提供量身定制的建议、漏洞管理策略和最佳实践，以便在事件发生前加强防御。
通过响应式参与评估不断变化的威胁：促进实时响应参与，如电话和协调会议，以帮助合作伙伴更好地了解威胁环境，并确定适当的下一步措施。这有助于确保合作伙伴了解预期的行动以及如何有效应对。

作为加强协调的一部分，JCDC与联邦政府合作伙伴密切合作，对重大人工智能网络安全问题做出统一回应。通过这种合作，联邦政府的能力得到了统一，确保在应对重大威胁或漏洞时考虑到所有可用资源和专业知识。与联邦政府合作伙伴协调有助于确保CISA 和 JCDC采取的行动与更广泛的政府工作相辅相成，从而加强事件响应和补救战略的整体有效性。

行动呼吁

JCDC人工智能网络安全合作手册为人工智能社区（包括人工智能提供商、开发商和采用者）自愿共享信息提供了重要指导，以加强集体防御，应对不断变化的网络威胁。随着人工智能应用的加速，人工智能系统的威胁范围不断扩大，带来了新的漏洞和安全挑战。本手册将定期更新，通过政府、行业和国际合作伙伴之间的积极合作来应对这些挑战。

JCDC 合作伙伴应将该手册纳入其事件响应和信息共享流程，根据需要进行迭代改进，并提供反馈。请参阅 “问题与反馈 ”部分的说明。通过持续的合作和实际应用，这种持续的投入可加强和调整该手册。

为加强合作与参与，JCDC邀请人工智能安全专家和利益相关者考虑采取以下行动：

标记技术交流机会： JCDC 合作伙伴应确定并分享与影响人工智能界的新兴威胁、对手或漏洞相关的技术交流机会。这些交流可提供重要的见解，使 JCDC 和 CISA 能够积极应对共同的风险。
确定人工智能界的优先问题：突出关键问题和风险有助于确保 JCDC 的优先事项与人工智能界确定的最紧迫挑战保持一致。这种一致性有助于更有针对性、更有效地满足关键的人工智能安全需求。
促进事后分析和知识共享：在社区内开发和共享事后分析、案例研究和教育内容，可促进积极主动地应对人工智能安全挑战。分享经验教训可加强集体应变能力，提高应对未来事件的准备程度。
成为 JCDC 合作伙伴：加入由来自全球各组织的网络防御者组成的多元化团队，该团队致力于主动收集、分析和共享可操作的网络风险信息，以实现同步的网络安全规划、网络防御和响应。要了解有关 JCDC 的更多信息，请访问 CISA 的 JCDC 网页并发送电子邮件至 [email protected]。

通过人工智能社区的积极参与，该手册将成为应对未来人工智能安全形势的动态资源。随着关键基础设施所有者和运营商越来越多地使用人工智能工具，业务合作在加强网络安全和推进人工智能技术的安全应用方面发挥着至关重要的作用。

附录A：信息处理限制和自愿信息共享核对表填充示例

以下是基于 2023年 1 月提交给MITRE ATLAS 的真实案例研究 “通过提示注入在 MathGPT 中执行代码 ”的自愿信息共享核对表填写示例。该事件涉及一名行为者利用提示注入漏洞访问应用程序主机系统的环境变量和GPT-3 API 密钥。利用这一访问权限，该行为者对MathGPT 执行了拒绝服务（DoS）攻击，MathGPT是一个采用 GPT-3语言模型回答用户生成的数学问题的公共应用程序。该攻击还可能耗尽应用程序的API 查询预算或完全中断其运行。

尽管 MathGPT团队后来已经缓解了此次事件中发现的漏洞，但本案例研究仍被用于填充自愿信息共享清单。本示例以MathGPT 开发人员在检测到攻击后不久对攻击做出响应的视角编写，就像事件仍在活动一样。

附录B：主动共享信息和加强协调的案例研究

主动信息共享实例：Clearview 人工智能配置错误案例研究

为了说明现实世界中的威胁行为者在日常操作中可能会使用哪些方法来利用人工智能系统，以及这些技术与传统的网络入侵有何不同，我们研究了MITRE ATLAS 关于Clearview AI 配置错误的案例研究。

Clearview AI 开发了一种面部识别工具，可在公开照片数据库（如Facebook、谷歌和YouTube）中搜索匹配的照片。该工具已被执法机构和其他实体用于调查目的。

然而，Clearview AI 的源代码库虽然有密码保护，但配置不当，允许任意用户创建账户。这一漏洞使外部研究人员能够访问包含Clearview AI 生产凭证、云存储桶密钥（包含70K 视频样本）、应用程序副本和Slack 标记的私有代码库。

通过访问这些训练数据和凭证，恶意行为者可以破坏未来的应用程序版本，导致部署模型中的面部识别功能降低或被恶意破坏。这一案例突出表明，需要以超越传统网络安全措施的方式确保人工智能系统的安全。此类系统不仅需要稳健的卫生措施，如强制执行最小权限访问、多因素身份验证以及严格的监控和审计，还需要针对人工智能技术带来的独特风险量身定制特定的保障措施。

在本案例中，安全研究人员通过对抗性方法展示了Clearview AI 系统中的漏洞，详情如下：

策略：资源开发

o技巧：建立账户

一名安全研究人员通过错误配置的服务器设置初步访问了Clearview AI 的私有代码库，该设置允许任意用户注册有效账户。

战术：收集

o技术：从信息库获取数据

私人代码库包含用于访问AWS S3 云存储桶的凭据，从而发现了面部识别工具的资产，包括

o已发布的桌面和移动应用程序。

o具有新功能的预发布应用程序。

o Slack 访问令牌。

o原始视频和其他数据

策略：资源开发

o技术：获取公共 ML人工制品

对手可以下载训练数据，并从源代码和反编译应用程序二进制文件中收集有关软件、模型和功能的详细信息。

战术：影响

o技术：侵蚀 ML模型完整性

由于访问了这些信息，敌方可能通过降低或恶意操纵面部识别能力来破坏未来发布的应用程序。

增强协作示例：受损的PyTorch 依赖链

为了说明在非例行或临时信息共享不足的情况下，增强协调情景下可能发生的过程，我们研究了MITRE ATLAS 的另一个案例研究：“PyTorch依赖链受损”。

在此案例中，一伙身份不明的恶意行为者通过破坏与PyTorch 预发布版本相关的Linux 软件包，实施了一次供应链攻击。15他们将恶意二进制文件上传到代码库，该二进制文件与合法的PyTorch 依赖程序同名。结果，PyPI软件包管理器（pip）无意中安装了恶意软件包，而不是正版软件包。这种被称为 “依赖关系混淆 ”的技术暴露了使用受影响的 pip安装版本软件包的 Linux机器上的敏感信息。

攻击通过以下步骤展开，详情如下：

战术：初始访问

o 技术： ML供应链破坏 – ML 软件

一个名为 torchtriton的恶意依赖包被上传到PyPI 代码库，其软件包名称与以PyTorch-nightly命名的软件包相同。行为者利用系统中现有的优先级规则，诱骗用户下载恶意软件包，而不是合法软件包。恶意软件包包含附加代码，可上传从安装该软件包的机器上获取的敏感数据。

战术：收集

o技术：从本地系统获取数据

恶意软件包调查受影响系统，以获取IP 地址和用户名等基本指纹信息以及其他敏感数据。

战术：渗透

o技术：通过网络手段渗透

所有收集到的信息（包括文件内容）都通过加密域名系统查询上传到外部网域。

MITRE ATLAS 网站上有一份完整的TTPs 演变清单，威胁者可能会使用这些TTPs 来攻击人工智能系统，这些TTPs 是由人工智能安全社区共享的真实世界攻击和现实红队演习提供的。

附录C：自愿共享信息的其他途径

遭遇人工智能网络安全事件的组织可通过多种自愿渠道向联邦政府通报事件，以请求技术援助、报告犯罪或参与业务合作。人工智能社区还开发和部署了更多自愿共享信息的非正式机制，以促进社区对前沿人工智能事件的认识和讨论。除了本手册中描述的联系CISA 的方法外，各组织还应考虑以下选项。

附录D：其他资源

以下文件提供了组织可参考的其他信息资源，以了解人工智能系统的网络安全。

往
期回顾

【国际视野】卡巴斯基：EAGERBEE后门变种瞄准中东

【国际视野】美国进出口银行监察长办公室：机构未妥善保护个人身份信息，存在泄露风险

【国际视野】美国国家科学技术委员会发布《数据基础设施互联互通的框架》建议报告

【国际视野】欧盟发布《2024 年欧盟网络安全状况报告》

“

天极按

近日，美国国家标准与技术研究院 (NIST) 发布了一份白皮书，其中建立了一个衡量标准，用于确定产品漏洞是否已被利用。NIST 表，其网络安全白皮书（CWSP）第 41 版描述了“可能被利用漏洞”（LEV）的计算方法，以及各组织机构如何利用它来指导其优先级排序工作。

1.介绍

这项工作提供了一种新颖的安全度量方法，用于确定观察到的漏洞被利用的可能性。在每年公布的数以万计的软件和硬件漏洞中，只有一小部分会被利用。预测哪些漏洞对企业漏洞修复工作的效率和成本效益非常重要。

一项研究表明，只有
5%
的漏洞被在野利用，而公司每月的漏洞修复率为
16%
。修复率如此之低，是因为公司处理漏洞的成本很高。安全补丁必须与企业软件一起测试，以确保运营的连续性；有些漏洞需要非补丁修复，需要人工部署。

如果
16%
能覆盖
5%
，那么这种情况就不是问题，但缺乏精确计算的计量方法。因此，预测哪些漏洞会被利用，对于企业漏洞修复工作的效率和成本效益至关重要。

漏洞利用预测评分系统（
EPSS
）就是在实现这一目标方面取得重大进展的努力之一。
EPSS
提供在未来
30
天内观察到漏洞在野外被利用的概率。然而，众所周知，该系统对以前观察到被利用的漏洞的概率并不准确；这一点在
EPSS
文档中已有说明。幸运的是，概率并非随机不准确，而是低估了真实概率。

另一个对确定漏洞修复优先级至关重要的领域是已知漏洞（
KEV
）列表。
KEV
列表列举了过去已被明确利用的漏洞（如和）。然而，这类列表可能并不全面，而且在这项研究之前，还没有测量其覆盖范围的计量方法。

这项工作提供了测量过去观察到的漏洞被利用概率的方程。这些漏洞概率列表被命名为 “可能被利用的漏洞（
LEV
）列表”。这个名称强调了这些列表的概率性质，并将它们与
KEV
列表（它们不能取代
KEV
列表）区分开来。

LEV
概率至少有四种用途：

1.衡量行为者已利用的由通用漏洞和暴露（CVE）标识符确定的漏洞的预期数量和比例；

估算 KEV列表的全面性；
通过识别可能遗漏的高概率漏洞，加强基于KEV 的漏洞修复优先级排序，以及；
通过识别可能被强调的漏洞，加强基于EPSS 的漏洞修复优先级排序。

LEV
的准确性取决于
EPSS
的性能，因为
LEV
是根据
EPSS
的历史得分计算得出的。
EPSS
已公布的测试结果表明，最新版本在召回率（即覆盖率）和精确率（即效率）方面表现出色，见第
9
节。随着
EPSS
性能的不断提高（三个版本的
EPSS
性能都有显著提高），
LEV
性能也会随之提高。

尽管
LEV
指标的推导在数学上是合理的，但它不可避免地存在误差，而这一误差目前还不得而知。目前还没有公开的漏洞利用数据，但这对于彻底测试
LEV
指标的性能是必要的。

EPSS
性能结果的形式无法直接计算
LEV
性能。因此，尽管
LEV
的性能因其基础
EPSS
数据的质量而被推定为很高，但
LEV
概率本身的性能结果目前还不可用。美国国家标准与技术研究院（
NIST
）正在寻求拥有相关数据集的行业合作伙伴，以便对
LEV
概率的性能进行实证测量。

本研究的其余部分安排如下。第
2
节介绍了漏洞枚举、
EPSS
和
KEV
列表的背景。第
3
节讨论
LEV
概率用例。第
4
节介绍
LEV
方程。第
5
节推导等式。第
6
节提供
LEV
输出示例。第
7
节介绍实证结果。第
8
节讨论
KEV
列表的全面性测量和可能的误差来源。第
9
节介绍性能。第
10
节讨论
LEV
的实现，第
11
节为结论。

2.背景介绍

本节包含理解
LEV
方程和方法所需的背景。它介绍了漏洞枚举列表、
EPSS
评分，并讨论了
KEV
列表。

2.1 常见漏洞与暴露

常见漏洞与暴露（
CVE
）是对信息技术产品（主要是软件，也包括硬件）中已知漏洞的列举。它被广泛认为是目前最全面的清单，在信息技术安全界被广泛使用。美国国家漏洞数据库（
NVD
）提供了所有
CVE
的信息和参考资料。

2.2 漏洞预测评分系统

EPSS
为每个
CVE
提供每日更新的得分。这些分数是每个
CVE
在未来
30
天内被观察到在野被利用的估计概率。截至
2025
年
1
月，已有
111
种安全产品采用了
EPSS
分数，由此可见，
EPSS
分数已被安全行业广泛接受。不过，安全专家们对使用它的利弊进行了辩论。

这些分数是通过使用几千个输入进行训练的机器学习模型得出的。训练数据由少数企业安全监控公司提供，每家公司都部署了一个大型传感器网络，为其企业客户观察漏洞利用活动。

第
5.1
节将详细讨论
EPSS
的设计初衷，即不将过去的漏洞利用行为作为模型的输入。这使得模型对过去的漏洞利用视而不见，导致对以前被利用过的漏洞的评分（即概率）不准确。分数会过低。在
30
天内被利用的漏洞不会在随后的
30
天内提高
EPSS
分数。这并不是错误，因为它可以使模型具有预测性，并对以前未被利用的漏洞得出更准确的结果。

EPSS
第
1
版于
2021-4-14
年首次发布；
2022-2-04
年更新为第
2
版。更精确的第
3
版于
2023-3-07
发布。

2.3 已知漏洞列表

已知已被利用漏洞列表（
KEV
）列出了过去曾被利用的已知漏洞。通常情况下，漏洞一旦被添加到
KEV
列表中，就会永久保留在列表中。不在名单上的漏洞，相对于过去被利用的情况是未知的。

一个著名的
KEV
列表来自美国网络安全和基础设施安全局（
CISA
）。要将漏洞列入该列表，该漏洞必须具有
CVE
标识符，与美国政府或关键基础设施使用的
IT
系统相关，并有可用的补救措施（如补丁或变通方法）。根据具有约束力的操作指令（
BOD
）
22-01 “
降低已知漏洞暴露的重大风险”，政府机构必须在规定时间内（通常在两周内）修复这些漏洞。

2024
年
12
月，
CISA KEV
清单上有
1228
个漏洞。与此同时，
CVE
列表上有
260k
个漏洞。因此，
CISA KEV
列表对
CVE
的覆盖率为
0.5%
。这低于之前引用的
5%
的漏洞已被利用的统计数字，但由于
CISA KEV
的范围有限（即其重点是美国政府系统和关键基础设施），预计
CVE
的总体覆盖率会降低。

3.目的与用途

第
4.1
节中描述的
LEV
方程为每个
CVE
提供了一个每日更新的概率，以及该
CVE
在过去某个时间被观察到在野被利用的可能性。这些结果可用来衡量已被利用的
CVE
的预期比例和
KEV
列表的全面性。这些结果还可以增强基于
KEV
和基于
EPSS
的漏洞修复优先级排序。

3.1 测量被利用CVE 的预期比例

一个重要的衡量标准是了解已观察到被利用的
CVE
数量和比例。使用下面的
Expected_Exploited()
公式可以确定其下限，该公式使用了第
4.1
节中提供的
LEV
公式。它提供了在特定日期观察到被利用的
CVE
的预期数量。接下来的
Expected_Exploited_Proportion()
等式提供了已观察到被利用的
CVE
的比例。

Expected_Exploited()
等式是衡量已被利用（而不是 “观察到 ”被利用）的
CVE
数量的一个替代指标。然而，这一指标无法直接计算，因为我们无法测量我们无法看到的东西，也因为这是
EPSS
所使用的公式，而
LEV
正是基于这一公式。

表
1. Expected_Exploited()
等式的变量

3.2 衡量KEV列表的全面性

LEV
概率可以衡量
KEV
列表的全面性。在此之前，
KEV
维护者没有衡量标准来证明他们的列表有多接近于包含所有相关漏洞。

KEV_Exploited()
等式为
KEV
列表应包含的漏洞数量提供了一个下限。为了计算出正确的测量值，必须使用
KEV
列表范围内的
CVE
。

表
2. Expected_Exploited()
等式的变量

3.3 增强基于KEV 的修复优先级排序

KEV
列表可通过
LEV
列表进行扩充。
LEV
列表是通过选择一个阈值概率，然后将
LEV
概率大于阈值的所有漏洞纳入其中来创建的。
LEV
列表可以识别
KEV
列表中可能遗漏的高概率漏洞。这对验证
KEV
列表的全面性非常重要（见第
8
章）。

一种方法是调查高于
LEV
列表阈值的漏洞，以便将其纳入
KEV
列表。我们通过
LEV
发现，许多漏洞都是低概率的（见第
8
章），因此执行这种
KEV
验证的工作量相对较小。

另一种方法是将高于所选阈值的漏洞特别区分为可能的候选漏洞。然后将这些漏洞与
KEV
列表中的漏洞（可能优先级较低）一起纳入修复活动中。同样，这样做的工作量也会相对较小，因为绝大多数漏洞都是低概率的。

如果没有与组织系统相关的
KEV
列表（例如，由于成本限制或许可问题），可以使用
LEV
列表作为非全面
KEV
列表。这样的清单只关注数量较少、可能性较大的漏洞。鉴于大多数漏洞的可能性极低，
LEV
列表使用的阈值即使低至
20%
，也能产生可控的漏洞数量，并将修复工作重点放在这些漏洞上。需要强调的是，这样使用
LEV
虽然有帮助，但不会产生全面的
KEV
清单。使用
LEV
列表并不能取代
KEV
列表。

3.4 增强基于EPSS 的修复优先级排序

EPSS
被组织用于确定漏洞修复的优先级，以及补丁测试和应用。目标是修复在未来
30
天内最有可能被利用的漏洞。一种方法是指定一个概率阈值，并修复所有高于该阈值的漏洞（从最有可能的漏洞开始）。

然而，正如第
2.2
节所讨论的，以及第
5.1
节中更详尽的内容，
EPSS
为以前被利用的漏洞提供的分数是不准确的。目前也无法修复
EPSS
中不准确的分数。因此，在确定企业漏洞修复的优先级时，不应单独使用
EPSS
。

如果将目标改为包括修复以前被利用的漏洞，并提供一个全面的
KEV
列表，就可以得到一个在数学上站得住脚的解决方案。为此，可将
KEV
列表中所有漏洞的
EPSS
分数改为
1.0
。全面的
KEV
列表将涵盖所有不准确的
EPSS
分数，覆盖错误，并产生可辩护的结果（尽管目标有所扩大）。

遗憾的是，
KEV
列表可能并不全面，因此这种方法不能保证覆盖所有错误的
EPSS
分数。不过，有了扩展目标，每个
EPSS
分数也可以重新分配为
LEV
和修订后的带
KEV EPSS
概率的最大值。这既包括漏洞以前被利用的几率（在某些情况下，
KEV
列表中的漏洞几率为
1.0
），也包括漏洞将被利用的几率。

增加
LEV
概率是一种实用的解决方案，可以覆盖剩余的不准确
EPSS
分数。它并不能保证消除所有
EPSS
错误（只有全面的
KEV
列表才能做到这一点，而这是可以用
LEV
来衡量的属性）。

下面的
Composite_Probability()
公式正式说明了这种方法。

表
3. Composite_Probability()
等式的变量和函数

3.等式

LEV
等式测量的是过去观察到的漏洞被利用的概率。本节介绍
LEV
方程的两种变体：
LEV
和
LEV2
。

4.1 LEV 方程

第一个等式
LEV
需要较少的计算资源，包括内存和
CPU
。它按照设计使用
EPSS
分数作为
30
天窗口的预测因子。它比
LEV2
稍为复杂。
LEV
是本文实验和讨论中使用的方程。

表
4. LEV
和
LEV2
方程的变量和函数

4.2 LEV2 方程

LEV2
等式需要更多的计算资源。它通过将
EPSS
分数除以
30
（而不是每个分数覆盖
30
天的窗口）来处理仅覆盖一天的
EPSS
分数。这使得该方程在计算中能够包含更多的
EPSS
分数，并提高了方程对分数变化的响应速度（尤其是对新发布的漏洞）。比较
LEV
和
LEV2
的有效性和特性是今后的工作重点。

虽然
LEV2
的计算资源比
LEV
更多，但每天在几小时内对所有漏洞进行
LEV2
测量，对于一台普通的现代笔记本电脑来说，完全可以做到。
LEV2
的计算挑战在于对内存和磁盘速度以及处理能力的要求。目前有近
30
万个漏洞，
EPSS
每天都会发布所有漏洞的
EPSS
分数文件。因此，计算所有漏洞的
LEV
概率需要使用来自上千个
EPSS
文件的数据。即使是一次
LEV2
计算，也可能需要所有
EPSS
分数文件中的
EPSS
分数（每天一个）。将所有
EPSS
数据缓存在内存中，以便更快地计算所有
CVE
，这需要超过
16 GB
的内存（现代计算机肯定能做到）。然而，即使有足够的内存，
LEV2
的计算时间也要比
LEV
长
30
倍，这是因为使用的窗口大小是
1
而不是
30
（在商用笔记本电脑上计算所有
CVE
的时间约为数小时）。

LEV2
方程使用与
LEV
方程相同的变量和函数（见表
1
）。

5.方程
推导

本节讨论
LEV
方程的推导过程。首先讨论
EPSS
分数对以前被利用的漏洞是不准确的。然后讨论
EPSS
对以前被利用的漏洞的概率如何仍然有用；它们是下限。然后，本节从教科书上的条件概率方程出发，推导出
LEV
方程，并将其应用于计算漏洞过去被利用的概率问题。

5.1 作为威胁前情报的EPSS 分数

EPSS
常见问题（
FAQs
）指出，
EPSS
分数 “应被视为威胁前情报”。附录
A
完整引用了
EPSS
常见问题的答案。它说，当没有威胁情报表明漏洞正在被利用时，应使用
EPSS
得分。
EPSS
常见问题解答中有一个问题
“
每个人都知道这个漏洞已被利用，为什么
EPSS
不给它打
100%
的分？
EPSS
并不总是对已知被利用的漏洞进行
100%
的评分，即使维护者知道该漏洞目前正在被利用。

这并不是
EPSS
设计中的错误或缺陷；文档指出，这是创建预测性机器学习模型的必要条件。
EPSS
维护者在训练
EPSS
模型时确实使用了观察到漏洞被利用的时间。但是，他们并没有将这些知识作为模型的输入。这些数据只是用来训练概率输出。

维护者发现，将脆弱性观测知识作为输入添加到模型中会降低模型的预测性。这样，模型就会过多地考虑过去的观察结果，而不是未来的观察指标。这就训练了模型，使其专注于一个不同但有用的目标（
LEV
目标），即识别过去的利用而不是未来的利用。

文件指出“如果没有开发证据，则可使用
EPSS
估算其被开发的概率”。文件还指出，如果有证据表明存在漏洞利用，则不应使用
EPSS
： “如果有证据表明某个漏洞正在被利用，则该信息应优先于
EPSS
所提供的任何信息
“
。

5.2 EPSS 分数作为下限

尽管
EPSS
得分假定过去未观察到漏洞被利用，但当这一假定不正确时会发生什么呢？在这种情况下，与未观察到漏洞被利用相比，该漏洞未来被利用的概率（
EPSS
得分）会增加。过去的漏洞利用观察结果会鼓励未来的漏洞利用观察结果。这有五个原因：

过去的观察结果显示了攻击者利用漏洞的效用。如果漏洞对他们没用，他们就不会利用漏洞。
过去的观察结果表明攻击者有能力成功地将漏洞武器化。
过去的观察结果表明，攻击者有能力在真实环境中到达漏洞的攻击面。
过去的观察结果表明，安全系统有能力检测到利用该漏洞进行的攻击。

5.过去的观察结果为继续利用该漏洞提供了动力。为什么一个有用的漏洞利用工具一旦被构建和使用，攻击者就会突然停止使用呢？随着时间的推移，对于一个特定的漏洞来说，漏洞利用概率最终会随着漏洞的老化和不适用性的增加而降低。但是，这种效应对于从未被利用的漏洞也是一样的。

因此，
EPSS
分数是下限。

5.3 作为条件概率的EPSS 得分

条件概率，写作
P(B|A)
，是一个函数
P
，计算事件
A
发生后事件
B
发生的概率。虽然不是很明显，但
LEV
方程使用了条件概率和相关的教科书公式：

将此应用于
LEV
问题：

让 P 计算在一系列连续的时间窗口（代表一个不间断的时间段）中没有观察到特定漏洞被利用的概率。除最后一个窗口外，其他窗口的长度均为30 天。最后一个窗口的长度为1 至30 天。
让 B 代表在最后一个窗口内未观察到漏洞被利用的事件。
让 A 代表在之前所有时间窗口内都未观察到漏洞被利用的事件。A 的开始时间总是该漏洞首次获得 EPSS 得分之日的00:00。
请注意，窗口的 EPSS 得分是窗口第一天的得分（因为EPSS 得分是用来表示30 天的窗口）。本推导使用函数EPSS(W) 表示窗口 W第一天的EPSS 得分。

条件概率方程可以重写，以明确显示窗口。

t 是窗口数（最少2个窗口）
1..t 表示从窗口W1 开始到窗口 Wt 结束的一个连续时间段。
W1..t
是公式1 中的(A ∩ B)。
W1..t-1
是公式1 中的A。
Wt
是公式1 中的B。

考虑方程
2
中的
P(W1..t-1
)
项。应用公式
1
可以简化它
P(A ∩ B)
由
P(W1..t-1
)
表示。

方程
3
中的
P(W1…t-2
)
项可以通过方程
1
的另一次迭代以同样的方式进一步简化（在方程
1
的第三次迭代中，
P(A∩B)
由
P(W1..t-2
)
表示）。

这种项扩展方法可以反复应用，不断扩展等式
1
中的
P(A)
项，直到只剩下一个窗口。此时，单个
30
天窗口的概率为
1
减去
EPSS
分数（因为事件是没有观察到漏洞被利用），如等式
5
所示。这也是
t=1
时
P(W1…t
)
的结果（需要注意的是，本推导假设
t>1
）。

公式
2
简化为：

如果在前一个窗口中没有观察到漏洞被利用，则公式
6
中的
P(W𝑖𝑖|W1..i-1
)
项可简化为
1 – EPSS(Wi
)
。第
5.1
节关于
EPSS
作为威胁前情报的讨论使这一假设成为合理。然而，第
5.2
节讨论了
EPSS
分数是如何成为下界的（尽管将它们视为等值也是合理的）。当简化
P(W𝑖𝑖|W1…i-1
)
为
1 – EPSS(Wi
)
时，等式的比较运算符由
=
变为
<=
。等式
7
显示了这一替换

注意方程
6
中的第一项是如何移入方程
7
中的乘积运算符中的。不过，还有一个问题没有解决。如果最后一个窗口不足
30
天怎么办？为了解决这个问题，
EPSS
分数按其覆盖时间（从
1
到
30
天）的比例进行计算。这就将公式
7
修改如下：

最后，
LEV
计算
P
的补码。
LEV
用于观测到漏洞被利用的情况。
P
是计算未观察到漏洞被利用的概率的函数。

由于减去了
1-P(W1…t
)
，不等式从
<=
变成了

=
。将其展开可得到以下结果。

这就是
LEV
方程的推导过程。

第
4.1
节中的
LEV
方程略有不同，因为它更正式一些。它将正在计算的漏洞和
LEV
计算所需的日期作为输入。它使用
weight()
函数表示窗口大小
i/30
。它还使用
dates()
函数明确计算每个窗口第一天的
EPSS
分数。在公式
10
中，计算窗口
EPSS
得分的
EPSS()
函数被第
4.1
节中计算特定日期特定漏洞的小写
EPSS()
函数所取代。

6.输出示例

LEV
实现每天输出每个
CVE
的信息。这包括过去的总体利用概率，还包括额外的辅助数据，使人们能够了解漏洞在利用概率方面的历史。

对于每个
CVE
，将提供以下数据字段：

1.CVE名称

2.发布日期

3.描述

4.LEV概率（过去观察到漏洞被利用的概率）

5.在评估的30 天窗口中EPSS 分数的峰值（即最大值

6.最高EPSS 分数的日期

7.每个30 天窗口的EPSS 分数

8.每个窗口的日期

使用通用平台枚举(CPE) 值的受影响产品

以下是
CVE-2023-1730
漏洞的输出示例，产生于
2024-12-12
。提供了上述每个数据字段。在
2023-05-02
首次发布漏洞后的几个月内，
EPSS
分数一直保持在
0.00
。它们在
2024-01-27
达到
0.16
的峰值，然后下降，徘徊在
0.05
左右。最后一次
EPSS
分数显示为
0.06
。然而，该日期（
2024-11-22
）的实际
EPSS
为
0.08
。之所以显示为
0.06
，是因为根据底部的说明，由于最后一个窗口只有
21
天（而
EPSS
是针对
30
天窗口的预测），因此需要对得分进行调整。虽然所有单个
EPSS
概率都小于或等于
0.16
，但
LEV
方程计算出的总体过去开发概率为
0.70
。

另一个例子是
CVE-2023-29373
，输出产生于
2025-1-22
。该漏洞的不同之处在于其
EPSS
概率历史最终降至
0.00
。由于最终窗口大小为
19
，因此即使不进行调整也是
0.00
。对于较老的漏洞来说，降到
0.00
是必要的，也是合理的，这样可以避免
LEV
概率最终上升到
1.0
。绝大多数
CVE
的
LEV
概率都很低，这表明
EPSS
最终将概率降至
0.00
是正常的。

EPSS
分数在这两个漏洞的整个生命周期中都会发生变化。它们都从
0
开始，上升一些，达到一个峰值，然后随着时间的推移而下降。这对
CVE
来说非常典型。概率通常会有一些轻微的波动，但通常不会出现大幅的上下波动。

7.经验结果

本节包含使用
LEV
方程得出的经验结果。介绍了
LEV
概率的分布情况。讨论了预计被利用的漏洞比例的经验数据。举例说明了
KEV
列表的全面性。还介绍了召回率的测量结果，表明
LEV
列表并不能取代
KEV
列表。

7.1 LEV 分布

图
1
提供了每年
LEV
概率的累积分布。

图
1. LEV
概率的累积分布（
2025
年
6
月
3
日）

较早年份的曲线向右倾斜，因为它们的
LEV
概率中包含了更多的
EPSS
得分，从而促进了
LEV
概率的增加。请注意，在
LEV
方程中，
EPSS
分数的增加只能增加过去漏洞被利用的总体概率。这是有道理的，因为每一天都有新的漏洞被利用的可能性。平均而言，旧漏洞被利用的可能性更大。

图
2
和图
3
显示了使用分选方法得出的
LEV
总体概率分布。

图
2.
采用分选法的
LEV
分布

图
3.
采用分选法的
LEV
分布（不包括小于
0.03
的分区）

图
2
提供了完整的分布，而图
3
则重点剔除了
0.01
和
0.02
这两个人口最多的概率分区，以便更直观地观察分布的其余部分。从图
3
中更容易看到几百个概率接近
1.0
的漏洞。有趣的是，这些漏洞中有许多并不在经过测试的
KEV
列表中。

大多数漏洞的
LEV
概率非常低。这些漏洞数量众多，根据概率的数学定义，可以观察到大量低概率漏洞被利用。这就是
LEV
列表无法取代
KEV
列表的原因之一。
LEV
无法确定众多低概率漏洞中哪些会被利用，它只能帮助计算预计有多少漏洞会被利用。而
KEV
列表能准确识别出被利用的漏洞。

7.2 预计被利用的CVE 比例

第
3.1
节中的
Expected_Exploited()
等式可用来计算预计观察到被利用的
CVE
数量。将这一数字与
Expected_Exploited_Proportion()
公式中的
CVE
总数进行比较，以确定应观察到被利用的
CVE
比例。

在
2025-01-16
日，有
66125
个
CVE
漏洞获得
EPSS
第三版评分。使用
Expected_Exploited()
公式计算，预计有
1006
个
CVE
被观察到被利用。

造成这种情况的一个原因是，这项工作的数据集使用了较新的漏洞，因为它只包括那些有
EPSS
版本
3
分数的
CVE
的整个历史（自
2023-03-07
以来发布的
CVE
）。较新的漏洞被利用的时间较短，因此
LEV
概率较低。

用
EPSS
第
2
版和第
3
版覆盖的
CVE
（
2022-02-04
以来发布的
CVE
）重新进行实验，得出的比例为
4.7%
（与
[2]
的研究一致）。将
EPSS
版本
1
涵盖的
CVE
（自
2021-04-14
起发布的
CVE
）包括在内，得出的比例为
8.7%
。用所有
CVE
（有些可追溯到
1980
年）重新进行实验，得出的比例为
14.6%
。这表明随着时间的推移，漏洞利用的比例越来越高，但较早的数据包含较高的错误率。
EPSS
第
2
版的准确性低于第
3
版；第
1
版的准确性低于第
2
版。在
2021-04-14
（
EPSS
版本
1
开始日期）之前发布的漏洞缺少许多
EPSS
分数。

表
5.
预计在
2025-01-16
被利用的比例

这些被
LEV
识别为可能被利用的老漏洞仍然很重要。

根据假设，随着旧漏洞的加入，该比例将接近
1.0
。这是因为每增加一天，就会有一个新的漏洞被利用的机会；每一个新的
EPSS
得分只能推高
LEV
的概率。然而，这种情况并没有发生，因为
EPSS
显然正确地考虑到了许多旧
CVE
的不适用性，计算出它们的概率几乎为零。

7.3 KEV 列表的LEV 召回率

“召回率”
的统计测量适用于
LEV
，测量不同阈值的
LEV
列表对
KEV
列表的覆盖率。如前文第
3.3
节所述，
LEV
列表可通过选择阈值概率来创建，然后将
LEV
概率大于阈值的所有漏洞都包括在内。

图
4
提供了
LEV
列表相对于
KEV
列表覆盖率的召回测量结果。

图
4. LEV
和
CISA KEV
的召回率测量结果

即使阈值为
0.1
，
LEV
列表的覆盖率也不超过
60%
。这表明
LEV
列表不应取代
KEV
列表。这并不一定表明
LEV
存在缺陷。它表明存在大量低概率漏洞，而且由于数量众多，尽管概率很低，但许多漏洞实际上会被利用。

8.KEV列表全面性测量与潜在误差来源

如第
3.2
节所述，
LEV
结果可用于测量
KEV
列表的全面性；可测量已知被利用漏洞的预期数量下限。

LEV
并不总能用来确定
KEV
列表中缺少哪些漏洞。例如，第
7.1
节显示，绝大多数漏洞的
LEV
概率都很低；这些漏洞数量众多，有大量漏洞会被利用，但
LEV
概率无法区分它们。

当
LEV
漏洞较高时，
LEV
可用来识别缺失的漏洞。当特定产品漏洞（即
CVE ID
）的
LEV
等式（
10
）很高时，我们希望该
CVE ID
出现在
CISA KEV
列表中（见第
3.2
节）。如果一个漏洞的
LEV
值很高，但却不在
KEV
列表中，那么就存在某种不匹配的情况。我们通常使用
0.9999
作为 “高 ”
LEV
，但临界值只是
LEV
结果的置信度。使用低至
0.1
的临界值，可以产生实际数量的候选漏洞，以审查是否纳入
KEV
，因为大多数
CVE
的
LEV
都小于这个数值。

当一个漏洞的
LEV
概率很高（使用任何方便的 “高 ”阈值），而它又不在正在分析的
KEV
列表中时，我们可以考虑是哪种错误导致该漏洞不在
KEV
列表中。

错误的来源会改变我们识别错误和应对错误的方式。我们通过不同的过程识别每种错误；因此，识别错误是一个排除每种错误的反复过程。我们也会针对每种错误的漏洞采取不同的建议应对措施。因此，确定错误的类型对于了解错误是否会导致关键绩效值的变化、我们分析的变化、源数据的变化，或者仅仅是概率性质的结果非常重要。

本节讨论的错误来源如下：

KEV 范围选择：这些漏洞已被利用，但不在 KEV 范围内；这不是真正的错误，而是源数据与被利用漏洞列表之间的范围不匹配。
概率错误：LEV 公式 (10) 存在错误或无效假设。例如，由于(10) 公式在每次概率计算中都包含多个分数，如果公式错误地假定了独立性，则可能会放大微小的从属误差。
分析错误：LEV 值偏高，但实际上不应该偏高。错误发生在 LEV 计算之前的某处（即数据收集或分析过程中）。
KEV可见性错误：这些数据本应出现在 KEV 上，但却没有出现，因为列表所有者不了解开发情况
校准错误：EPSS 分数对漏洞的排序正确，但概率都偏高，导致 LEV 被高估。也就是说，漏洞的 LEV 值实际上不应该高于 “高 ”的分析阈值。
偶然性：虽然漏洞被正确利用的可能性很高，但实际上并没有被利用。

一般情况下，应按此处介绍的顺序排除错误。

8.1 KEV 策略选择

摘要：
漏洞已被利用，但不在KEV 范围内。

如何识别：
KEV列表可能有显式范围、隐式范围或两者兼有。例如，CISA KEV 规定其”目的是保护联邦信息和信息系统。我们根据截至2025 年2 月KEV 上所列漏洞的产品信息，确定CISA KEV 的隐含范围。如何应对：调整第 3.2节中定义的分析，排除此漏洞。结果并非真正的错误，而是源数据与漏洞列表之间的范围不匹配。或者，KEV列表维护者可以决定调整列表的范围。

8.2 概率错误

摘要：
LEV公式（10）有一些错误或无效假设。例如，由于(10)式在每次概率计算中都包含多个分数，如果方程错误地假定其独立性，则可能会放大微小的从属误差。

如何鉴定：
同行评审方程、方程的表述以及每个数学步骤的理由。理想情况下，咨询几位具有不同专业领域的同行专家，以涵盖不同类型的形式主义错误。

如何应对：
调整方程，以考虑形式规范中发现的任何问题。重新运行分析，看看漏洞的LEV 值是否仍然很高。

8.3 分析错误

摘要：
LEV值很高，但实际上不应该很高。错误发生在LEV 计算之前的某处（即数据收集或分析中）。

如何识别：
EPSS 特别兴趣小组(SIG)提供了数据收集和分析中可能出现的错误类型的透明度（见https://www.first.org/epss/faq和https://www.first.org/epss/model）。例如，源EPSS 数据基于利用活动，其定义为”是企图利用漏洞的证据，而不是针对易受攻击目标成功利用漏洞的证据。如果漏洞的LEV很高，因为许多扫描程序都在试图利用它，但所有范围内的系统都已加固或打了补丁，那么就会有利用活动，但没有实际的主动利用。要确定一个漏洞是否属于这种介于利用活动和实际主动利用之间的空间，需要专家对有关漏洞的已知信息进行审查。

如何应对：
不应该将该漏洞添加到KEV 中，尽管它有可能被利用。

8.4 KEV 可见性错误

摘要：
这些内容本应出现在 KEV上，但却没有出现，因为列表所有者不知道开发行为。

如何识别：
搜索利用证据。搜索可能包括指导事件响应者确定漏洞利用在不同类型的日志（系统日志、网络入侵检测系统、主机入侵检测系统等）中的可见性，以及与供应商、安全公司和社区核实他们是否有类似的证据。如果发现利用证据，则该错误为KEV 可见性错误。

如何应对：
将 CVE 添加到KEV 列表中。

8.5 校准错误

摘要：
EPSS分数对漏洞的排序是正确的，但概率都偏移得太高，导致LEV 被高估。也就是说，漏洞的LEV 值实际上不应该高于 “高 ”的分析阈值。

如何识别：
已排除前四种错误来源，但 LEV值偏高的漏洞数量远大于基于偶然性的预期。例如，如果LEV 临界值为0.9999，但分析的漏洞中，LEV高但没有其他已知错误的漏洞远远超过0.0001。

如何应对：
在 LEV 分析的某一阶段，调整EPSS分数，将其全部下调，下调比例与确定的超额脆弱性数量相关。

8.6 机会

概要：
虽然漏洞被正确利用的可能性很高，但实际上并没有被利用。

如何识别：
已排除所有其他错误来源。

如何应对：
不要将漏洞添加到KEV 列表中。不调整LEV计算或分析管道。一切都在按预期运行，这个结果就是使用概率的结果。

9.性能

LEV
性能基于
EPSS
性能，因为
LEV
是使用
EPSS
分数计算的。下面提供的数据显示，
EPSS
第三版在召回率和精确度方面表现优异。虽然这表明
LEV
性能也应该很高，但不可能使用这些数据来宣称
LEV
性能。

NIST
正在寻求行业合作伙伴，对
LEV
概率进行实证测试。为此，需要由一组
CVE
和关于每个
CVE
首次被观察到利用的时间（如果有的话）的数据组成的数据集。由于实际上只有
5%
的
CVE
被利用
[2]
，因此数据集必须包含许多从未被观察到被利用的
CVE
（理想情况下是这个比例）。

如
[4]
图
1
所示，版本
3
的
EPSS
性能远高于版本
1
和版本
2
。因此，本文的实证工作仅限于使用
EPSS
版本
3
的分数（
2023-3-07
之后发布的
CVE
）。

图
5. EPSS
性能，复制自
[4]
的图表

在图
5
中，最上面的红线代表
EPSS v3
，标注的点代表
EPSS
分数至少达到该点数值的
CVE
集。
X
轴（召回率）显示了与
30
天内观察到被利用的
CVE
相比，这组
CVE
的覆盖率。
Y
轴（精确度）表示在
30
天内观察到被利用的
CVE
集的比例。

10.实施与可用性

LEV
方程使用
Python
实现；在计算
LEV
概率之前，它会从多个资源下载数据：
NVD
、
CISA KEV
和
EPSS
。

10.1 NVD 下载

代码会下载
NVD
数据库，以检索完整的
CVE
列表、发布日期和描述。只有向
NIST
申请
NVD
应用程序编程接口
(API)
密钥，才能下载
NVD (https://nvd.nist.gov/developers/request-an-apikey)
。必须在源代码中输入
API
密钥用户名和密码才能下载
NVD
。第一次下载数据库可能需要几个小时；之后代码下载的只是更改和新增加的
CVE
。

10.2 CISA KEV 下载

CISA KEV
列表以小型
CSV
（逗号分隔值）文件形式下载。

10.3 EPSS 下载和数据

LEV
代码可使用
EPSS
自
2021
年启动以来的所有
EPSS
分数。然而，本工作中的
LEV
实证研究仅使用
EPSS
第
3
版，以利用该版本所提高的性能。因此，只有在
2023
年
3
月
7
日及之后发布的
CVE
才能获得完整的高质量
EPSS
数据。

LEV
代码可以使用自
EPSS
于
2021
年启动以来的所有
EPSS
分数。不过，本研究中的
LEV
实证研究仅使用
EPSS
第
3
版，以利用该版本的更高性能。因此，只有在
2023
年
3
月
7
日及之后发布的
CVE
才能获得完整的高质量
EPSS
数据。

甚至可以计算
EPSS
第一版之前发布的
CVE
的
LEV
概率。例如，可以计算
20
世纪
80
年代发布的
CVE
的
LEV
概率。代码将使用每个
CVE
可用的
EPSS
概率。由于
LEV
等式的性质，缺失的
EPSS
概率会降低
LEV
概率。由于
LEV
是一个大于或等于不等式，因此（由于
EPSS
数据缺失）降低的
LEV
概率仍然是正确的。只是它的下限比所有
EPSS
概率都可用时要小。

11.结论

这项工作描述了一种拟议的安全度量方法，用于确定观察到的漏洞被利用的可能性。

LEV
等式提供了在野观察到漏洞被利用的概率。这些概率可用来衡量被利用的
CVE
的预期比例。它们可以衡量
KEV
列表的全面性。它们还可以通过识别在
EPSS
中被强调或在
KEV
列表中缺失的高概率漏洞，加强使用
EPSS
和
/
或
KEV
列表确定修复优先级的工作。

这一点很重要，因为经验表明，相对于全部漏洞集而言，
KEV
列表并不全面。此外，
EPSS
在设计上对于以前观察到被利用的漏洞是不准确的。

所有这四种用例都非常重要，因为企业依靠
KEV
列表和
EPSS
分数来集中有限的资源，优先进行漏洞修复和补丁管理。

然而，必须强调的是，虽然
LEV
指标的推导在数学上是合理的，但它不可避免地存在误差，而这一误差目前尚不可知。目前还没有公开的漏洞利用数据，但这些数据对于彻底测试
LEV
指标的性能是必要的。

参考文献

[1] FIRST (2024) EPSS Frequently Asked Questions: Everyone knows this vulnerability has been exploited, why doesn’t EPSS score it at 100%? Available at https://www.first.org/epss/faq

[2] Jacobs J, Romanosky S, Adjerid I, Baker W (2020) Improving vulnerability remediation through better exploit prediction. Journal of Cybersecurity 6(1) (2020):1-12.https://doi.org/10.1093/cybsec/tyaa015

[3] Cyentia Institute, Kenna Security (2022) Prioritization to Prediction Volume 8: Measuring and Minimizing Exploitability. Available athttps://library.cyentia.com/report/report_008756.html

[4] Jacobs J, Romanosky S, Suciu O, Edwards B, Sarabi A (2023) Enhancing Vulnerability prioritization: Data-driven exploit predictions with community-driven insights. 2023 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW) (IEEE Computer Society, Delft, The Netherlands), pp 194-206.https://doi.ieeecomputersociety.org/10.1109/EuroSPW59978.2023.00027

[5] CISA (2024) Known Exploited Vulnerabilities Catalog. Available athttps://www.cisa.gov/known-exploited-vulnerabilities-catalog

[6] VulnCheck (2024) Exploit & Vulnerability Intelligence. Available athttps://vulncheck.com/product/exploit-intelligence

[7] MITRE (2024) CVE. Available at https://cve.mitre.org [8] NIST (2024) National Vulnerability Database. Available at https://nvd.nist.gov

[9] CISA (2021) BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities. Available at https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significantrisk-known-exploited-vulnerabilities [10] FIRST (2024) Who is using EPSS? Available at https://www.first.org/epss/who_is_using

[11] Spring J (2022) Probably Don’t Rely on EPSS Yet. Available athttps://insights.sei.cmu.edu/blog/probably-dont-rely-on-epss-yet

[12] Deploy Securely (2022) Why you probably should use the EPSS. Available athttps://blog.stackaware.com/p/why-you-probably-should-use-epss

[13] Tenable (2025) Documentation: Vulnerability Information. Available athttps://docs.tenable.com/vulnerability-management/Content/vulnerabilityintelligence/vulnerability-information.htm

[14] Romanosky S (2022) Exploit Prediction Scoring System: Changing our approach to vulnerability prioritization. Available at https://www.first.org/resources/papers/conf2023/FIRSTCON23-TLP-CLEAR-Romanoskyand-Jacobs-An-Introduction-to-EPSS.pdf

[15] NIST (2025) Official Common Platform Enumeration (CPE) Dictionary. Available at https://nvd.nist.gov/products

往
期回顾

【国际视野】美国国防部发布《25-26财年软件现代化实施计划》

【国际视野】欧盟发布《网络压力测试手册》

【国际视野】美国国家标准与技术研究院发布《网络安全与隐私计划2024 财年年度报告》

【国际视野】美国网络安全和基础设施安全局等多机构联合发布《减少OT网络威胁的措施》

END