CVSS4升级内容浅析

快速了解CVSS4的升级内容

0x00 前言

FIRST.Org, Inc. (FIRST)在2023年11月1日，正式发布了Common Vulnerability Scoring System version 4.0（简称CVSS4），熟悉我的小伙伴应该知道我的工作内容有一部分和漏洞评级相关，当时团队内负责漏洞运营分析的各位师傅能明显感受到CVSS3.1所带来的局限性，为此我们还做了一些修正的方案。这次终于在年底前把CVSS4等到，接下来我们看看具体的内容，CVSS4带来了哪些改变。

0x01 CVSS4与CVSS3.1的度量标准对比

先贴两张图。

可以方便大家直观的感受一下，CVSS4与CVSS3.1的差异。

0x02 CVSS命名规范

CVSS4中引入了一个新的命名规范，用来描述在不同场景下的评分。我们知道CVSS3.1的评分规范中，是有三个部分组成的（上图所示），大部分情况，包括第三方的漏洞库，甚至NVD和CNA厂商所提供评分中，仅仅只提供了基础度量组（Base Metric Group）的分数，如果在分数计算器中继续填写时间度量组（Temporal Metric Group）或环境度量组（Environmental Metric Group）中的指标，会进一步得出一个新的分数，但是这种方式提供的分数，无法明确感知是否包含时间度量和环境度量的情况，所以在CVSS4中，对这种情况增加了一个的命名的概念，用来区分最终评分采用了哪些指标组。

另外我们也可以看到在CVSS4中度量组也产生了新的变化，基础和环境两个组保留下来，原来的时间（Temporal）重命名为威胁（Threat）,另外新增了补充（Supplemental），我们会在稍后讨论这些改动。

根据使用的Metrics Group有如下的命名方式：

CVSS命名	使用的指标组
CVSS-B	基础指标
CVSS-BE	基础和环境指标
CVSS-BT	基础和威胁指标
CVSS-BTE	基础，威胁和环境指标

此外还有以下几点需要注意：

• 不管在任何时候显示或者传递CVSS分数时候，应该明确显示这个命名法。
• 环境和威胁指标，NVD依然和3.1版一样，不做提供，根据FIRST的定义，这些指标应该是CVSS的消费者（也就是使用方）的责任，例如公司安全部门，需要根据这些指标对自己的资产收到的影响做重新的评估。
• 有朋友可能注意到了上图中还有一个补充度量组，并没有出现在这个命名方案中，原因是因为这个度量组的指标不会影响最终的评分，另外和环境，威胁指标一样，在FIRST的定义中，也需要由CVSS的消费者自行去确定。

0x03 CVSS基础分（CVSS-B）衡量的是严重性（Severity）而不是风险（Risk）

在CVSS4.0的规范文章中特地强调了：CVSS的基础分 (CVSS-B) 旨在衡量漏洞的严重性，不应单独用于评估风险。CVSS基本分仅代表漏洞本身的特征，与它能造成的危害或者所处的环境没有关系。如果想要评估漏洞的真实风险，则可以使用CVSS-BTE做更加全面的评估，CVSS-BTE的分数被视为更加接近真实的风险。

说到这里想提及两件事，第一个是在国内环境做漏洞预警相关的业务，经常会感觉CVSS评分给了一个比较高的分数，但实际在测试利用过程中，发现是属于很鸡肋的一个洞，利用场景的要求非常高，会下意识的认为这个漏洞CVSS分数不准，然后吐槽一句CVSS就是一坨💩，其实本质上可能就是对Severity和Risk概念没有分清楚，才造成这种误解（来自某威胁情报中心某领导的说法）。

第二件事是关于漏洞修复优先级，单纯依靠CVSS-B来做，早已被证实其实不是那么准确，需要评估漏洞对目标所造成对真实风险是如何的，面对不同的目标环境下，可能造成的风险水平也有较大的差异，所以FIRST给出的建议可以参考CVSS-BTE，如果有做相关的扫描器或ASM等产出的漏洞报告时候，可以根据所处环境评估TE两个指标的分数，进一步得出更加真实的优先级排序。

0x04 Scope指标移除

原3.1版本中包含Scope的指标，并且与Confidentiality、Integrity、Availability三个指标相关。在4.0版本中被Vulnerable System Impact Metrics中的Confidentiality（简称VC）、Integrity（简称VI）、Availability（简称VA）和Subsequent System Impact Metrics中的Confidentiality（简称SC）、Integrity（简称SI）、Availability（简称SA）所代替。

0x05 评估软件库（或类似库）中的漏洞

在新的指南中说明了如何评估外部引入的库文件存在漏洞所造成影响，包括但不限于类似Maven，pip，npm等类似的软件库，包文件等。

0x06 允许多个CVSS基础分

我们知道漏洞通常会影响产品的多个版本，不同的平台或操作系统。在这种情况下适用指标选项可能并不相同。举个例子来说，一个漏洞在同一厂商的低版本操作系统上攻击复杂度(AC) 为低 (L)。但是在较新的操作系统上增加了额外的保护功能，攻击复杂度变为高 (H)。这种差异会最终导致同一漏洞在两个操作系统上的CVSS-B得分不同。

在新版规范中同一个漏洞如果有多个CVSS-B的情况是允许的。

0x07 环境安全要求度量标准的使用指南

在环境度量组（Environmental Metric Group）中分为了两个部分，第一部分是根据实际环境的影响按照Base组指标重新进行评分，另外一部分新增了三个安全要求度量：易受攻击系统的机密性要求（CR）、易受攻击系统的完整性要求（IR）和易受攻击系统的可用性要求（AR）。

0x08 新的指标：攻击要求（Attack Requirements）

在CVSS3.1中，攻击复杂度（AC）的“低”和“高”这两种分类方式并不能准确反映出所有攻击复杂性的实际差异。也就是说，尤其是在“高”这一类别，把许多明显不同的攻击条件都压缩到了一起，这种二元分类方法降低了评价的精准度。例如，绕开安全缓解技术如ASLR或者密码技术明显需要比重放攻击复杂性更高，但是，这两种条件都会给最终的严重性评分带来相同的“惩罚”。

为了解决这个问题，CVSS4将AC定义拆分为两个指标，分别为攻击复杂度（AC）和攻击要求（AT）：

• 攻击复杂性（Attack Complexity）：表示逃避或规避防御或安全增强技术所需的利用工程复杂性。
• 攻击要求（Attack Requirements ）：表示让攻击成为可能的易受攻击组件的先决条件。

0x09 更新的指标：用户交互（User Interaction）

考虑用户交互行为与易受攻击组件之前增加了额外的细节考虑：

• None（N）：除攻击者外，不需要任何人的交互就可以利用漏洞。
• Passive（P）：被动式，成功利用这个漏洞需要目标用户对脆弱组件和攻击者的payload进行有限的交互。这些交互被认为是无意识的，不需要用户主动破坏脆弱组件中的保护。
• Active（A）：主动式，成功利用这个漏洞需要目标用户对脆弱组件和攻击者的payload进行特定的，有意识的交互，或者用户的交互会主动破坏保护机制，导致漏洞被利用。

0x0A 时间（Temporal）度量组更新为威胁（Threat）度量组

威胁度量组有以下几项改动：

• 时间度量组更名为威胁度量组。
• 修复级别（通常为O）和报告置信度（通常为C）已经停用。
• 利用代码成熟度（Exploit Code Maturity）改名为利用成熟度（Exploit Maturity）。
• 威胁度量值的对评分的影响进行了增强。

威胁度量组通过使用威胁情报来调整“合理最坏情况”的基础得分，以降低CVSS-BTE得分，用来解决许多CVSS-B得分过高的问题。

0x0B CVSS扩展框架

在CVSS4中，新定义了一种标准方法，可以扩展CVSS以包括额外的指标和指标组，同时保留官方的基础，威胁和环境指标。这种扩展性允许不同的行业，如隐私保护和汽车安全等，对那些不在CVSS核心标准范围内的因素进行评估。

0x0C 新的评分系统

新的度量组产生了变化，对应的整体评分算法也进行了更新，可以参看4.0版的评分计算器

0x0D 在向量字符串中更新版本标识

新版的向量字符串开头更新为：CVSS:4.0，例如：CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:H/SC:L/SI:H/SA:H