第三章 漏洞数据库和评分方法

关于应用程序安全和漏洞管理的对话的一个关键方面是对漏洞进行分类和评分的方法。这是推动软件透明度的一个重要方面，更重要的是，软件安全。如果不了解存在哪些软件漏洞以及这些漏洞的评分方式，组织就很难确定漏洞的优先级以进行修复。软件生产商可以确定漏洞的优先级进行修复，以降低客户的风险，并告知客户其产品中漏洞的严重性和可利用性。软件消费者可以了解他们正在使用的软件的固有风险，并就其消费和使用做出风险知情决策。

• 3.1公共漏洞与暴露
• 3.2国家漏洞数据库
• 3.3软件标识格式
• 3.4 Sonatype OSS索引
• 3.5 开源漏洞数据库
• 3.6 全球安全数据库
• 3.7 公共漏洞评分系统
• 3.8 漏洞预测评分系统
• 3.9 EPSS模型
• 3.10 EPSS的批评意见
• 3.11 CISA的观点
• 3.12 行动意见
• 3.13 小结

3.1公共漏洞与暴露

“公共漏洞与暴露”（CVE）是一个项目，旨在识别、定义和编目公开披露的影响软件或硬件的网络安全漏洞。作为一个组织，CVE涉及国际研究人员和组织的参与，这些合作伙伴帮助发现和发布漏洞，并以标准化格式描述这些漏洞。CVE项目和概念的起源可以追溯到1999年1月由David Mann和Steven Christey撰写的一份MITRE白皮书，标题为“Towards a Common Enumeration of Vulnerabilities”（https://cve.mitre.org/docs/docs-2000/cerias.html）。这份白皮书描述了当时的网络安全格局，其中包括多个独立的漏洞数据库，它们具有独特的格式、标准和分类法。白皮书的作者解释了这如何影响互操作性和漏洞信息的共享。在互操作性的障碍中，他们提到了不一致的命名约定、管理来自不同来源的类似信息，以及数据库之间映射的复杂性。

为了促进安全软件工具之间的互操作性，提出了CVE作为一个标准化列表，帮助列举所有已知漏洞，分配标准的唯一名称，并且开放和共享没有限制。

这一努力在20多年的时间里已经成为行业的基石，来自35多个国家的200多个组织参与了这一项目，CVE系统收录了超过200,000个漏洞。参与组织被称为CVE编号授权机构（CNA；www.cve.org/PartnerInformation/ListofPartners）。CNA包括软件供应商、开源软件项目、漏洞赏金服务提供商和研究人员。它们被CVE项目授权，可以为漏洞分配唯一的CVE ID，并将CVE记录发布到CVE列表中。组织可以申请成为CNA，但必须满足特定要求，例如具有公开的漏洞披露政策、具有漏洞披露的公开来源，并同意CVE使用条款（www.cve.org/Legal/TermsOfUse）。

在第一章“软件供应链威胁的背景”中，我们讨论了国家漏洞数据库（NVD），尽管NVD和CVE之间有密切合作，但它们是不同的项目。CVE起源于MITRE，现在是一个由社区驱动的合作努力。而NVD由国家标准与技术研究所（NIST）发起。两个项目都由美国国土安全部和网络安全基础设施安全局（CISA）赞助，并免费供公众使用。CVE表现为一组漏洞记录，包括识别号码、描述和公开引用，而NVD是一个与CVE列表同步的数据库，以确保已披露的CVE和NVD记录之间的一致性。NVD提供了额外的信息，如修复方法、严重性评分和影响评级。NVD还通过高级元数据和字段使CVE可被搜索。

CVE由几个工作组组成，每个工作组都有不同的重点领域，包括自动化、战略规划、协调和质量。这些工作组致力于改进整个CVE项目并提升其对社区的价值和质量。除了工作组外，CVE还设有CVE项目委员会，以确保项目满足全球网络安全和技术社区的需求（www.cve.org/Resources/Roles/Board/General/Board-Charter.pdf）。该委员会负责监督项目，引导其战略方向，并在社区中推广。

一些与CVE项目相关的基本术语包括：

■ 漏洞
■ CVE标识符
■ 范围
■ CVE列表
■ CVE标识符
■ 范围CVE记录

CVE将漏洞定义为软件、固件或硬件中的缺陷，这些缺陷由于可以被利用而对受影响组件的机密性、完整性和可用性（CIA）三元组产生负面影响。CVE标识符（CVE ID）是由CVE项目分配给特定漏洞的唯一字母数字标识符，使得多个方可以自动化处理和共同讨论这些漏洞。范围是指CVE项目内的组织对特定硬件或软件集的独特责任。CVE列表是由CVE项目识别或报告的CVE记录的总目录。CVE记录提供与CVE ID相关的漏洞的描述性数据，由CNA提供。CVE记录可以是保留的、发布的或拒绝的。保留状态是指由CNA保留的初始状态，发布状态是指CNA填写数据后成为CVE记录的状态，拒绝状态是指CVE ID和记录不应再使用但仍在CVE列表中作为无效CVE记录的未来参考。

CVE记录也经历一个定义好的生命周期。这个生命周期包括发现、报告、请求、保留、提交和发布的阶段（见图3.1）。最初，某个组织发现一个新漏洞，向CVE项目或参与者报告，并请求一个CVE ID，该ID在保留期间由CVE项目参与者提交相关详细信息。最后，CVE记录被发布供公众下载和查看，以便在需要时开始适当的响应活动。

自CVE项目成立以来，CVE项目和CVE记录列表呈线性增长。根据发布的CVE记录统计数据（www.cve.org/About/Metrics），截至本文撰写时，每季度发布的CVE记录从几百个增长到超过6000个。这是由于项目的日益普及、安全研究人员的增加、软件供应商参与的增加以及网络安全的整体增长和可见性。

3.2国家漏洞数据库

漏洞有助于指导软件生产者和消费者降低风险，并为行业提供广泛的关于生态系统中存在的漏洞的知识。虽然行业中有多个漏洞数据库，但最著名的例子之一是NIST的国家漏洞数据库（NVD; https://nvd.nist.gov）。NVD是一个综合性的网络安全漏洞数据库，整合了所有公开的美国政府漏洞资源，并提供了对行业资源的引用。

NVD于2005年正式成立（https://nvd.nist.gov/general/brief-history）。NVD的起源可以追溯到1999年，其前身是互联网攻击工具分类（ICAT）。ICAT最初作为一个攻击脚本数据库开发，涉及SANS研究所的学生作为项目分析员。ICAT面临一些资金挑战，但在SANS以及NIST员工的努力下得以存续。在获得美国国土安全部（DHS）的一些额外资金后，ICAT发展到超过10,000个漏洞，最终被重新命名为NVD，成为如今的NVD。随着项目的发展，NVD采用了仍在使用的流行漏洞数据和评分系统，例如通用漏洞评分系统（CVSS）和通用平台枚举（CPE；https://nvd.nist.gov/products/cpe）。

截至本文撰写时，NVD包含超过200,000个漏洞，并且这个数字还在不断增长，因为新的漏洞不断出现。NVD被全球对漏洞数据感兴趣的专业人士以及希望关联漏洞发现及其详细信息的供应商所使用。

NVD通过分析已在CVE字典中发布的CVE来促进这一过程。通过参考CVE字典并进行额外分析，NVD的工作人员生成关于漏洞的重要元数据，包括CVSS评分、通用弱点枚举（CWE）类型和以CPE形式表示的适用性声明。值得注意的是，NVD工作人员不进行漏洞测试，而是利用供应商和第三方安全研究人员的见解和信息来创建这些属性。随着当前信息的出现，NVD经常修订元数据，例如CVSS评分和CWE信息。

NVD整合了来自CVE项目的信息，CVE项目是我们将在本章后面“CPE”部分讨论的漏洞字典。在NVD中集成新发布的CVE后，NVD通过严格的分析过程评估这些CVE，包括审查CVE的参考资料，这些参考资料涵盖了互联网上公开可用的信息。CVE被分配一个或多个CWE标识符，以帮助分类漏洞，并通过CVSS分配可利用性和影响指标。适用性声明通过CPE提供，以确保通过这些适用性声明识别特定版本的软件、硬件或系统。这有助于组织采取适当的行动，取决于漏洞是否影响他们正在使用的特定硬件和软件。一旦完成初步分析和评估，任何分配的元数据（如CWE、CVSS和CPE）都由高级分析师进行质量保证审核，然后发布在NVD网站和相关数据源上。

NVD提供丰富的数据源（https://nvd.nist.gov/vuln/data-feeds）和API（https://nvd.nist.gov/developers/start-here），供组织和个人获取已发布的漏洞数据。API允许相关方以更加自动化和可扩展的方式程序化地获取漏洞信息，而不是手动查看数据源。NVD API经常更新且可搜索，包括其他好处，如数据匹配，并且通常被安全产品供应商用来作为其产品提供的一部分，提供漏洞数据。

3.3软件标识格式

推动软件供应链安全性和软件透明度的一个基本方面是需要有效的方法来识别软件组件，包括拥有足够的信息来唯一地识别每个软件组件。然而，这种需求远不是一个微不足道的问题，因为软件领域由数千个不同的软件供应商、部门和社区组成。美国国家电信和信息管理局（NTIA）在他们的“软件识别挑战和指导”白皮书（www.ntia.gov/files/ntia/publications/ntia_ sbom_software_identity-2021mar30.pdf）中关注了这个问题，该白皮书是通过NTIA的多利益相关者过程产生的。NTIA指出，有必要在短期内功能性地识别软件组件，但也需要在未来使多个现有的识别系统实现合理化。这样做将缓解一些挑战，并帮助行业围绕一个统一的解决方案进行反弹。为了控制围绕软件组件识别的一些混乱，NTIA建议尽可能使用现有的识别系统，但指出这并不总是可能的，这导致一些人不得不使用“尽最大努力”的识别方法。

尽管整个行业的软件生产商和消费者都在广泛推动采用和集成软件材料清单（SBOM），但关于SBOM组件的识别，目前还没有权威的消息来源。软件供应商通常根据其组织和相关活动的需要来定义和识别软件组件。组件识别不是一个静态事件，而且可能会由于分叉和采用项目和组织收购等因素而改变，因此这个问题可能会进一步加剧。

尽管整个行业的软件生产商和消费者都在广泛推动采用和集成软件材料清单（SBOM），但关于SBOM组件的识别，目前还没有权威的消息来源。软件供应商通常根据其组织和相关活动的需要来定义和识别软件组件。组件识别不是一个静态事件，而且可能会由于分叉和采用项目和组织收购等因素而改变，因此这个问题可能会进一步加剧。

综上所述，有一些主要的软件识别标准被行业和NTIA认可，如cpe、软件标识标签（SWIDs）和软件包url（PURLs），我们接下来将快速查看它们。

CPE

通用平台枚举（CPE）是一种结构化的命名方案，用于描述和识别跨企业IT资产的应用程序、操作系统和硬件设备的类别。最初由NIST（www.govinfo.gov/content/pkg/GOVPUB-C13-5d78ccf04a5285bc768fb03ea45 dd6bb/pdf/GOVPUB-C13-5d78ccf04a5285bc768fb03ea45dd6bb.pdf），CPE于2011年8月发布，已经经过了几次迭代，截至本文时最新版本为2.3（https://cpe.mitre.org/specification）。CPE解决了以标准化的方式引用IT产品和平台的需求，同时对于处理和自动化也是机器可读的。NIST维护一个CPE字典（https://csrc.nist.gov/Projects/Security-Content-Automation-Protocol/Specifications/cpe/字典），它作为一个商定的CPE名称列表。它有XML格式，可供公众消费和使用。

最新的CPE规范，2.3，将CPE标准分解成一个堆栈中的一套单独的规范，其中包括以下内容：

■名称
■名称匹配
■字典
■适用性语言

该名称是CPE规范的基础，用于定义为IT产品类分配名称的标准化方法。名称匹配用于定义一种将源CPE名称与目标CPE名称进行一对一比较的方法。它决定了两个实体之间是否存在公共关系。例如，IT资产管理工具可以收集有关系统上安装的软件的信息，并识别已安装或存在的特定软件。该字典定义了创建和管理CPE字典的标准化方法，这些字典是CPE名称及其相关元数据的存储库。堆栈中的最后一个规范是适用性语言，它通过形成组成的CPE名称和引用的复杂逻辑表达式，定义了一种描述IT平台的标准化方式。CPE规范提供的一个例子是一个操作系统，如Windows XP，它运行微软Office 2007，以及操作系统上的一个特定配置，如有源无线网卡。

软件标识标签

软件标识（SWID）标记是由国际标准化组织认可的一种格式，是一种用于描述软件产品（https://csrc.nist.gov/projects/softwareidentification-swid/guidelines）的结构化元数据格式。SWID使用数据元素来识别软件产品，以及在产品生产和分发中发挥角色的产品版本、组织或个人，以及软件产品组成的工件。一些软件资产管理和安全流程将SWID作为活动的一部分，如对软件资产的漏洞评估、丢失的补丁程序或特定的配置管理评估。它还可以用作验证软件完整性的一部分，或作为安全操作活动的一部分。

NIST在其出版物NISTIR 8060“创建可互操作的软件标识（SWID）标签的指南”（https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf）中详细描述了使用SWID标签。NTIA还在其出版物“现有SBOM格式和标准的调查”（www.ntia.gov/files/ntia/publications/sbom_ formats_survey-version-2021.pdf）中讨论了SWID。SWID标签被各种标准机构使用，如可信计算组（TCG）和互联网工程特别工作组（IETF）。作为一个标准，SWID帮助定义一个软件产品的生命周期。SWID使用了四种类型的标签：

■ 基础
■ 补丁
■ 数据
■ 补充

基础标签用于识别和描述安装在计算设备上的软件产品，而补丁标签表示对已安装的软件产品进行的增量更改。数据标签表示处于预安装状态的可安装软件产品，例如有关安装软件包或软件更新的元数据。补充标签可用于向任何被引用的SWID标签添加信息。软件管理工具可以使用它们来添加元数据，而不改变其他标记格式。要可视化SWID标签的生命周期功能，请参见图3.2，它显示了前面提到的NTIA出版物中的一个示例。

虽然我们在SBOM格式的讨论中加入了SWID，但SWID并没有像其他主要SBOM格式(例如SPDX和CycloneDX)那样收到同等关注，因为它主要侧重于软件识别作为主要用例，并且缺乏其他格式提供的丰富的上下文。但是，需要注意的是，CycloneDX原生支持SWID进行软件识别。

PURL

软件包URL（PURL; https://archive.fosdem.org/2018/schedule/event/purl/attachments/slides/2298/export/events/attachments/purl/slides/2298/meet_purl_FOSDEM_2018_narrow.pdf）可帮助解决与软件包命名约定和协议相关的问题。现代软件开发涉及消耗和生产大量的软件包，如NPM和Ruby gem。然而，在涉及到软件包的识别、位置和供应时，每个包管理器和生态系统都使用不同的命名约定和方法。

为了解决这一挑战，nexB（www.nexb.com）--他们开发ScanCode和VulnerableCode、软件组成分析（SCA）和免费和开源软件（FOSS）安全扫描工具--开发了PURL规范（https://github.com/package-url/purl-spec）。PURL项目的目标是标准化在软件包管理器、工具和更广泛的软件生态系统中识别和定位软件包的方法。PURL由六个数据元素组成：

■方案
■类型
■命名空间/名称
■版本
■限定符
■子路径

有些元素是可选的，而其他元素则是必需的。这最终会形成一个URL字符串，比如pkg:bitbucket/birkenfeld/pygmentsmain@244fd47e07d1014f0aed9c. scheme是pkg常定的URL方案。Type是指示程序包类型的必需元素，如maven或NPM。命名空间，如Maven和Docker，是一个可选的元素。名称是显示程序包名称的必需字段；版本是一个可选的数据元素。限定符提供了额外的上下文，如操作系统、体系结构或分布，而子路径可以识别包中的其他子路径；这两个元素也都是可选的。

PURL最初是在FOSDEM 2018等活动上展示的。自成立以来，它现在被许多人认为是一个事实上的标准，用于包url的项目，如领先的SBOM格式CycloneDX和SPDX，OSS索引，和世界各地的其他组织。

开放全球应用程序安全项目（OWASP）、Linux基金会和Oracle等人的成员也已经开始努力让NVD采用PURL，以改进漏洞管理（https://owasp.org/blog/2022/09/13/sbom-forumrecommends-improvements-to-nvd.html）的自动化和组件识别.一个被称为SBOM论坛的组织，由供应链顾问和博客主 Tom Alrich（http://tomalrichblog.blogspot.com）领导，发表了一篇题为“操作脆弱性管理的组件识别的建议”的论文（https://owasp.org/assets/files/posts/A%20Proposal%20to%20Operationalize%20Component%20 Identification%20for%20Vulnerability%20Management.pdf）.在该文中，作者指出了命名问题，即开源产品或组件在不同的包管理器和注册表之间具有不同的名称。为了在漏洞识别和修复方面更有效，组织需要为软件组件制定一个标准化的命名约定。

NVD目前对软件产品使用CPE名称；然而，CPE命名约定带来了各种挑战，阻碍了与软件安全相关的自动化工作。NVD中的cpe主要通过供应商、产品和版本字符串来识别软件和硬件组件。NVD采用PURL有可能缓解与CPE使用相关的一些挑战，并促进改进的软件识别，以及帮助与SBOM采用和自动化相关的工作。

3.4 Sonatype OSS索引

随着OSS的采用不断增长，并日益对现代应用程序和产品的重要部分做出贡献，人们越来越需要了解与OSS组件相关的风险。超声型OSS指数已经成为一个帮助解决这个问题的著名来源。该索引提供了数百万个OSS组件的免费目录，以及组织可以使用这些扫描工具来识别OSS组件的漏洞和相关的风险，并降低组织的风险。OSS索引还提供了补救建议，与NVD一样，它有一个健壮的API，用于作为集成的扫描和查询的一部分。NVD和OSS索引之间的一个关键区别是使用了PURL而不是CPE。NVD使用CPE来唯一地识别受漏洞影响的脆弱产品，而OSS索引则使用PURL规范来描述组件或软件包的坐标。

除了能够搜索OSS组件并找到与漏洞相关的任何信息外，OSS索引还支持扫描项目的OSS漏洞，并通过索引的代表性状态传输（REST）应用程序编程接口（API）与现代连续集成/连续交付（CI/CD）工具链进行集成。作为更广泛的推动“安全左移”的一部分，将安全移到软件开发生命周期(SDLC)的早期，这种工具链和构建时集成有助于在将代码部署到生产运行时环境之前识别OSS组件中的漏洞。OSS索引API集成被许多流行的扫描工具用于各种编程语言，如Java Maven插件、Rust Cargo Pants、OWASP依赖检查和Python的ossaudit等。值得注意的是，虽然OSS索引对社区使用是免费的，但它也不包括任何特别策划的情报或来自专家的见解。然而，Sonatype确实提供了其他服务来提供额外的智能、管理库和提供自动化功能。

3.5 开源漏洞数据库

2021年，谷歌安全发布了（https://security.googleblog.com/2021/02/ launching-osv-better-vulnerability.html）开源漏洞（OSV）项目（https://osv.dev），目的是“改善对开源软件的开发者和消费者的漏洞分类”。该项目源于谷歌安全早期的“了解、预防、修复”项目(https://opensource.googleblog.com/2021/02/know-prevent-fix-frameworkfor-shifting-discussion-around-vulnerabilities-in-open-source.html).OSV致力于提供有关漏洞产生和修复位置的数据，以使软件消费者能够了解漏洞的影响以及如何降低风险。OSV的目标是最小化维护人员发布漏洞所需的工作量，并提高下游消费者的漏洞查询的准确性。OSV通过强大的API和查询漏洞数据，为开源软件包消费者自动执行分类工作流程。它还降低了软件维护人员试图提供可能影响下游消费者的提交和分支中受影响版本的准确列表所产生的开销。

谷歌安全发布了一些博客，展示了OSV如何将SBOM与漏洞连接起来，因为OSV能够以一种专门为映射到开源包版本和提交散列而设计的格式来描述漏洞。它还收集了来自各种来源的信息，如GitHub咨询数据库（GHSA）和全球安全数据库（GSD）。甚至还有一个称为spdx-osv（https://github.com/spdx/spdx-to-osv）的工具，它从软件包数据交换（SPDX）文档中列出的信息创建一个OSS漏洞JavaScript对象表示法（JSON）文件。

OSV不仅仅是一个在OSV.dev上可用的数据库；它也是一种模式和OSV格式。OSV指出，有许多漏洞数据库，但没有标准化的交换格式（https://ossf.github.io/osv-schema）。如果组织希望拥有广泛的漏洞数据库覆盖，他们必须使每个数据库都有自己独特的格式和模式。这一问题阻碍了软件消费者采用多个数据库，并阻碍了软件生产者将其发布到多个数据库。OSV旨在提供一种所有漏洞数据库都可以围绕的格式，并允许它们之间实现更广泛的互操作性，并减轻希望使用多个漏洞数据库的软件消费者、生产者和安全研究人员的负担。OSV以基于JSON的编码格式运行，具有各种字段细节，如ID、已发布、撤回、相关、摘要和严重性等，包括子字段。

3.6 全球安全数据库

尽管 CVE 计划得到了广泛采用，但许多人指出该计划存在问题，其方法以及无法跟上动态技术格局。随着云计算的兴起，云安全联盟 (CSA；https://cloudsecurityalliance.org) 等组织已成为现代云驱动 IT 时代指导和研究的知名行业领导者。CSA 的显著努力之一是创建全球安全数据库 (GSD)，它将自己描绘成解决现代问题的现代方法，声称 CVE 是一种过时的方法，没有跟上现代复杂的 IT 格局。这项工作由 Josh Bressers 和 Kurt Seifried 牵头，他们在 Red Hat 都拥有丰富的漏洞识别和治理经验和专业知识，而 Kurt 甚至还在 CVE 董事会任职。

在 CSA 博客文章《我们为何创建全球安全数据库》（https://cloudsecurityalliance.org/blog/2022/02/22/why-we-created-the-global-security-database）中，Kurt 列举了创建 GSD 的几个原因，以及 CVE 等其他计划未能达到预期的原因。该博客追溯了漏洞识别的起源，早于 CVE 的 BugTraq ID 计划，该计划要求相关方订阅并阅读可用的漏洞信息。他描述了 CVE 计划的发展，最初每年只有一千个左右的发现，在 2011 年开始下降之前达到 8,000 个 CVE 的峰值。正如我们之前讨论的那样，本文还展示了 CNA 的增长。然而，尽管 CNA 数量增长，但 Kurt 指出，近 25% 的 CNA 至少一年没有活动。 2017 年，发布和分配的 CVE 数量达到峰值，除了 2020 年的激增外，CVE 分配活动一直保持平稳，如图 3.3 所示。

本文介绍了 Josh 和 Kurt 参与的早期工作，例如分布式弱点归档项目，并讨论了 Linux 内核如何参与这项工作。Linux 项目拒绝与 CVE 计划合作，Greg Kroah-Hartman 在题为“2019 年内核配方 — CVE 已死，CVE 万岁！” (www.youtube.com/watch?app=desktop&v=HeeoTE9jLjM) 的演讲中对此进行了详细讨论。在该视频中，Greg 指出，由于应用和反向移植给用户的修复程序数量众多，CVE 计划与 Linux 内核配合不佳。Greg 解释了 Linux CVE 的平均“修复请求”时间线为 100 天，表明对 Linux 内核 CVE 缺乏关注，从更广泛的层面来看，Linux 项目的进展速度太快，无法适应严格管理的 CVE 流程。

GSD 公告描述了服务如何“吞噬世界”，现代软件和应用程序绝大多数都是以服务形式提供的，鉴于云计算以各种模式激增，这一点很难反驳，但最明显的是软件即服务 (SaaS) 等应用程序。作者解释了 CVE 计划在涵盖即服务应用程序方面缺乏连贯的方法。“吞噬世界”的评论是指之前的口头禅，即软件已经吞噬世界，但现在世界上许多软件都是以服务形式提供的。

在作者和GSD领导引用的其他变化中，还有像Python（20万）或NPM（130万）等软件包的迅猛增长。还有一种观点认为，CVE项目缺乏透明度、社区访问、参与度，并且缺乏与使用OSS软件包的供应商相关的数据，例如Log4j。

如果您有兴趣参与开放且由社区驱动的 GSD 工作，您可以在 GSD 主页 (https://globalsecuritydatabase.org) 或 Slack 或邮件列表 (https://groups.google.com/a/groups.cloudsecurityalliance.org/g/gsd?pli=1) 等通信渠道上了解更多信息。

3.7 公共漏洞评分系统

虽然CVE计划提供了一种识别和记录漏洞的方法，NVD丰富了CVE数据并将其呈现在一个强大的数据库中，但通用漏洞评分系统（CVSS）则评估安全漏洞的严重性并分配严重性分数。CVSS致力于捕捉软件、硬件和固件漏洞的技术特性。它提供了一种平台和供应商无关的行业标准化评分方法，并且在分数来源的特性和方法方面完全透明。

CVSS起源于国家基础设施咨询委员会（NIAC）在2000年代初期的研究，CVSS版本1于2005年初问世。虽然NIAC的研究导致了CVSS的创建，但在2005年，NIAC选择了事件响应和安全团队论坛（FIRST）来领导和管理未来的CVSS计划。FIRST是一个位于美国的非营利组织，为计算机安全事件响应团队提供资源，如CVSS。虽然CVSS由FIRST拥有和运营，但其他组织可以在遵循FIRST CVSS规范指导的前提下使用或实施CVSS。CVSS经历了几次迭代，最初的CVSS在2005年初发布，CVSS v2于2007年发布，CVSS v3于2015年发布。截至本文写作时，CVSS已更新到v3.1规范。CVSS由三个核心指标组组成，如图3.4所示。

如前所述，CVSS由三个指标组组成：基本指标、时间指标和环境指标。漏洞的严重性基于固有特性，这些特性在假定最坏情况的情况下保持不变，无论部署环境如何。另一方面，时间指标调整基本分数，考虑随时间变化的因素，包括漏洞利用工具的实际可用性。环境指标根据计算环境的具体情况调整基本和时间严重性分数，包括减少风险的缓解措施的存在。

基本分数由产品所有者或第三方（如安全研究人员）分配。这些分数/指标在分配后保持不变，因此会被发布。由于发布方不会拥有托管或操作环境的全部背景信息以及潜在的缓解控制措施，因此CVSS消费者可以根据需要通过时间和环境分数来调整分数。成熟的组织通过基于这些因素进行调整，能够更好地优先处理漏洞管理活动，基于更准确的风险计算，考虑到其具体环境和所涉及的控制措施。

深入探讨每个指标组，基本指标组涉及随时间一致的固有特性，除非有新信息出现，无论该组存在于何种环境中。基本指标组包括可利用性指标和影响。可利用性指标包括攻击向量、攻击复杂性以及所需权限等。这些指标围绕一个易受攻击的组件及其被利用的难易程度。另一方面，影响指标使用传统的网络安全CIA三元组（机密性、完整性和可用性），这涉及漏洞被利用的后果以及对易受攻击组件的影响。

基本指标

基本指标做出了一些假设，例如攻击者对系统及其防御机制的了解。截至本文写作时，CVSS 3.1是现行版本，而CVSS 4.0正在开发中。我们的讨论将基于CVSS 3.1的视角。正如之前提到的，基本指标还包括特定于可利用性和影响的指标。在可利用性指标中，有攻击向量和复杂性、所需权限、用户交互和范围等因素。

攻击向量指标旨在提供关于恶意行为者可能使用的攻击方法的背景。由于需要物理接近才能进行攻击的情况较少，因此攻击向量的评分受到影响。攻击向量指标包括网络、邻接、本地或物理等值。从网络角度来看，攻击向量可能绑定到本地网络、远程可利用性，甚至可能涉及整个互联网。而邻接则绑定到特定的物理或逻辑范围，例如共享蓝牙网络/范围或在同一局域子网中。本地涉及访问系统键盘或控制台，但也可能包括远程SSH访问。本地还可能需要用户交互，例如通过网络钓鱼攻击和社会工程。最后，物理指标值意味着恶意行为者需要物理访问易受攻击的组件才能利用漏洞。

虽然攻击向量指标基于攻击者可用的路径和方法，但攻击复杂性涉及超出恶意行为者控制的条件，可能包括易受攻击组件上存在的特定配置。攻击复杂性分为低或高。低复杂性指的是允许恶意行为者反复成功利用易受攻击组件的情况，而高复杂性则更复杂，可能需要恶意行为者收集知识、准备目标环境或插入网络路径，例如使用路径攻击。

所需权限指标描述了攻击者必须具备的权限级别才能成功利用漏洞。在不需要任何权限的情况下，基本分数会最高；而在需要恶意行为者具备管理员级别访问权限的情况下，分数会较低。所需权限的值包括：

■ 无：不需要访问系统或组件

■ 低：需要基本用户权限

■ 高：需要管理员级别的权限才能利用漏洞

用户交互指标描述了除恶意行为者外的其他用户需要进行的操作，以使漏洞成功利用。一些漏洞可以在没有其他用户参与的情况下成功利用，而其他漏洞则需要额外用户的参与。此指标非常简单，可能值为“无”或“需要”。

最后一个可利用性指标是范围，描述了易受攻击组件的利用是否可能超出其自身的安全范围并影响其他资源和组件。该指标要求了解易受攻击组件对其他资源的影响范围，更基本地说，需要了解哪些组件最初在其管理权限之下。范围的两个指标值是“未改变”和“已改变”，表示利用对其他安全权限管理的组件的影响程度。

在基本指标中，还有影响指标，以传统的CIA三元组（机密性、完整性和可用性）表示。CVSS建议分析人员将其影响预测合理地与恶意行为者可能造成的实际影响保持一致。如果你熟悉NIST风险管理框架对CIA的指导，你会注意到两者的相似之处。CIA指标值包括无、低或高。无意味着对CIA没有影响，低意味着对CIA有一定程度的损失，高意味着对CIA的完全损失以及在特定场景下漏洞利用所能造成的最严重影响。

时间指标

正如之前提到的，时间指标会随着时间的推移而变化，例如活跃的漏洞利用会提高分数，而可用的补丁会降低CVSS分数。请记住，这些因素与行业相关，而不是特定用户的环境或某个组织可能已实施的特定缓解措施。时间指标包括漏洞利用代码成熟度、补救水平和报告可信度。

漏洞利用代码成熟度基于相关利用技术的当前状态和可用于利用漏洞的代码的可用性。这通常被称为“野外利用”，一个显著的例子是CISA的“已知利用漏洞目录”（Known Exploited Vulnerabilities Catalog，www.cisa.gov/known-exploited-vulnerabilities-catalog），该目录定期更新已知被积极利用的漏洞，联邦机构需要修补这些已知的可利用漏洞。该列表已包含数百个漏洞以及适用于许多组织的各种软件和硬件利用方法。随着新漏洞被发现和确认，该列表会定期更新。漏洞利用代码成熟度指标包括未证明（unproven）、概念验证（proof-of-concept，PoC）、功能性（functional）、高级（high）和未定义（not defined）。这些指标代表了从没有利用代码或仅为理论性的情况，到完全功能化且自动化且不需要手动触发的情况。

补救水平指标有助于驱动漏洞优先级排序工作，涉及通过可用的官方修复方案进行的临时解决方案。潜在的指标值包括不可用（unavailable）、临时解决方案（workaround）、临时修复（temporary fix）和官方修复（official fix）。修复漏洞可能是可行的，或者需要非官方的临时解决方案，直到发布、验证并验证为可消费和实施的官方修复方案。

最后一个时间指标，报告可信度，涉及漏洞报告及其相关技术细节的实际可信度。初步报告可能来自未经验证的来源，但可能会逐渐被供应商或信誉良好的安全研究人员验证。潜在的指标值包括未知（unknown）、合理（reasonable）和确认（confirmed），代表了对报告的漏洞和细节的信心逐渐增加。这些因素会影响漏洞的整体评分。

环境指标

对于组织特定的背景，这是环境指标发挥作用的地方。由于每个环境都是独特的，并且有一系列可能影响环境评分的因素，如技术堆栈、架构和特定的缓解控制措施，每个软件消费者的环境指标都会有所不同。

环境指标帮助组织根据其操作环境的特定因素调整基本分数。这些修改围绕CIA三元组（机密性、完整性和可用性），允许分析人员根据每个CIA方面在组织业务功能或使命中所扮演的角色分配相应的值。修改后的基本指标是由于用户环境的具体情况而覆盖基本指标的结果。值得注意的是，这些修改需要对基本和时间指标因素有详细的了解，以进行准确的修改，从而不会低估漏洞对组织构成的风险。

CVSS 评分尺度

CVSS 使用一个定性的严重性评级尺度，范围从 0.0 到 10.0，如图 3.5 所示。

所有不同的 CVSS 评分指标和方法都会生成一个称为向量字符串的内容，CVSS 规范将其定义为“一种特定格式的文本字符串，包含分配给每个指标的每个值，并应始终与漏洞评分一起显示。” 向量字符串由指标组、指标名称、可能的值以及它们是否是必选项组成。这最终形成一个向量字符串，例如“攻击向量：网络，攻击复杂性：低，所需权限：高，用户交互：无，范围：未改变，机密性：低，完整性：低，可用性：无。”

计算这些指标需要详细了解可能的字段、值和其他因素。我们强烈建议您访问 CVSS v3.1 规范文档，以了解更多关于公式和指南的信息（www.first.org/cvss/v3.1/specification-document）。

批评意见

尽管CVSS被广泛使用和采用，但它也有其批评者。安全研究员和作家Walter Haydock在他的“Deploying Securely”博客（www.blog.deploy-securely.com）中的文章《CVSS：评估风险的不合适行业标准》（www.blog.deploy-securely.com/p/cvss-an-inappropriate-industry-standard）中，对CVSS提出了批评。Walter认为CVSS不适合评估网络安全风险。他引用了多篇行业领袖的文章，这些文章表明，尽管行业广泛使用CVSS进行风险评估，但单独使用CVSS进行风险评估并不恰当（https://pt-br.tenable.com/blog/why-you-need-to-stop-using-cvss-for-vulnerability-prioritization）。

正如Walter的文章以及其他文章所指出的，CVSS通常被用来帮助组织根据漏洞的利用难度和可能的影响程度来优先处理漏洞。像Tenable这样的组织的研究指出，不论这些漏洞是否可能被利用，CVSS评分为高或严重的漏洞中有超过50%从未被利用（https://pt-br.tenable.com/research）。研究表明，所有被评为高或严重的漏洞中，有75%从未实际有已知的利用代码发布，但安全团队仍然优先处理这些漏洞。这意味着，组织可能在浪费有限的时间和资源，优先处理不太可能甚至从未被利用的漏洞，而不是解决那些具有活跃利用代码的漏洞。

由于采用这种笼统的方法追踪CVSS评分为高和严重的漏洞，组织可能忽视了大量评分在4到6之间且具有活跃利用代码的漏洞，从而错失了大量风险。这是可以理解的，因为组织通常需要处理数百甚至数千个资产，这些资产通常与许多漏洞相关。当你淹没在大量漏洞数据中时，很难追踪和进行细致的漏洞管理，更不用说清楚了解哪些资产属于你的组织并构成风险。

要更深入了解CVSS，可以查看NIST发布的内部报告8409《衡量通用漏洞评分系统基本评分公式》（https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8409.pdf）。

3.8 漏洞预测评分系统

基于对CVSS的批评，一些人呼吁使用漏洞预测评分系统（Exploit Prediction Scoring System, EPSS）或将CVSS与EPSS结合，以使漏洞指标更具可操作性和效率。与CVSS类似，EPSS也由FIRST管理。EPSS以其开放和数据驱动的努力为荣，旨在估计软件漏洞在野外被利用的概率。CVSS关注漏洞的固有特性，最终形成严重性评分。然而，仅仅依靠严重性评分并不能表明漏洞被利用的可能性，而这对于需要优先处理漏洞修复和缓解工作的漏洞管理专业人员来说是至关重要的信息，以最大限度地减少组织风险。

EPSS有一个面向公众开放的特别兴趣小组（SIG），欢迎那些对参与该项目感兴趣的人加入。EPSS由志愿者驱动，由研究人员、安全从业者、学术界和政府人员领导，但FIRST拥有根据组织需要更新模型和相关指导的权利，尽管这是一个行业协作的方式。目前，该小组拥有来自RAND、Cyentia、弗吉尼亚理工大学和Kenna Security等组织的主席和创建者。EPSS有几篇论文深入探讨了相关主题，如攻击预测、漏洞建模和披露以及软件利用（www.first.org/epss/papers）。

3.9 EPSS模型

EPSS旨在帮助安全从业者及其组织改进漏洞优先级排序工作。在当今的数字环境中，识别出的漏洞数量呈指数增长，这一数量因系统和社会的数字化程度提高、对数字产品的审查增加以及研究和报告能力的提高而不断增加。EPSS指出，组织每月只能修复5%到20%的漏洞。实际上，已发布的漏洞中只有不到10%被确认曾在野外被利用。长期以来的劳动力问题也在发挥作用，例如年度（ISC）2网络安全劳动力研究（www.isc2.org/News-and-Events/Press-Room/Posts/2021/10/26/ISC2-Cybersecurity-Workforce-Study-Sheds-New-Light-on-Global-Talent-Demand），显示全球网络安全专业人员短缺超过200万人（见图3.6）。

这些因素使得组织需要一个连贯且有效的方法来优先处理带来最高风险的漏洞，以避免浪费有限的资源和时间。EPSS模型通过创建漏洞在接下来的30天内被利用的概率评分来提供支持，评分范围在0到1之间，即0%到100%。为了提供这些评分和预测，EPSS使用来自各个来源的数据，如MITRE CVE列表、关于CVE的发布日期数据，以及来自AlienVault和Fortinet等安全供应商的野外利用活动观察数据。

EPSS团队发布的数据支持其使用不仅仅是CVSS评分，还包括EPSS评分数据的做法，以实现更有效的漏洞修复。例如，许多组织规定，CVSS评分达到或高于特定值（如7或以上）的漏洞必须修复。但这种方法仅基于CVSS评分优先处理漏洞修复，而不考虑漏洞是否已知被利用。将EPSS与CVSS结合使用更为有效，因为这样组织可以根据漏洞的严重性评分以及它们是否已知被积极利用来优先处理漏洞，使组织能够处理对其构成最大风险的CVE。

EPSS关注两个核心指标：效率和覆盖率。效率指标评估组织在使用资源修复漏洞方面的能力。EPSS指出，大部分组织的资源花在修复已知被利用的漏洞上比随机修复仅基于CVSS严重性评分的漏洞更有效。覆盖率指标评估被修复的漏洞中已被利用的漏洞的百分比。

为了展示其提出的方法的效率，EPSS在2021年使用CVSS v3基本评分、EPSS v1和EPSS v2数据进行了研究。他们考虑了一个30天的时间段，以确定CVE的总数、修复的CVE数量和被利用的CVE数量。正如图3.6所示，几个事实显而易见。首先，大多数CVE根本没有被修复。其次，被修复的CVE中，被利用的CVE仅是其中的一部分。这意味着组织没有修复大多数CVE，而在他们修复的CVE中，许多并没有被积极利用，可能不会带来最大的风险。这也表明，EPSS v2通过最大化被修复的已被利用的漏洞的百分比，进一步提高了漏洞修复工作的效率。当组织在网络安全从业人员方面面临资源挑战时，通过让资源集中在对组织构成最大风险的漏洞上，最大化投资回报至关重要。EPSS试图帮助组织更有效地利用有限的资源，提高降低组织风险的效果。

3.10 EPSS的批评意见

与CVSS类似，EPSS也受到业界和学术界的批评。卡内基梅隆大学软件工程研究所（SEI）博客上的一篇文章《Probably Don’t Rely on EPSS Yet》（https://insights.sei.cmu.edu/blog/probably-dont-rely-on-epss-yet）对EPSS提出了质疑。SEI最初发布了一篇题为《Towards Improving CVSS》的论文，对CVSS进行了尖锐的批评，EPSS便是在该论文发布后不久推出的（https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=538368）。

文章提出的一些主要批评包括EPSS的不透明性及其数据和输出问题。文章讨论了EPSS的开发过程、治理或目标受众如何被决定的方面尚不清楚。文章指出，EPSS依赖于现有的CVE ID，这意味着EPSS对软件供应商、事件响应团队或漏洞奖励小组等实体没有帮助，因为这些小组处理的许多漏洞尚未获得CVE ID，且可能永远不会获得。此外，EPSS在处理零日漏洞时也无济于事，因为这些漏洞在被利用时才获得关注，而没有已知的关联CVE ID。

文章的作者还对EPSS的开放性和透明性提出了担忧。尽管EPSS自称是一个开放和数据驱动的努力，并且如前所述还有一个特别兴趣小组（SIG），但EPSS及其管理组织FIRST仍然保留在任何时候更改网站和模型的权利，无需解释。实际上，即使是SIG成员也无法访问用于底层EPSS模型的代码或数据。SIG本身对模型没有监督或治理权，而模型更新或修改的过程对SIG成员乃至公众都不透明。文章指出，由于EPSS由FIRST管理，EPSS模型和数据也可能被从公共贡献和使用中撤回。

文章表明，EPSS专注于预测漏洞在接下来的30天内被利用的可能性。但要做出这种预测需要一些基本的条件。这些条件包括NVD中已有的CVE ID并且具有相关的CVSS v3向量值、与CVE ID关联的活跃利用尝试的入侵检测系统（IDS）签名、来自AlienVault或Fortinet的数据贡献（它们向EPSS提供数据），以及与未来30天相关的模型。正如作者指出的，只有10%的具有CVE ID的漏洞有伴随的IDS签名，这意味着90%的具有CVE ID的漏洞在利用时可能不会被检测到。这也导致对Fortinet和AlienVault的IDS传感器及相关数据的依赖，可以通过更广泛的安全供应商社区的进一步参与来缓解。

3.11 CISA的观点

随着关于漏洞优先级排序和管理的讨论日益激烈，像CISA这样的组织也对此发表了看法。2022年11月发表的一篇题为《Transforming the Vulnerability Management Landscape》的文章（www.cisa.gov/blog/2022/11/10/transforming-vulnerability-management-landscape）中，CISA执行助理主任Eric Goldstein讨论了现代数字环境的复杂性和漏洞加速出现的速度。

根据文章，CISA提出了推动漏洞管理生态系统进步的三个关键步骤：

1. 扩大通用安全咨询框架（CSAF）的使用，提供自动化的机器可读安全咨询

2. 增强漏洞利用交换（VEX）的采用，帮助软件消费者了解特定产品何时受可利用漏洞的影响

3. 通过使用利益相关者特定漏洞分类（SSVC）和CISA的已知利用漏洞（KEV），帮助组织优先安排漏洞管理资源

我们将在本节中更详细地讨论这些步骤。

通用安全咨询框架（CSAF）

CISA列表中的首项是使用CSAF来自动化生成机器可读的安全咨询。正如CISA指出的，每当发现并披露一个新漏洞时，软件供应商必须评估其产品并验证是否适用，如果适用，决定如何修复并将此信息传达给其客户群体。在供应商进行这些工作的同时，恶意行为者也在积极寻找机会利用漏洞，可能在供应商能够直接修复（例如SaaS环境）或发布补丁并由终端用户应用之前（例如传统的本地软件）。随着漏洞发现和披露速度的加快，尤其是与CVE相关的漏洞，迫切需要自动化和加速这一活动，以便将信息迅速传达给软件消费者，这正是机器可读性和自动化的作用所在。

CSAF由OASIS通用安全咨询框架（CSAF）技术委员会领导。OASIS是一个非营利联盟，帮助创建和推广各种最佳实践和标准。OASIS提供了一些优秀的资源供那些想要了解CSAF的人使用，包括他们的“什么是通用安全咨询框架（CSAF）？”视频（www.youtube.com/watch?app=desktop&v=vQ_xY3lmZOc）或非常全面的CSAF 2.0规范（https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html）。

根据规范的定义，“CSAF支持创建、更新和互操作交换安全咨询，作为产品、漏洞及其影响和缓解状态的结构化信息。”这些咨询以JSON格式提供。

传统上，安全咨询以静态文档形式发布，如PDF文件和网站，供人类阅读。其挑战在于漏洞发现和披露速度加快，以及在恶意行为者利用漏洞之前进行修复的竞赛，使得机器和自动化的需求变得至关重要。这种情况与其他网络安全领域有许多相似之处，这些领域也越来越多地采用机器可读的工件，例如使用开放安全控制评估语言（OSCAL）的治理风险与合规（GRC）工具和基础设施即代码及合规即代码的传统IT。现代技术环境变化太快，人类无法作为中介来应对。

CSAF还致力于提供一套强大的工具（https://oasis-open.github.io/csaf-documentation），如CSAF解析器、可视化工具、可信提供者和聚合器等。值得注意的是，截至本文写作时，这些工具仍在开发中，可能缺乏某些功能，例如CSAF解析器尚不支持CSAF 2.0。这些工具每个都配有GitHub存储库、文档和代码库，以帮助组织和采用者更好地利用CSAF并将其作为其网络安全和漏洞管理活动的一部分，无论是作为软件消费者还是生产者。

CSAF架构文档主要涉及三类信息：

■文档的框架、聚合和参考信息

■CSAF咨询创建者认为相关的产品信息

■与所讨论产品相关的漏洞信息

CSAF还原生支持引用用于平台数据、漏洞分类和评分等行业标准化内容的架构。例如CPE、CVSS和CWE，每个都有一个用于使用的架构。

通过这一基本概述，很容易看出CSAF如何帮助引入一个机器可读安全咨询的时代，这些咨询可以自动化并有助于加速创建、分发和接收安全咨询，从而惠及软件提供商和消费者，并在软件生态系统中做出关于网络安全风险的快速决策。如需了解更多信息，可以查看详尽的规范本身或观看一些可供参考的CSAF视频（https://oasis-open.github.io/csaf-documentation）。

漏洞可利用性交换

在关于CSAF的讨论基础上，CISA的第二个关键步骤是广泛采用VEX。我们将在第4章“软件物料清单的崛起”中讨论VEX，因此这里只作简要介绍。在高层次上，VEX允许软件供应商断言特定漏洞是否影响某个产品以及是否不影响某个产品。实际上，组织面临网络安全人才短缺的问题，VEX允许组织优先将时间和资源花在对其构成风险的漏洞上，而不是那些可能无法利用且不构成风险的漏洞上。VEX文档作为SBOM的密切伙伴，提供关于SBOM中包含的漏洞的可利用性的信息，这些文档可以与SBOM一起或独立于SBOM生成。由于漏洞不断被发现和披露，即使没有新的软件发布，也可能会出现新的漏洞，因此在某些情况下，VEX的节奏可能与SBOM不同。

行业在SBOM和VEX领域的规范和工具方面不断创新。例如，在2023年初，软件供应链领导者Chainguard宣布，通过与HPE和TestifySec等其他公司的合作，他们创建了OpenVEX规范。OpenVEX旨在保持简洁、合规、可互操作和可嵌入。更多信息可以在OpenVEX的GitHub存储库中找到（https://github.com/openvex/spec）。

特定利益相关者漏洞分类和已知被利用的漏洞

行业内的一个持续需求是帮助组织优先处理构成最大风险的漏洞。

CISA（网络安全和基础设施安全局）已策划并发布了一个已知被利用的漏洞（KEV）目录，并通过一项强制性操作指令（BOD） (www.cisa.gov/binding-operational-directive-22-01)要求联邦机构修复这些KEV。CISA建议，如果商业组织受到这些KEV的影响，也应采取同样的措施。该目录以网页形式发布，同时也提供CSV或JSON文件格式。组织和个人还可以订阅KEV目录更新公告，通过电子邮件通知新KEV的添加。

一个漏洞要进入KEV目录的标准包括以下几点：

■它必须有一个CVE ID分配。
■根据可靠证据，该漏洞正在在野利用。
■对于该漏洞有明确的补救指导，例如供应商提供的补丁或更新。

正如我们之前讨论的，CVE计划由CISA赞助，但由MITRE运行，MITRE是一个联邦资助的研究与开发中心（FFRDC）。CVE计划的目的是识别、定义和编目公开披露的漏洞。CVE ID由CVE编号机构分配，并有三种可能的状态：保留、发布或拒绝。

CISA 的 KEV 目录并不使用漏洞可利用性本身作为纳入目录的标准。相反，必须有可靠证据表明该漏洞已被尝试利用或成功利用。例如，可能有证据表明恶意行为者尝试在目标上执行代码但未成功，或者仅在蜜罐系统上执行。与尝试利用不同，成功利用意味着恶意行为者成功利用目标系统上的漏洞代码，从而能够在系统或网络上执行某种未经授权的操作。CISA 谨慎地指出，PoC漏洞利用不会被纳入 KEV 目录，因为尽管研究人员可能展示了某些漏洞可能被利用，但没有证据表明它在实际环境中已被利用或尝试利用。

纳入 KEV 目录的第三个标准是明确的修复指导。这意味着组织可以采取明确的行动来减轻 KEV 的风险。这些行动可能包括应用供应商更新，或者在潜在的严重情况下，如果没有可用的更新或产品已到达生命周期终点且不再更新或支持，则完全从网络中移除受影响的产品。CISA 还承认，在缺乏相关更新和补丁的情况下，组织通常会寻求实施缓解措施（防止漏洞被利用）或变通方法，这些是手动更改，用于在补丁可用之前保护易受攻击的系统免受利用。

在使用 KEV 的指导基础上，CISA 正致力于通过特定利益相关者漏洞分类（SSVC）帮助组织优先分配漏洞管理资源。SSVC 是通过 CISA 与卡内基梅隆大学的软件工程研究所（SEI）合作创建的。SEI 对单独使用 CVSS 等资源的批评并不陌生，2018 年发布了一篇具有一定批判性的白皮书《Towards Improving CVSS》，指出广泛使用的 CVSS 在漏洞优先级管理中的若干缺陷（https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=538368）。值得一提的是，尽管倡导使用诸如 SSVC 这样的框架，像 CISA 这样的联邦组织仍然强制使用 CVSS，尽管他们积极与诸如 SEI 这样的组织合作，这些组织已指出 CVSS 的缺点和不足(www.blog.deploy-securely.com/p/revealing-the-governments-approach)。

如 CISA 的 SSVC 指南所述，SSVC 是一种定制的决策树模型，旨在协助美国政府及相关实体优先处理漏洞响应，但其他组织也可以使用。SSVC 包括四种可能的决策，如图 3.7 所示。

该指南建议组织了解漏洞的范围，因为这也会影响决策树的使用。例如，漏洞是否遍布整个企业，或仅影响关键系统的一部分。

在使用 SSVC 并逐步通过决策树时，组织应考虑多个因素。这些因素包括利用状态，可以使用国家漏洞数据库 (NVD) 或信息共享与分析中心 (ISACs) 等来源。这些来源通常提供关于漏洞是否没有利用证据、是否存在概念验证 (PoC) 或是否正在实际环境中被积极利用的见解。

接下来，组织需要了解利用漏洞的技术影响。在这里可以类比 CVSS 的基础评分概念——严重性。可能的取值包括“部分”，即恶意行为者对系统的控制或影响有限；以及“完全”，即恶意行为者对漏洞所涉及的软件或系统的行为具有完全控制权。

另一个关键因素是漏洞利用是否可以自动化。对于恶意行为者来说，能够自动化利用的漏洞比需要人工干预和实施的漏洞更容易扩展其恶意活动。这里的决策值是简单的“是”或“否”。如果答案是“是”，那么恶意行为者可以自动化执行洛克希德·马丁公司网络杀伤链（ (www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html)）步骤1-4：侦察、武器化、投递和利用。指导意见还提到，除了自动化，还必须考虑漏洞链结，因为为了成功利用漏洞，可能需要或可能可以将多个漏洞或弱点连在一起。

从技术影响开始，考虑到任务的普遍性，即对任务基本职能或有关实体的影响。SSVC 指导意见将这些功能定义为“直接与完成组织在其法定或执行宪章中规定的使命相关的功能。”组织通过业务连续性规划（BCP）等演习来识别 MEFs。决策值包括最小、支持或必要。必要是指存在漏洞的组件直接为至少一个 MEF 或实体提供能力，且漏洞利用会导致任务失败。而支持则意味着存在漏洞的组件支持 MEFs 但不直接支持它们。最后，最小是指既不适用必要也不适用支持的情况。

决策树中的下一个考虑因素是公众福祉的影响，即存在漏洞的组件或系统对人类的影响程度。SSVC 采用了美国疾病控制与预防中心（CDC）对福祉的定义：人类的身体、社会、情感和心理健康。这里的决策分为影响的严重程度，可以是物质上的或不可逆的，以及伤害的类型，从身体上的、心理上的，甚至是经济上的伤害都包含在内。

最后是缓解状态的考虑，它衡量了及时缓解脆弱性的困难程度。需要考虑的因素包括：

■缓解措施是否公开可用。
■进行所需系统更改的难度。
■是否存在修复方案或需要临时解决方法。

指导意见强调，缓解措施的价值不应改变 SSVC 决策的优先级，但应积极跟踪和考虑 SSVC。图 3.8 是决策树的示例，但也可以以表格格式表示。

3.12 行动意见

CISA 指导意见优先考虑的步骤包括使用 CSAF 自动化安全公告，并通过 VEX 等资源告知软件消费者漏洞利用的影响。然而，同时也明确指出，需要主观的网络安全专业知识，尤其是在复杂的决策树中。自动化在减轻组织和网络安全团队认知负荷方面发挥了关键作用，但仍需具备网络安全和软件专业知识，以理解漏洞对更广泛的企业和系统环境的影响，并确定如何优先分配组织资源来应对这些挑战。

3.13 小结

在本章中，我们了解了行业漏洞数据库和评分方法。这包括传统漏洞数据库及其潜在的局限性，以及整个漏洞生态系统中新兴的数据库。我们还审视了常见的软件身份格式及其带来的挑战，以及为缓解这些挑战所提出的解决方案。同时，我们探讨了漏洞如何分类、评分和传播。在下一章中，我们将看看软件物料清单 (SBOM) 及其相关工件如 VEX 的兴起。