Common Vulnerability Scoring System version 4.0: User Guide
通用漏洞评分系统版本 4.0：用户指南

Also available in PDF format.
也可提供 PDF 格式。

Document Version: 1.0  文档版本：1.0

The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software vulnerabilities. CVSS consists of four metric groups: Base, Threat, Environmental, and Supplemental. The Base group represents the intrinsic qualities of a vulnerability that are constant over time and across user environments, the Threat group reflects the characteristics of a vulnerability that change over time, and the Environmental group represents the characteristics of a vulnerability that are unique to a user's environment. Base metric values are combined with default values that assume the highest severity for Threat and Environmental metrics to produce a score ranging from 0 to 10. To further refine a resulting severity score, Threat and Environmental metrics can then be amended based on applicable threat intelligence and environmental considerations. Supplemental metrics do not modify the final score, and are used as additional insight into the characteristics of a vulnerability. A CVSS vector string consists of a compressed textual representation of the values used to derive the score. This document provides the official specification for CVSS version 4.0.
通用漏洞评分系统（CVSS）是一个用于沟通软件漏洞特征和严重性的开放框架。CVSS 包括四个度量组：基本、威胁、环境和补充。基本组代表漏洞的内在品质，这些品质在时间和用户环境中保持不变，威胁组反映了随时间变化的漏洞特征，环境组代表特定于用户环境的漏洞特征。基本度量值与假设威胁和环境度量值最高严重性的默认值相结合，产生一个 0 到 10 的分数。为了进一步细化得到的严重性分数，可以根据适用的威胁情报和环境考虑因素修改威胁和环境度量值。补充度量值不修改最终分数，用作对漏洞特征的额外洞察。CVSS 向量字符串由用于推导分数的值的压缩文本表示组成。 本文件提供了 CVSS 版本 4.0 的官方规范。

The most current CVSS resources can be found at https://www.first.org/cvss/
当前最新的 CVSS 资源可在 https://www.first.org/cvss/找到。

CVSS is owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profit organization, whose mission is to help computer security incident response teams across the world. FIRST reserves the right to update CVSS and this document periodically at its sole discretion. While FIRST owns all rights and interest in CVSS, it licenses it to the public freely for use, subject to the conditions below. Membership in FIRST is not required to use or implement CVSS. FIRST does, however, require that any individual or entity using CVSS give proper attribution, where applicable, that CVSS is owned by FIRST and used by permission. Further, FIRST requires as a condition of use that any individual or entity which publishes CVSS data conforms to the guidelines described in this document and provides both the score and the scoring vector so others can understand how the score was derived.
CVSS 由 FIRST.Org, Inc.（FIRST）拥有和管理，FIRST 是一家位于美国的非营利组织，其使命是帮助全球的计算机安全事件响应团队。FIRST 保留自行决定定期更新 CVSS 和本文件的权力。虽然 FIRST 拥有 CVSS 的所有权利和利益，但它免费向公众许可其使用，但需遵守以下条件。使用或实施 CVSS 不需要成为 FIRST 的成员。然而，FIRST 确实要求任何使用 CVSS 的个人或实体在适用的情况下给予适当的归属，即 CVSS 由 FIRST 拥有，并经许可使用。此外，FIRST 还要求作为使用条件，任何发布 CVSS 数据的个人或实体必须遵守本文件中描述的指南，并提供得分和评分向量，以便他人了解得分是如何得出的。

Introduction  引言

This guide supplements the Common Vulnerability Scoring System (CVSS) version 4.0 Specification Document with additional information including significant changes from CVSS version 3.1, additional scoring guidance, and scoring rubrics.
本指南补充了通用漏洞评分系统（CVSS）版本 4.0 规范文档，包括从 CVSS 版本 3.1 的重大变更、额外的评分指南和评分标准。

Changes in CVSS Version 4.0
CVSS 版本 4.0 的变化

Changes between CVSS versions 3.x and 4.0 focus on clarifying and improving the existing standard.
CVSS 版本 3.x 与 4.0 之间的变化主要关注澄清和改进现有标准。

CVSS Nomenclature  CVSS 命名法

Numerical CVSS Scores have very different meanings based on the metrics used to calculate them. Regarding prioritization, the usefulness of a numerical CVSS score is directly proportional to the CVSS metrics leveraged to generate that score. Therefore, numerical CVSS scores should be enumerated using nomenclature that communicates the metrics used in its generation.
数值 CVSS 评分根据计算它们的指标具有非常不同的含义。关于优先级，数值 CVSS 评分的有用性与生成该评分所使用的 CVSS 指标成正比。因此，应使用传达其生成所使用指标的命名法来列举数值 CVSS 评分。

CVSS Nomenclature  CVSS 命名法	CVSS Metrics Used  CVSS 度量指标
CVSS-B	Base metrics  基础指标
CVSS-BE	Base and Environmental metrics 基础和环境指标
CVSS-BT	Base and Threat metrics 基础和威胁指标
CVSS-BTE	Base, Threat, Environmental metrics 基础，威胁，环境指标

Additional Notes:  附加说明：

• This nomenclature should be used wherever a numerical CVSS value is displayed or communicated.
  此命名法应适用于显示或传达数值 CVSS 值的所有场合。

• The application of Environmental and Threat metrics is the responsibility of the CVSS consumer. Assessment providers such as product maintainers and other public/private entities such as the National Vulnerability Database (NVD) typically provide only the Base Scores enumerated as CVSS-B.
  环境威胁指标的运用是 CVSS 消费者的责任。评估提供者，如产品维护者以及其他公共/私人实体，如国家漏洞数据库（NVD），通常仅提供按 CVSS-B 列出的基本分数。

• The inclusion of the “E” in the nomenclature is appropriate if any Environmental metrics are used to generate the resulting score.
  在命名法中包含“E”是合适的，如果使用任何环境指标来生成最终得分。

• The inclusion of the “T” in the nomenclature is appropriate if any Threat metrics are used to generate the resulting score.
  在命名法中包含“T”是合适的，如果使用了任何威胁指标来生成最终得分。

• In CVSS v4.0, Base, Threat, and Environmental metric values are always considered in the calculation of the final score. The absence of explicit Threat and/or Environmental metric selections will still result in a complete score using default (“Not Defined”) values. This nomenclature makes it explicit and clear about which metric groups were considered in the numerical CVSS score provided.
  在 CVSS v4.0 中，基础、威胁和环境度量值始终在计算最终得分时被考虑。即使没有明确选择威胁和/或环境度量值，也会使用默认值（“未定义”）来计算完整的得分。这种命名法明确且清晰地说明了在提供的数值 CVSS 得分中考虑了哪些度量组。

CVSS Base Score (CVSS-B) Measures Severity, not Risk
CVSS 基础评分（CVSS-B）衡量严重程度，而非风险

The CVSS Specification Document has been updated to emphasize and clarify the fact that CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk.
CVSS 规范文档已更新，强调并阐明 CVSS 基础（CVSS-B）评分旨在衡量漏洞的严重性，不应单独用于评估风险。

The CVSS v4.0 Specification Document clearly states that the CVSS Base Score represents only the intrinsic characteristics of a vulnerability and is independent of any factor associated with threat or the computing environment where the vulnerable system resides.
CVSS v4.0 规范文档明确指出，CVSS 基础分数仅代表漏洞的固有特征，与任何与威胁或漏洞系统所在计算环境相关的因素无关。

The CVSS Base Score should be supplemented with an analysis of the environment (Environmental Metrics), and with attributes that may change over time (Threat Metrics).
CVSS 基本分数应辅以对环境（环境指标）的分析，以及可能随时间变化的属性（威胁指标）。

For an organization that employs automated methods to comprehensively utilize the Environmental and Threat metric groups, the resulting CVSS-BTE score can be considered much closer to “Risk”.
对于一个采用自动化方法全面利用环境和威胁度量组的企业，其产生的 CVSS-BTE 评分可以认为更接近“风险”。

Changes to Assessment Guidance
评估指南的变更

The CVSS Specification Document and User Guide have been updated with additional guidance to help CVSS analysts produce resulting severity scores that are consistent and defensible across various situations that were previously considered ambiguous. A sampling of the new assessment guidance is listed below.
CVSS 规范文档和用户指南已更新，增加了额外的指导，以帮助 CVSS 分析师产生在各种先前被认为是模糊的情况下的结果严重性评分，保持一致性和可辩护性。以下列出了新的评估指导的样本。

Scope Removed  范围已移除

The concept of Scope has been replaced with the concepts of a vulnerable system (VC, VI, VA) and a subsequent system (SC, SI, SA), capturing impacts from both, where relevant. Refer to Section 3.7 for more information.
范围的概念已被易损系统（VC、VI、VA）和后续系统（SC、SI、SA）的概念所取代，捕捉了相关影响。有关更多信息，请参阅第 3.7 节。

Assessing Vulnerabilities in Software Libraries (and Similar)
评估软件库（及其类似）中的漏洞

New guidance explains how to assess the impact of a vulnerability in a library. Refer to Section 3.9 for more information.
新指南解释了如何评估库中漏洞的影响。请参阅第 3.9 节以获取更多信息。

Multiple CVSS Base (CVSS-B) Scores
多个 CVSS 基础（CVSS-B）评分

Guidance explicitly allows multiple CVSS Base Scores to be generated for a vulnerability that affects multiple product versions, platforms, and/or operating systems. Refer to Section 3.10 for more information.
指导明确允许为受多个产品版本、平台和/或操作系统影响的漏洞生成多个 CVSS 基础评分。有关更多信息，请参阅第 3.10 节。

Guidance for Using Environmental Security Requirements Metrics
环境安全要求指标使用指南

The Environmental Metric Group includes three Security Requirement metrics: Confidentiality Requirement of the vulnerable system (CR), Integrity Requirement of the vulnerable system (IR), and Availability Requirement of the vulnerable system (AR). Section 3.14 contains new guidance and examples explaining how these metrics can be used.
环境度量组包括三个安全需求度量指标：脆弱系统的机密性需求（CR）、脆弱系统的完整性需求（IR）和脆弱系统的可用性需求（AR）。第 3.14 节包含新的指导和示例，解释了如何使用这些指标。

Guidance for Using Supplemental Metrics
使用补充指标的指南

Guidance on assessing each of the new Supplemental Metrics is provided in Section 4.0.
第 4.0 节提供了评估每个新补充指标的指南。

New Base Metric: Attack Requirements
新基准指标：攻击需求

In CVSS v3.1, the “low” and “high” Attack Complexity (AC) values do not reflect the significant differences between conditions currently compressed in the definition of “high” complexity. For example, the evasion of security mitigation techniques such as ASLR or crypto objectively require significantly higher exploit complexity than iterating an attack to win a race condition; yet both conditions currently result in the same “penalty” to the final severity score.
在 CVSS v3.1 中，“低”和“高”攻击复杂度（AC）值并未反映当前在“高”复杂度定义中压缩的条件之间的显著差异。例如，绕过如 ASLR 或加密等安全缓解技术的逃避行为，客观上需要比迭代攻击以赢得竞争条件更高的利用复杂度；然而，这两种条件目前都导致对最终严重程度评分相同的“惩罚”。

CVSS v4.0 aims at addressing this by splitting the current AC definition in two metrics, called “Attack Complexity” (AC) and “Attack Requirements” (AT) that respectively convey the following:
CVSS v4.0 通过将当前的攻击复杂度（AC）定义分为两个指标，即“攻击复杂度”（AC）和“攻击需求”（AT），分别传达以下内容：

• Attack Complexity - Reflect the exploit engineering complexity required to evade or circumvent defensive or security-enhancing technologies. (defensive measures)
  攻击复杂性 - 反映规避或绕过防御或增强安全技术的利用工程复杂性。（防御措施）

• Attack Requirements - Reflect the prerequisite conditions of the vulnerable component that make the attack possible.
  攻击需求 - 反映使攻击成为可能的脆弱组件的先决条件。

Updated Base Metric: User Interaction
更新基础指标：用户互动

The User Interaction Base Metric has been updated to allow for additional granularity when considering the interaction of a user with a vulnerable component, and details are as follows:
用户交互基础指标已更新，以便在考虑用户与易受攻击组件的交互时提供更细粒度的分析，具体如下：

• None (N): The vulnerable system can be exploited without interaction from any human user, other than the attacker.
  无（N）：易受攻击的系统可以在没有任何人类用户（除了攻击者）交互的情况下被利用。

• Passive (P): Successful exploitation of this vulnerability requires limited interaction by the targeted user with the vulnerable component and the attacker’s payload. These interactions would be considered involuntary and do not require that the user actively subvert protections built into the vulnerable component.
  被动（P）：成功利用此漏洞需要目标用户与受影响组件以及攻击者的有效载荷进行有限的交互。这些交互被视为非自愿的，且不需要用户主动绕过受影响组件中内置的保护措施。

• Active (A): Successful exploitation of this vulnerability requires a targeted user to perform specific, conscious interactions with the vulnerable component and the attacker’s payload, or the user’s interactions would actively subvert protection mechanisms which would lead to exploitation of the vulnerability.
  活动（A）：成功利用此漏洞需要目标用户与受漏洞影响的组件和攻击者的有效载荷进行特定、有意识的交互，否则用户的交互将主动破坏保护机制，从而导致漏洞被利用。

Temporal renamed to the Threat Metric Group
时间度量组更名为威胁度量组

Several changes were made to the Temporal Metric Group:
对时间度量组进行了几项修改：

• Temporal Metric Group renamed to Threat Metric Group
  时间度量组更名为威胁度量组

• Remediation Level (usually O) and Report Confidence (usually C) retired
  修复等级（通常为 O）和报告置信度（通常为 C）已退役

• Exploit Code Maturity renamed Exploit Maturity
  利用代码成熟度更名为利用成熟度

• Enhanced impact for Threat Metric values
  增强威胁度量值的影响

The Threat Metric Group adjusts the “reasonable worst case” Base score by using threat intelligence to reduce the CVSS-BTE score, addressing concerns that many CVSS (Base) scores are too high.
威胁度量组通过使用威胁情报调整“合理最坏情况”基础得分，以降低 CVSS-BTE 得分，解决许多 CVSS（基础）得分过高的担忧。

The CVSS Extensions Framework
CVSS 扩展框架

Section 3.11 defines a standard method of extending CVSS to include additional metrics and metric groups while retaining the official Base, Threat, and Environmental Metrics. The additional metrics allow industry sectors such as privacy, automotive, etc., to assess factors that are outside the core CVSS standard.
第 3.11 节定义了一种将 CVSS 扩展到包括额外指标和指标组的标准方法，同时保留官方的基线、威胁和环境指标。这些额外指标允许诸如隐私、汽车等行业评估 CVSS 核心标准之外的因素。

New Scoring System Development
新评分系统开发

The scoring system development for CVSS v4.0 consisted of the following broad steps. Each step will be described in more detail in the following.
CVSS v4.0 评分系统开发包括以下几个主要步骤。以下将详细描述每个步骤。

1. Use metric groups to gather the 15 million CVSS-BTE vectors into 270 equivalence sets
   使用度量组将 1500 万个 CVSS-BTE 向量聚集成 270 个等价集

2. Solicit experts to compare vectors representing each equivalence set
   征求专家比较代表每个等价类向量的向量

3. Use the expert comparison data to calculate an order of vectors from least severe to most severe
   利用专家比较数据，从最轻微到最严重计算向量顺序

4. Solicit expert opinion to decide what vector group in the ordering of vectors represents the boundary between qualitative severity scores to be backwards compatible with qualitative severity score boundaries from CVSS v3.x.
   征求专家意见，以确定在向量排序中哪个向量组代表与 CVSS v3.x 的定性严重程度得分边界向后兼容的定性严重程度得分边界。

5. Compress the vector groups in each qualitative severity bin into the number of available scores in that bin (for example, 9.0 to 10.0 for critical, 7.0 to 8.9 for high, etc.)
   将每个定性严重程度组中的向量压缩到该组中可用的分数数量（例如，对于危急，为 9.0 到 10.0；对于高，为 7.0 到 8.9 等）。

6. Create a small score modification factor that adjusts the scores of vectors within a vector group so that a change of any metric value results in a score change. The intent is that the score change is not larger than the uncertainty in the ranking of the vector groups as collected from the expert comparison data in step 2.
   创建一个小的分数调整因子，以调整向量组内向量的分数，使得任何度量值的变化都导致分数变化。目的是分数变化不超过从步骤 2 中收集的专家比较数据中向量组排名的不确定性。

More details for each of these six steps are as follows:
每个这六个步骤的更多细节如下：

Use metric groups to gather the 15 million CVSS-BTE vectors into 270 equivalence sets
使用度量组将 1500 万个 CVSS-BTE 向量聚集成 270 个等价集

This step helps satisfy a couple of design requirements. One is that there are 101 CVSS scores (0.0 to 10.0 by 0.1). The second is that we create the scoring system using no more time from experts than we have available on a volunteer basis to the SIG. How this helps meet the first requirement is straightforward – there has to be some grouping of all the possible vectors because many of them will have to share a score if there are 15 million options and 101 possible scores. How this step reduces expert effort into the system is less obvious, and will be more clear in step 2. The basic idea is that 15 million vectors are too many for experts to individually rank all of them in any plausibly-achievable amount of time. This is especially true because any sorting algorithm takes a number of comparisons proportional to the number of elements to be sorted. Usually, the work grows in an order faster than the list size (in computational terms, order nlog(n), see Sorting algorithm - Wikipedia). The impact on scoring system design is that if we want to get smart input about the whole CVSS vector space we have to assert some rules about it that help us make structured use of the data we collect from the expert analysts.
这一步有助于满足几个设计要求。一是存在 101 个 CVSS 评分（0.0 到 10.0，以 0.1 为步长）。二是我们创建评分系统时，所需专家时间不超过 SIG 志愿者可提供的时间。如何满足第一个要求是显而易见的——由于有 1500 万个选项和 101 个可能的评分，许多向量必须共享一个评分。这一步如何减少系统中的专家工作量不太明显，将在第二步中更加清晰。基本思路是，1500 万个向量对于专家来说，在可实现的任何合理时间内，都无法逐一进行排名。这尤其是因为任何排序算法都需要与待排序元素数量成比例的比较次数。通常，工作量增长的速度比列表大小（从计算的角度看，为 nlog(n)，参见排序算法 - 维基百科）要快。 对评分系统设计的影响是，如果我们想获取关于整个 CVSS 向量空间的全局智能输入，我们必须对其提出一些规则，这些规则有助于我们结构化地使用从专家分析师那里收集到的数据。

Solicit experts to compare vectors representing each equivalence set
征求专家比较代表每个等价类向量的向量

With the total number of items to compare reduced from 15 million to 270, it was feasible to ask experts to compare each element to each other element and totally order the severity of the metric-group-based qualitative sets of vectors. This is an attractive idea because the SIG could define a score for every possible BTE vector based on input from every interested SIG member in a repeatable and private way without sampling from the CVSS vector space. That is, we could generate a score for each possible vector based on their membership in the metric-group-based qualitative sets and the relative severity of those sets.
将比较的项目总数从 1500 万减少到 270 后，可以请专家将每个元素与其他每个元素进行比较，并对基于度量组的质量向量集的严重程度进行完全排序。这是一个吸引人的想法，因为 SIG 可以根据每个感兴趣的 SIG 成员的输入，以可重复和私密的方式为每个可能的 BTE 向量定义一个分数，而不从 CVSS 向量空间中进行采样。也就是说，我们可以根据每个向量在基于度量组的质量集中的成员资格以及这些集的相对严重程度为每个可能的向量生成一个分数。

Use the expert comparison data to calculate an order of vectors from least severe to most severe
利用专家比较数据，从最轻微到最严重计算向量顺序

The expert comparisons are used as if the metric-group-based vector sets are competing in a match, and we want to rank the vector sets from "best" to "worst". The algorithm used to turn these expert comparisons into a ranking is the same as the algorithm used to take outcomes of chess matches (comparisons) to rank chess players from best to worst. The name of this algorithm is Elo (Elo rating system - Wikipedia). The output of the algorithm is a set of "raw" scores called "points". The interpretation of the point scores for each vector set is that if a vector-set has a score 100 points higher than another vector-set, then that score difference predicts that an expert would rate the higher-scored vector set as "more severe" a certain percentage of the time. In the chess metaphor, would win the match a certain percentage of the time. The bigger the point-score difference, the larger the chance the higher-scored vector would be rated as more severe. There are details of how exactly to configure and run the Elo scoring algorithm that matter; however, through a SIG-led feedback process, we found the configuration details tend to converge on a similar set of values. Therefore, we believe the Elo algorithm output is stable and represents a reliable transformation from the diverse expert opinion inputs to a single severity ordering of the metric-group-based vector sets.
专家比较被用作如果基于度量组向量的集合在比赛中竞争，我们希望从“最好”到“最差”对向量集合进行排名。将这些专家比较转化为排名的算法与用于将象棋比赛（比较）的结果排名从最好到最差的算法相同。这个算法的名称是 Elo（Elo 评分系统 - 维基百科）。算法的输出是一组称为“原始”得分的“分数”。对于每个向量集合的分数解释是，如果一个向量集合的分数比另一个向量集合高 100 分，那么这种分数差异预测专家会有一定比例的时间将得分更高的向量集合评为“更严重”。在象棋隐喻中，会有一定比例的时间赢得比赛。分数差异越大，得分更高的向量被评为更严重的可能性就越大。如何具体配置和运行 Elo 评分算法的细节很重要；然而，通过 SIG 领导的反馈过程，我们发现配置细节往往收敛到一组相似的价值。 因此，我们认为 Elo 算法的输出是稳定的，并且能够可靠地将来自不同专家意见的输入转换为基于指标组的向量集的单个严重程度排序。

Solicit expert opinion to decide what vector group in the ordering of vectors represents the boundary between qualitative severity scores to be backwards compatible with qualitative severity score boundaries from CVSS v3.x.
征求专家意见，以确定在向量排序中哪个向量组代表与 CVSS v3.x 的定性严重程度得分边界向后兼容的定性严重程度得分边界。

Before mapping the 270 metric-group-based vector sets to scores between 0.0 and 10.0, the SIG wanted to improve backwards compatibility with CVSS v3 scores. To do this, the SIG wanted to decide which metric-group-based vector sets define the qualitative severity set boundaries. The output of step 3 was a total ordering of the vector sets. In deciding the qualitative severity boundaries, the SIG did not change the ordering output by step 3. Rather, the SIG wanted to decide what CVSS v4 B vector set represented the boundary between critical and high, high and medium, and medium and low. This was determined by soliciting input from the 30+ member CVSS SIG. Five (5) members contributed input in the form of marking the three boundaries in the ordering of vector sets. The SIG's then defined the boundaries as the average of the 5 SIG members' selections.
在将基于 270 个度量组向量的集合映射到 0.0 到 10.0 的分数之前，SIG 希望提高与 CVSS v3 分数的后向兼容性。为此，SIG 希望决定哪些基于度量组向量的集合定义了定性严重性集合的边界。第 3 步的输出是向量集的总排序。在决定定性严重性边界时，SIG 没有改变第 3 步输出的排序。相反，SIG 希望决定 CVSS v4 B 向量集合代表关键与高、高与中、中与低的边界。这是通过征求 30 多个 CVSS SIG 成员的意见来确定的。五名（5）成员以在向量集排序中标记三个边界的形式提供了意见。SIG 随后将边界定义为 5 名 SIG 成员选择的平均值。

Compress the vector groups in each qualitative severity bin into the number of available scores in that bin (for example, 9.0 to 10.0 for critical, 7.0 to 8.9 for high, etc.)
将每个定性严重程度组中的向量压缩到该组中可用的分数数量（例如，对于危急，为 9.0 到 10.0；对于高，为 7.0 到 8.9 等）。

The second part of maintaining backwards compatibility with CVSS v3 was keeping the score ranges for each qualitative severity value the same. The result of the total ordering (step 3) and qualitative severity boundaries (step 4) resulted in the following number of metric-group-based vector sets in each qualitative severity value. Note that each vector set has a different number of CVSS v4.0 BTE vectors. However, the SIG does not believe that counting total number of possible CVSS v4.0 BTE vectors is a relevant way to assess lumpiness of CVSS v4 BTE scores. For example, as of April 2023, there are less than 200,000 total CVE IDs to date since the inception of the program. Even if 15 million CVSS v4 BTE scores are possible, many will never be assigned to a CVE ID since there are so many fewer CVE IDs than vectors. A better assessment of the distribution of CVSS v4 BTE scores will have to be an empirical assessment of how many times a vector string actually recurs in actual CVE ID assessments.
维护与 CVSS v3 向后兼容的第二部分是保持每个定性严重性值的评分范围相同。总排序（步骤 3）和定性严重性边界（步骤 4）的结果导致每个定性严重性值基于度量组向量的集合数量如下。请注意，每个向量集合具有不同数量的 CVSS v4.0 BTE 向量。然而，SIG 认为，计算可能的 CVSS v4.0 BTE 向量的总数并不是评估 CVSS v4 BTE 评分粗糙度的相关方法。例如，截至 2023 年 4 月，自该计划启动以来，CVE ID 总数不到 20 万个。即使可能的 CVSS v4 BTE 评分有 1500 万个，由于 CVE ID 的数量远少于向量，许多评分将永远不会分配给 CVE ID。对 CVSS v4 BTE 评分分布的更好评估将需要对向量字符串在实际 CVE ID 评估中实际出现的次数进行经验评估。

Salient to the creation of the scoring system, CVSS v4.0 scoring system was created as 4 (four) scoring systems created for each qualitative severity score (critical, high, medium, low), as well as None as a special case for 0.0. Each qualitative severity score contains a different number of metric-group-based vector sets and a different number of available scores. The same algorithm is used for creating a scoring system meeting the requirements for each of critical, high, medium, and low. That algorithm is agglomerative hierarchical clustering (Hierarchical clustering - Wikipedia), which makes sure that vector sets that share the same CVSS v4 BTE score also have the smallest difference between their Elo-point scores.
与评分系统的创建密切相关，CVSS v4.0 评分系统被创建为 4（四个）评分系统，每个针对定性严重程度得分（严重、高、中、低），以及 0.0 的特殊情况“无”。每个定性严重程度得分包含不同数量的基于度量组向量集和不同数量的可用得分。创建满足严重、高、中、低要求的评分系统使用相同的算法。该算法是聚类层次聚类（层次聚类 - 维基百科），确保具有相同 CVSS v4 BTE 得分的向量集之间 Elo 得分差异最小。

Create a small score modification factor that adjusts the scores of vectors within a vector group so that a change of any metric value results in a score change. The intent is that the score change is not larger than the uncertainty in the ranking of the vector groups as collected from the expert comparison data in step 2.
创建一个小的分数调整因子，以调整向量组内向量的分数，使得任何度量值的变化都导致分数变化。目的是分数变化不超过从步骤 2 中收集的专家比较数据中向量组排名的不确定性。

The result of step 5 is an option for a CVSS v4.0 scoring system. In order to meet a requirement that any change in a metric value result in at least a 0.1 change in the CVSS v4 BTE score, the SIG added an additional step to create a small change in the score based on metric value changes within metric-group-based vector sets. The vector sets are totally ordered, but of course especially small differences in vector set Elo-point-scores represent situations where there were a number of experts who disagreed with the resultant ordering. Providing a small change based on metric values within vector sets allows the slightly-more-severe metric strings within a vector set to overlap the slightly-less-severe metric strings from a nearby but slightly-more-severe metric-group-based vector set. These small shifts account for the fact that every vector within an equivalence set is not identical even if they are importantly and saliently equivalent enough to enable expert opinion ranking to be possible.
步骤 5 的结果是 CVSS v4.0 评分系统的一个选项。为了满足任何指标值的变化至少导致 CVSS v4 BTE 评分变化 0.1 的要求，SIG 增加了一个额外步骤，根据基于指标组向量的指标值变化来创建评分的小幅度变化。向量集是完全有序的，但当然，向量集 Elo 点分数的小幅度差异代表了有多个专家对结果排序存在不同意见的情况。基于向量集内的指标值提供的小幅度变化允许向量集中略微严重的指标字符串与来自附近但略微严重的基于指标组的向量集的略微轻微的指标字符串重叠。这些小幅度变化解释了即使向量在等价集中不是完全相同，只要它们在重要性和显著性上足够等效，以使专家意见排序成为可能。

The basic intuition behind these small adjustments is that the CVSS metric values are ordered within each metric. For example, AV:N is more severe than AV:A, which is more severe than AV:L, which is more severe than AV:P. There is a similar ordering for all other metrics. Therefore, it is plausible to algorithmically define a change in CVSS v4 BTE score based on this ordering. That is, the expert opinion was used to sort the big-picture ordering of qualitatively important differences. The small changes in metric value that are not salient to a metric-group-based equivalence set change can still be used to represent a small change in the score that is consistent with the Elo-point difference interpretation of how likely an expert is to rate one vector set as more severe than another.
这些小调整背后的基本直觉是，CVSS 指标值在每个指标内是有序的。例如，AV:N 比 AV:A 严重，AV:A 比 AV:L 严重，AV:L 比 AV:P 严重。所有其他指标也有类似的排序。因此，根据这种排序，可以算法性地定义 CVSS v4 BTE 分数的变化。也就是说，专家意见被用来对定性重要差异的大致排序进行排序。那些对基于指标组等价集变化不显著的指标值的小变化，仍然可以用来表示与 Elo 积分差异解释一致的小分数变化，即专家认为一个向量集比另一个向量集更严重的可能性。

Update to the Version Identifier in the Vector String
向量字符串版本标识符更新

The Vector String has been updated so that it begins with CVSS:4.0 rather than CVSS:3.1. Although no other changes have been made to the Vector String, CVSS v4.0 contains changes to the definition of some of the metric values and to the formulas, so it is important to correctly indicate the version of CVSS.
向量字符串已更新，现在以 CVSS:4.0 开头，而不是 CVSS:3.1。尽管向量字符串没有其他更改，但 CVSS v4.0 对某些度量值的定义和公式进行了更改，因此正确指出 CVSS 版本很重要。

Assessment Guide  评估指南

Below are a number of recommendations for consumers when assessing vulnerabilities with CVSS v4.0.
以下是在评估 CVSS v4.0 漏洞时对消费者的一些建议。

Integrate Vulnerability Scan results with Asset Management
整合漏洞扫描结果与资产管理

It is highly recommended to enrich the results from vulnerability scanning solutions with asset data. Often, asset management data is kept in a database that can easily be integrated with vulnerability scan data. Not only will this step enable a Vulnerability Management team to utilize the Environmental Metric Group to improve the quality of the resulting CVSS scores, the engineers responsible for remediating identified vulnerabilities will have more information at their disposal.
强烈建议通过资产数据丰富漏洞扫描解决方案的结果。通常，资产管理数据保存在可以轻松与漏洞扫描数据集成的数据库中。这一步骤不仅将使漏洞管理团队能够利用环境度量组来提高 CVSS 评分的质量，而且负责修复已识别漏洞的工程师将拥有更多信息可供使用。

For example, vulnerability scans are conducted against 100 servers. Among other details, scan results provide the hostname, vulnerability, and the CVSS Base (CVSS-B) score. The Asset Management database contains records for all servers where each one contains values for Asset Class, Confidentiality Requirements, Integrity Requirements, Availability Requirements, and Exposure (Internet or Internally facing). Once this information is integrated using automation, the result is a CVSS-BE score that takes those environmental factors into consideration. Additionally, the Asset Class and similar information can be used to get the vulnerability to the right engineers for remediation.
例如，对 100 台服务器进行漏洞扫描。扫描结果包括主机名、漏洞和 CVSS 基础（CVSS-B）评分等详细信息。资产管理数据库包含所有服务器的记录，其中每个记录包含资产类别、机密性要求、完整性要求、可用性要求和暴露（互联网或内部）的值。一旦使用自动化集成这些信息，结果就是考虑了这些环境因素的 CVSS-BE 评分。此外，资产类别和类似信息可用于将漏洞分配给适当的工程师进行修复。

Integrate Vulnerability Scan results with Threat Intelligence
整合漏洞扫描结果与威胁情报

Perhaps one of the most important facets of improving the result of a CVSS assessment is the application of Threat Data and the use of the Exploit Maturity (E) metric. Knowing which vulnerabilities have been exploited in the past should have a significant impact on the resulting score.
CVSS 评估结果改进最重要的方面之一是威胁数据的运用以及利用成熟度（E）指标的使用。了解过去哪些漏洞已被利用，应会对最终得分产生重大影响。

There are many sources that can provide threat intelligence regarding the Exploit Maturity of vulnerabilities. Many of these sources are publicly available for free and others are offered by commercial organizations for a subscription cost.
有许多来源可以提供关于漏洞利用成熟度的威胁情报。其中许多来源是免费公开的，而其他一些则由商业组织提供，需付费订阅。

It is important to understand that none of these sources are perfect and it is highly recommended to gather multiple sources of threat intelligence to improve the comprehensiveness and fidelity of the information being used to enrich your vulnerability data.
理解这些来源都不是完美的至关重要，强烈建议收集多个威胁情报来源，以提高用于丰富您的漏洞数据的全面性和准确性。

The application of the threat intelligence should be matched against vulnerability scan data using automation. The result will be a much more accurate measurement of the priority that should be applied to those vulnerabilities being assessed.
威胁情报的应用应与漏洞扫描数据通过自动化进行匹配。这将使对被评估漏洞的优先级应用得到更准确的测量。

CVSS Scoring in the Exploit Life Cycle
CVSS 评分在漏洞生命周期中的应用

When understanding when to assess the impact of vulnerabilities, analysts should constrain impacts to a reasonable, final outcome which they are confident an attacker is able to achieveFor example, consider the following two vulnerabilities.
在理解何时评估漏洞影响时，分析师应将影响限制在合理、最终的结果范围内，他们对此有信心认为攻击者能够实现。例如，考虑以下两个漏洞。

In vulnerability 1, a remote, unauthenticated attacker can send a trivial, crafted request to a web server which causes the web server to disclose the plaintext password of the root (administrator) account. The analyst only knows from the vulnerability description that the attacker has access to send a crafted request to the web server in order to exploit the vulnerability. Impact should stop there; while an attacker may be able to use these credentials to later execute code as the administrator, it is not known that the attacker has access to a login prompt or method to execute commands with those credentials. Gaining access to this password represents a direct, serious loss of Confidentiality only:
在漏洞 1 中，一个远程未认证的攻击者可以向 Web 服务器发送一个简单的、精心制作的请求，导致 Web 服务器泄露 root（管理员）账户的明文密码。分析师只知道从漏洞描述中，攻击者有权向 Web 服务器发送精心制作的请求以利用该漏洞。影响应该到此为止；虽然攻击者可能能够使用这些凭证后来以管理员身份执行代码，但尚不清楚攻击者是否有权访问登录提示或使用这些凭证执行命令。获取此密码仅代表直接、严重的保密性损失：

CVSS-B Score: 8.8 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N)
CVSS-B 评分：8.8（CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N）

In vulnerability 2, a local, low-privileged user can send a trivial, crafted request to the operating system which causes it to disclose the plaintext password of the root (administrator) account. The analyst knows from the vulnerability description that the attacker has access to the operating system, and can log in as a local, low privileged attacker. Gaining access to this password represents a direct, serious loss of Confidentiality, Integrity, and Availability because the analyst can reasonably issue commands as the root / administrator account (assume that the attacker could log out from their own account and log back in as root):
在漏洞 2 中，一个本地低权限用户可以向操作系统发送一个简单定制的请求，导致其泄露 root（管理员）账户的明文密码。分析师从漏洞描述中知道攻击者可以访问操作系统，并可以以本地低权限攻击者的身份登录。获取此密码代表直接严重的机密性、完整性和可用性损失，因为分析师可以合理地以 root/管理员账户发出命令（假设攻击者可以从自己的账户注销并重新登录为 root）：

CVSS-B Score: 8.5 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)
CVSS-B 评分：8.5（CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N）

Confidentiality and Integrity, Versus Availability Impacts
保密性与完整性，与可用性影响

The Confidentiality and Integrity metrics refer to impacts that affect the data used by the service. For example, web content that has been maliciously altered, or system files that have been stolen. The Availability impact metric refers to the operation of the service. That is, the Availability metric speaks to the performance and operation of the service itself – not the availability of the data. Consider a vulnerability in an Internet service such as web, email, or DNS that allows an attacker to modify or delete all web files in a directory. The only impact is to Integrity, not Availability, as the web service is still functioning – it just happens to be serving back altered content.
保密性和完整性指标指的是影响服务使用的数据的影响。例如，被恶意篡改的网页内容或被盗的系统文件。可用性影响指标指的是服务的运行。也就是说，可用性指标涉及服务本身的性能和运行，而不是数据的可用性。考虑一个互联网服务（如网页、电子邮件或 DNS）中的漏洞，该漏洞允许攻击者修改或删除目录中的所有网页文件。唯一的影响是完整性，而不是可用性，因为网页服务仍在运行——只是恰好返回了被篡改的内容。

Local Vulnerabilities Exploited by Remote Attackers
本地漏洞被远程攻击者利用

Guidance concerning Local attacks was improved by clarifying the definitions of the Network and Adjacent values of the Attack Vector metric. Specifically, analysts should only assess Network or Adjacent when a vulnerability is bound to the network stack. Vulnerabilities which require user interaction to download or receive malicious content (which could also be delivered locally should be assessed as Local.
关于本地攻击的指导通过明确攻击向量度量的网络和相邻值的定义得到了改进。具体来说，分析师只有在漏洞绑定到网络堆栈时才应评估网络或相邻。需要用户交互下载或接收恶意内容（也可能本地交付）的漏洞应被视为本地。

For example, a document parsing vulnerability, which does not rely on the network in order to be exploited, should typically be assessed as Local, regardless of the method used to distribute such a malicious document (e.g., it could be a link to a website).
例如，一种不依赖于网络即可被利用的文档解析漏洞，通常应被视为本地漏洞，无论使用何种方法分发这种恶意文档（例如，可能是一个指向网站的链接）。

Vulnerability Chaining  漏洞链

CVSS is designed to classify and rate individual vulnerabilities. However, it is important to support the needs of the vulnerability analysis community by accommodating situations where multiple vulnerabilities are exploited in the course of a single attack to compromise a host or application. The assessment of multiple vulnerabilities in this manner is termed “vulnerability chaining.” Note that this is not a formal metric, but is included as guidance for analysts when assessing these kinds of attacks.
CVSS 旨在对单个漏洞进行分类和评级。然而，支持漏洞分析社区的需求，通过适应在单一攻击过程中利用多个漏洞以破坏主机或应用程序的情况，这一点很重要。以这种方式评估多个漏洞被称为“漏洞链”。请注意，这并非正式指标，但作为分析师评估此类攻击时的指导。

When assessing a chain of vulnerabilities, it is the responsibility of the analyst to identify which vulnerabilities are combined to form the chained resulting score. The analyst should list the distinct vulnerabilities and their resulting score along with the chained resulting score. For example, this may be communicated within a vulnerability disclosure notice posted on a web page.
在评估漏洞链时，分析员的责任是确定哪些漏洞组合形成了链式结果得分。分析员应列出不同的漏洞及其结果得分，以及链式结果得分。例如，这可以在网页上发布的漏洞披露通知中传达。

In addition, the analyst may include other types of related vulnerabilities that could be chained with the vulnerabilities being assessed. Specifically, the analyst may list generic types (or classes) of related vulnerabilities that are often chained together, or provide further descriptions of required preconditions that must exist. For example, one might describe how certain kinds of SQL Injection vulnerabilities are precursors to a cross-site scripting (XSS) attack, or how a particular kind of buffer overflow would grant local privileges. Listing the generic types or classes of vulnerabilities provides the minimum information necessary to warn other users, without potentially informing attackers about new exploit opportunities.
此外，分析师可能还会包括其他与正在评估的漏洞相关的漏洞类型，这些漏洞可以与正在评估的漏洞串联起来。具体来说，分析师可能会列出常见的相关漏洞类型（或类别），这些类型通常会被串联起来，或者提供必须存在的先决条件的进一步描述。例如，可能会描述某些类型的 SQL 注入漏洞是如何成为跨站脚本（XSS）攻击的先导，或者某种特定的缓冲区溢出会如何赋予本地权限。列出漏洞的通用类型或类别提供了警告其他用户所需的最少信息，而不会无意中向攻击者透露新的利用机会。

Alternatively, the analyst may identify (in the form of a machine readable and parsable list of vulnerabilities as CVE IDs or CWEs), a complete list of specific related vulnerabilities that are known to be (or are very likely to be) chained to one or more of the chained vulnerabilities being assessed in order to exploit an IT system. In the event that a vulnerability can be exploited only after other preconditions are met (such as first exploiting another vulnerability), it is acceptable to combine two or more CVSS scores to describe the chain of vulnerabilities by assessing the least-restrictive Exploitability metrics and assessing the most-impactful Impact metrics. The following example uses the Exploitability and Impact assessment to describe the chain.
此外，分析师可能以机器可读和可解析的漏洞列表（CVE ID 或 CWE）的形式识别出已知（或极有可能）与正在评估的链式漏洞之一或多个相关联的特定相关漏洞的完整列表，以利用 IT 系统。如果只有满足其他先决条件（如首先利用另一个漏洞）后才能利用漏洞，则可以将两个或多个 CVSS 评分合并，通过评估最宽松的可利用性指标和评估最具影响力的影响指标来描述漏洞链。以下示例使用可利用性和影响评估来描述漏洞链。

Vulnerability A is CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
漏洞 A 是 CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
It requires a local, low-privileged user in order to exploit.
需要本地低权限用户才能利用。

Vulnerability B is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
漏洞 B 是 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
It provides an unprivileged, remote attacker the ability to execute code on a system with Low impacts if a local user interacts to complete the attack.
它使未授权的远程攻击者能够在本地用户交互以完成攻击的情况下，以低影响在系统上执行代码。

Given A and B, Chain C could be described as the chain of B → A,
给定 A 和 B，链 C 可以描述为 B → A 的链
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N which combines the Exploitability of B, and the Impact of A, because if one can exploit B and gain the code execution as a local user from it, then one has satisfied the prerequisite to subsequently launch A causing an impact from vulnerability A.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N 结合了 B 的利用性和 A 的影响，因为如果一个人能够利用 B 并从它那里获得本地用户的代码执行，那么他就满足了随后启动 A 并从漏洞 A 造成影响的先决条件。

Vulnerable System and Subsequent System
易受攻击的系统及其后续系统

The CVSS 4.0 Specification introduces Vulnerable System and Subsequent System concepts. Let’s look at a few examples to understand how to differentiate between Vulnerable System impact and Subsequent System impact using examples borrowed from CVSS 3.1:
CVSS 4.0 规范引入了易受攻击系统和后续系统概念。让我们通过几个例子来了解如何使用从 CVSS 3.1 借用的例子来区分易受攻击系统影响和后续系统影响：

1. A vulnerability in a virtual machine that enables an attacker to read and/or delete files on the host operating system (perhaps even its own virtual machine) demonstrates impact to a Subsequent System (the host operating system) as well as to the Vulnerable System (the virtual machine).
   虚拟机中存在的漏洞，允许攻击者读取和/或删除宿主操作系统的文件（甚至可能是其自身的虚拟机），这表明对后续系统（宿主操作系统）以及易受攻击的系统（虚拟机）都有影响。

2. A violation of a security boundary between microprocessor privilege levels should be considered when assessing vulnerabilities using CVSS. User space programs’ capabilities running in lower privilege levels are typically limited in what instructions they can run and what registers they can write to even when running under operating system administrator privileges. A vulnerability that allows a program running in a lower privilege level to break out and run arbitrary code in a higher privilege level should be considered an impact to the Vulnerable System (the microprocessor).
   在评估使用 CVSS 评估漏洞时，应考虑微处理器权限级别之间的安全边界违规。在较低权限级别运行的用户空间程序的能力通常受到限制，即它们可以运行的指令和可以写入的寄存器，即使在操作系统管理员权限下运行也是如此。允许在较低权限级别运行的程序突破并运行更高权限级别的任意代码的漏洞应被视为对受影响系统（微处理器）的影响。

3. The security boundary between secure enclaves integrated in microprocessors and the rest of operating system processes, including the operating system kernel itself, should be considered when assessing vulnerabilities using CVSS. A vulnerability that allows other processes to impact the confidentiality, integrity or availability of data or code in a secure enclave has impact to the Vulnerable System (the secure enclave where the exploit occurs) as well as a Subsequent System (a secure enclave impacted by the exploit outside the security boundary of the Vulnerable System) .
   安全区域（集成在微处理器中的）与操作系统其余进程（包括操作系统内核本身）之间的安全边界，在评估使用 CVSS 的漏洞时应予以考虑。允许其他进程影响安全区域中数据或代码的机密性、完整性和可用性的漏洞，将对受影响系统（发生利用的安全区域）以及后续系统（受影响系统安全边界之外受利用影响的安全区域）产生影响。

4. When a vulnerability in a web application impacts user clients, e.g., web browsers, the user clients are Subsequent Systems. Common vulnerabilities of this type include cross-site scripting and URL redirection. The vulnerability is in the web application, but there is an impact to the data/behavior of the victim users’ web browsers.
   当网络应用程序中的漏洞影响用户客户端，例如网页浏览器时，用户客户端称为后续系统。此类常见漏洞包括跨站脚本和 URL 重定向。漏洞存在于网络应用程序中，但对受害用户网页浏览器中的数据/行为产生影响。

5. In a distributed environment, a vulnerability in a component providing connectivity, protection, or authentication services to components in a different security domain should include assessment for the Subsequent System(s) if a successful attack impacts these other components. For example, a vulnerability in a component such as a router, firewall, or authentication manager that affects the primary availability of one or more downstream components can impact a Subsequent System. However, if a successful attack either does not affect at all, or causes only negligible impact to other components, the vulnerability should be assessed as having no impact to a Subsequent System. Additionally, a vulnerability in a component designed to be deployed as part of a larger fault-tolerant topology should not be assessed with a Subsequent System impact if the fault-tolerance means a successful attack does not affect other components . Any effect on additional services provided by the Vulnerable System is considered a secondary impact and not a Subsequent System impact.
   在分布式环境中，为不同安全域中的组件提供连接性、保护或认证服务的组件中的漏洞，如果成功的攻击影响了这些其他组件，则应包括对后续系统（s）的评估。例如，一个影响一个或多个下游组件主要可用性的路由器、防火墙或认证管理器等组件中的漏洞可能会影响后续系统。然而，如果成功的攻击根本不影响，或者只对其他组件造成可忽略的影响，则应评估该漏洞对后续系统没有影响。此外，如果一个组件旨在作为更大容错拓扑结构的一部分部署，那么如果容错意味着成功的攻击不会影响其他组件，则不应评估其对后续系统的影响。对易受攻击系统提供的附加服务的影响被视为次要影响，而不是后续系统影响。

6. A vulnerability in a simple Portable Document Format (PDF) reader that allows an attacker to compromise other files on the same operating system when a victim opens a malicious PDF document is assessed as having no impact to a Subsequent System. This assumes the PDF reader does not have any authorization functionality that would be considered a separate security domain from the underlying operating system.
   一个简单的便携式文档格式（PDF）阅读器中的漏洞，允许攻击者在受害者打开恶意 PDF 文档时损害同一操作系统上的其他文件，评估认为对后续系统没有影响。这假设 PDF 阅读器没有任何授权功能，这些功能被视为与底层操作系统分开的安全域。

7. A SQL injection vulnerability in a web application is not usually considered as causing impact to a Subsequent System assuming that the credentials are shared between web application and impacted SQL database, and therefore they are part of the same security scope.
   一个 Web 应用程序中的 SQL 注入漏洞通常不被认为是会对后续系统造成影响，前提是凭证在 Web 应用程序和受影响的 SQL 数据库之间共享，因此它们属于同一个安全范围。

8. A vulnerability that crashes a web server or SSH server is not considered impact to a Subsequent System since the impact is limited only to the service provided by the affected server. The impact on users is secondary and is not considered as impact to a Subsequent System as users are not considered constituent elements of the Subsequent System.
   一个导致 Web 服务器或 SSH 服务器崩溃的漏洞不被视为对后续系统的影响，因为影响仅限于受影响服务器提供的服务。对用户的影响是次要的，并且不被视为对后续系统的影响，因为用户不被视为后续系统的组成部分。

9. A vulnerability that permits an attacker to exhaust a shared system resource, such as filling up a file system, should not be considered as causing impact to a Subsequent System. The attacker is still acting under the usual capabilities of the application and not breaching any security boundary.
   漏洞允许攻击者耗尽共享系统资源，例如填满文件系统，不应被视为对后续系统造成影响。攻击者仍在应用程序的正常功能范围内操作，并未突破任何安全边界。

10. By exploiting a vulnerability in an application that allows users restricted access to resources shared with other components across multiple security scopes (e.g., operating system resources such as system files), an attacker can access resources that they should not be able to access. Since there is already a valid path across the trust boundary, there is no Subsequent System impact.
    通过利用一个允许用户对与其他组件共享的资源（例如操作系统资源如系统文件）进行受限访问的应用程序中的漏洞，攻击者可以访问他们不应能够访问的资源。由于已经存在跨越信任边界的有效路径，因此没有后续的系统影响。

11. A vulnerability in an application that implements its own security domain which allows attackers to affect resources outside its security scope should be assessed as having Subsequent System impact. This assumes the application provides no features for users to access resources governed by a higher-level security domain shared with other components across multiple security scopes (e.g., the resources of the underlying operating system). One example would be a web application that allows users to read and modify web pages and files only under the web application’s installation paths, and provides no feature for users to interact beyond these paths. A vulnerability in this application allowing a malicious user to access operating system files unrelated to this application is considered impact to a Subsequent System.
    应用程序实现自己的安全域，但允许攻击者影响其安全范围之外的资源，应评估为具有后续系统影响。这假设应用程序不提供用户访问由高级安全域管理的资源的功能，该安全域与其他组件共享，跨越多个安全范围（例如，底层操作系统的资源）。一个例子是，一个允许用户仅在其安装路径下读取和修改网页和文件的 Web 应用程序，并且不提供用户在这些路径之外进行交互的功能。该应用程序中允许恶意用户访问与该应用程序无关的操作系统文件的漏洞，被认为是后续系统的影响。

Vulnerable Systems Protected by a Firewall
防火墙保护的易受攻击系统

If a vulnerability is assessed with an Attack Vector (AV) of Network (N) and the analyst has high confidence that the vulnerable system is deployed on a secure network unavailable from the Internet, Modified Attack Vector (MAV) may be assessed as Adjacent, reducing the resulting severity score.
如果对具有网络（N）攻击向量（AV）的漏洞进行评估，并且分析师高度确信受漏洞影响的系统部署在安全的网络中，且该网络无法从互联网访问，则可能评估为相邻的修改攻击向量（MAV），从而降低结果严重性评分。

Example: MySQL Stored SQL Injection (CVE-2013-0375)
示例：MySQL 存储 SQL 注入（CVE-2013-0375）

CVSS-B Score: 5.1 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N)
CVSS-B 评分：5.1（CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N）

CVSS-BE Score: 4.9 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/MAV:A)
CVSS-BE 评分：4.9（CVSS：4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/MAV:A）

Assessing Vulnerabilities in Software Libraries (and Similar)
评估软件库（及其类似）中的漏洞

When assessing the impact of a vulnerability in a library, independent of any adopting program or implementation, the analyst will often be unable to take into account the ways in which the library might be used. While specific products using the library should generate CVSS scores specific to how they use the library, assessing the library itself requires assumptions to be made. The analyst should account for the reasonable worst-case scenario. When possible, the CVSS information should detail these assumptions.
在评估库中漏洞的影响时，独立于任何采用程序或实现，分析师通常无法考虑库可能被使用的各种方式。虽然使用该库的特定产品应生成针对其使用库的 CVSS 评分，但评估库本身需要做出假设。分析师应考虑合理的最坏情况。在可能的情况下，CVSS 信息应详细说明这些假设。

For example, a library that performs image conversion would reasonably be used by programs that accept images from untrusted sources over a network. In the reasonable worst-case, it would pass them to the library without checking the validity of the images. As such, an analyst assessing a vulnerability in the library that relates to the incoming data should assume an Attack Vector (AV) of Network (N), but explain this assumption in the summary of the vulnerability. If the library might run with normal privileges, having lower impact on the embedding implementation, or with high privileges, increasing the impacts, the analyst should assume high privileges while assessing the vulnerability in the library.
例如，一个执行图像转换的库可能会被接受来自不可信来源网络的图像的程序合理使用。在合理的最坏情况下，它会在不检查图像有效性的情况下将它们传递给库。因此，评估与传入数据相关的库漏洞的分析师应假设攻击向量（AV）为网络（N），但在漏洞摘要中解释这一假设。如果库可能以正常权限运行，对嵌入实现的影响较小，或者以高权限运行，影响增加，分析师在评估库中的漏洞时应假设高权限。

When assessing a vulnerability in a given implementation using the impacted library, the metric values must be re-assessed for that specific implementation. For example, if an implementation embeds the vulnerable system (in this case, the library mentioned in the previous example), but only operates on local files, the Attack Vector (AV) would be Local (L). If the implementation that embeds this library does not invoke any of the faulty functions or does not support the mode that triggers that vulnerability, it would have no interface or attack vector to exploit the vulnerability. Thus, that vulnerability in the embedded library would have no impact on that implementation, resulting in a severity score for the given implementation of 0.
在评估使用受影响库的特定实现中的漏洞时，必须重新评估该特定实现的度量值。例如，如果一个实现嵌入有漏洞的系统（在这种情况下，指前一个例子中提到的库），但仅对本地文件进行操作，攻击向量（AV）将是本地（L）。如果嵌入该库的实现没有调用任何有缺陷的函数或不支持触发该漏洞的模式，它将没有接口或攻击向量来利用该漏洞。因此，嵌入库中的该漏洞对该实现没有影响，导致给定实现的严重度评分为 0。

Multiple CVSS Base (CVSS-B) Scores
多个 CVSS 基础（CVSS-B）评分

It is common for a vulnerability to be present on multiple product versions, platforms, and/or operating systems. In some circumstances, the Base metrics may differ on different product versions, platforms, and/or operating systems. For example, a hypothetical vulnerability is applicable to multiple operating systems produced by the same vendor. The Attack Complexity (AC) of this vulnerability on a legacy operating system is Low (L). However, a newer operating system has new inherent protection capabilities that change the Attack Complexity to High (H). This variance ultimately leads to different CVSS-B scores for the same vulnerability on the two operating systems.
漏洞存在于多个产品版本、平台和/或操作系统上是很常见的。在某些情况下，基础指标在不同产品版本、平台和/或操作系统上可能有所不同。例如，一个假设的漏洞适用于同一厂商生产的多个操作系统。在旧版操作系统上，该漏洞的攻击复杂度（AC）为低（L）。然而，较新的操作系统具有新的固有保护能力，将攻击复杂度变为高（H）。这种差异最终导致同一漏洞在这两个操作系统上的 CVSS-B 评分不同。

It is acceptable to assess and publish multiple CVSS-B scores for a single vulnerability provided each has additional language outlining the specific product versions, platforms, and/or operating systems that are relevant to each CVSS-B score. Values for all CVSS-B metrics (not only a numeric CVSS-B score) must be supplied for each affected product version, platform, and/or operating system using a standard format. In situations where multiple CVSS-B scores are applicable but only one is provided, the highest CVSS-B score must be utilized.
对于单个漏洞，可以评估和发布多个 CVSS-B 评分，前提是每个评分都有额外的语言说明与每个 CVSS-B 评分相关的特定产品版本、平台和/或操作系统。对于每个受影响的产品版本、平台和/或操作系统，必须提供所有 CVSS-B 指标值（而不仅仅是数值 CVSS-B 评分），并使用标准格式。在存在多个适用的 CVSS-B 评分但只提供了一个评分的情况下，必须使用最高的 CVSS-B 评分。

CVSS Extensions Framework
CVSS 扩展框架

Opportunities exist to leverage the core foundation of CVSS for additional scoring efforts. For example, a proposal was presented to the CVSS Special Interest Group (SIG) to incorporate privacy into CVSS by overlaying combinations of CVSS Base and Environmental metrics to derive a Privacy Impact.
存在利用 CVSS 核心基础进行额外评分工作的机会。例如，曾向 CVSS 特别兴趣小组（SIG）提出一项建议，通过叠加 CVSS 基础和环境指标的组合，将隐私纳入 CVSS，以推导隐私影响。

The following guidelines define a standard method of extending CVSS to include additional metrics and metric groups while retaining the official Base, Threat, and Environmental Metrics. The additional metrics allow industry sectors such as privacy, safety, automotive, healthcare, etc., to score factors that are outside the core CVSS standard.
以下指南定义了一种将 CVSS 扩展到包括额外的指标和指标组的方法，同时保留官方的基线、威胁和环境指标。这些额外的指标允许诸如隐私、安全、汽车、医疗保健等行业对 CVSS 标准核心之外的因素进行评分。

Guidelines  指南

• Formulas, constants or definitions of existing CVSS Base, Threat, or Environmental Metrics must not be modified. If a change to an existing item is desired, create a new metric group with a new name and work on it as desired.
  公式、常量或现有 CVSS 基础、威胁或环境度量指标的定义不得修改。如果希望更改现有项目，请创建一个新的度量指标组，并使用新名称进行工作。

• New metrics must not be added to existing metric groups, but must be added to new metric groups. New metric groups can be based on existing metric groups.
  新指标不得添加到现有指标组中，而必须添加到新的指标组中。新的指标组可以基于现有指标组。

• New metric groups can optionally have an impact on the resulting score. If they do, the resulting score must be between 0.0 and 10.0, with 10.0 being the most severe. The resulting score must be based on adjusting the CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE scores as appropriate.
  新指标组可以选择性地影响最终得分。如果影响，最终得分必须在 0.0 到 10.0 之间，10.0 表示最严重。最终得分必须基于适当调整 CVSS-B、CVSS-BT、CVSS-BE、CVSS-BTE 得分。

• The CVSS SIG does not officially approve extensions, but rather acts as a consulting body, similar to IETF¹. The CVSS SIG welcomes and encourages innovation, but has an interest in maintaining consistency across all proposed extensions.
  CVSS SIG 不正式批准扩展，而是作为咨询机构，类似于 IETF ¹ 。CVSS SIG 欢迎并鼓励创新，但同时对保持所有提议扩展的一致性感兴趣。

• The list of validated extensions will be listed on the first.org website, similar to IANA².
  经验证的扩展列表将列在 first.org 网站上，类似于 IANA ² 。

  • Mandatory Fields: Name, Description, External Authoritative Web Page
    必填字段：名称、描述、外部权威网页

  • Optional Fields: JSON Schema, XML Schema, JavaScript Calculator
    可选字段：JSON 模式、XML 模式、JavaScript 计算器

Suggested Vector String Format
建议的向量字符串格式

CVSS Extension vector strings must be listed separately, utilizing the following format:
CVSS 扩展向量字符串必须单独列出，采用以下格式：

CVSS:4.0/AV:x/AC:x/AT:x/PR:x/UI:x/VC:x/VI:x/VA:x/SC:x/SI:x/SA:x
EXT:1.0/NEW1:VAL1/NEW2:VAL2

where:

EXT:n.n is a unique extension identifier and major.minor version number
EXT:n.n 是一个独特的扩展标识符和主版本号.次版本号

NEWn is a unique attribute of the extension for each new metric
NEWn 是每个新指标扩展的唯一属性

VALn is a unique value for the attribute for each new metric value
VALn 是每个新度量值属性的唯一值

Attack Vector Considerations
攻击向量考虑

When scoring Attack Vector, use Adjacent or Network (as appropriate), when a network connection is required for an attack to succeed, even if the attack is not launched over a network. For example, a local attacker may be able to trick a vulnerable, privileged, local program into sending sensitive data to a server of the attacker’s choosing over a network. As a network connection is required to gather the sensitive data this is scored with an Attack Vector of Network.
在评估攻击向量时，根据需要使用相邻或网络（适用时），当攻击成功需要网络连接，即使攻击不是通过网络发起。例如，本地攻击者可能能够诱骗一个易受攻击的、有特权的本地程序通过网络将敏感数据发送到攻击者选择的服务器。由于收集敏感数据需要网络连接，这将以网络攻击向量为计分。

Vulnerabilities where malicious data is received over a network by one system, then passed to a separate system with a vulnerability should be scored with an Attack Vector of Local. An example is a web browser that downloads a malicious office document, saves it to disk, and then starts a vulnerable system (in this case, a document processing application) which reads the saved file.
漏洞是指一个系统通过网络接收恶意数据，然后将这些数据传递给另一个存在漏洞的系统，应将其评分攻击向量为本地。例如，一个网络浏览器下载恶意办公文档，将其保存到磁盘，然后启动一个有漏洞的系统（在这种情况下，是一个文档处理应用程序），该系统读取已保存的文件。

In cases where the vulnerable system contains the functionality that receives the malicious data, Attack Vector should be scored as Network. An example is a web browser with a vulnerability in the browser itself, or a browser plugin or extension, that triggers when the malicious data is received.
在易受攻击的系统包含接收恶意数据的函数时，攻击向量应被评分为准网络。一个例子是浏览器本身存在漏洞，或者浏览器插件或扩展，在接收到恶意数据时触发。

Non-Repudiation is a Part of Integrity
不可否认性是完整性的一个组成部分

As per NIST³ non-repudiation is “Protection against an individual falsely denying having performed a particular action”. There could be scenarios where a system user could perform system critical actions, within the user’s own privilege, and then completely deny performing the action; that would cause a Repudiation Impact.
根据 NIST ³ ，不可否认性是指“防止个人虚假否认执行特定行为”。可能存在系统用户在其权限范围内执行系统关键操作，然后完全否认执行该行为的情况；这会导致否认影响。

Say a system has multiple user admins. One admin gives backdoor access to a malicious attacker to the system. When the incident is identified, there is no way to identify the defaulter as there was no logging in place. The malicious admin didn’t do anything beyond own privileges. But in this case, CWE-778: Insufficient Logging was the weakness which caused a Repudiation impact, and hence an Integrity impact. (Example: CVE-2019-8124)
一个系统拥有多个用户管理员。一位管理员将后门访问权限提供给恶意攻击者。当事件被识别时，由于没有日志记录，无法确定违规者。恶意管理员没有超出自身权限进行任何操作。但在此情况下，CWE-778：日志不足是导致否认影响的弱点，从而引发完整性影响。（例如：CVE-2019-8124）

Similarly, in case of horizontal privilege escalation vulnerabilities the malicious user is usually unable to do something beyond his/her own capabilities. The delta impact on C, I, and A are None. But the attacker can still take malicious actions in the system by impersonating another user of the same privileges leading to a Repudiation impact, and hence an Integrity impact. (Example: CVE-2017-6785)
同样，在水平权限提升漏洞的情况下，恶意用户通常无法超越其自身能力进行操作。对 C、I 和 A 的影响均为无。但攻击者仍然可以通过冒充具有相同权限的其他用户在系统中执行恶意操作，从而导致否认影响，进而影响完整性。 （例如：CVE-2017-6785）

Whenever a vulnerability causes a potential repudiation, it immediately impacts the Integrity of the system, along with other subsequent impacts.
每当一个漏洞导致潜在的否认时，它立即影响系统的完整性，以及其他后续影响。

Security Requirements  安全需求

This section provides guidance on selecting appropriate metric values for these based on the characteristics of a specific environment. The examples are simplified to illustrate the concepts.
本节提供了根据特定环境的特征选择合适的度量值指南。示例被简化以说明概念。

Confidentiality Requirement (CR)
保密性要求（CR）

The Confidentiality Requirement of a system should be based on the classification level of the data that is stored or used by the user and/or applications running on the target system. Encryption of the data at rest on this device should also be taken into consideration when establishing the Confidentiality Requirement. Data that passes through a device without being consumed or processed (e.g., a switch or firewall) should not be taken into consideration when assessing this attribute. See below for examples.
系统机密性要求应基于用户和/或运行在目标系统上的应用程序存储或使用的数据的分类级别。在确定机密性要求时，还应考虑该设备上静态数据的加密。在评估此属性时，不应考虑未经消耗或处理（例如，交换机或防火墙）通过设备的数据。以下为示例。

Note: The volume of data may influence the value of the attribute, but should not have as much impact as the classification (i.e., type) of data that is being stored or used.
注意：数据量可能影响属性值，但不应像存储或使用的数据的分类（即类型）那样产生重大影响。

1. A device that stores data classified at the highest level should have this attribute rated as High. However, if the sensitive data is encrypted at rest, this attribute may be rated Medium.
   存储最高级别数据的设备应具有此属性被评为高。然而，如果静止状态下的敏感数据被加密，则此属性可能被评为中。

2. A device that stores data classified as non-public but not as high as the highest level should have this attribute rated as Medium. However, if the sensitive data is encrypted at rest, this attribute can be rated Low.
   设备存储的数据被归类为非公开但不如最高级别，应具有中等评级的此属性。然而，如果敏感数据在静止状态下加密，则此属性可以评为低。

3. A device that stores data that can be openly shared publicly should have this attribute rated as Low.
   存储可公开共享数据的设备应将此属性评级为低。

4. Network equipment such as a router, switch, or firewall will generally be rated as Medium due strictly to the sensitivity of information such as routing tables, etc.
   网络设备如路由器、交换机或防火墙通常会被评定为中等，主要是因为路由表等信息的高度敏感性。

5. Any system that stores login credentials without encryption should have this attribute rated as High. This includes service accounts and credentials embedded into scripts or source code.
   任何未加密存储登录凭证的系统，其此属性应评为高。这包括服务帐户以及嵌入到脚本或源代码中的凭证。

Integrity Requirement (IR)
完整性要求（IR）

The Integrity Requirements of a system focus on the importance of the accuracy of the data it stores or uses. Data that passes through a device without being consumed or processed (e.g., a switch or firewall) should not be taken into consideration when assessing this attribute. The use of encryption on the data at rest should not be taken into consideration for this attribute. See below for examples:
系统完整性要求关注其存储或使用的数据的准确性。未经消耗或处理（例如，交换机或防火墙）通过设备的数据不应在评估此属性时予以考虑。对于此属性，不应考虑对静态数据使用加密。以下为示例：

1. Devices that contain monetary transactional data and/or personally identifiable information (PII) should be rated High.
   包含货币交易数据以及/或个人身份信息（PII）的设备应评为高风险。

2. Devices that contain data directly used to make business or risk management decisions should be rated at a minimum of Medium. As the severity of the decisions increase, so should the Integrity Requirement rating.
   设备中包含直接用于商业或风险管理决策的数据应至少评为中等。随着决策严重性的增加，完整性要求评级也应相应提高。

3. Devices that contain data directly used to make health decisions should be rated High.
   直接用于做出健康决策的数据所包含的设备应评为高级。

4. Network equipment such as a router or switch will generally be rated at least Medium due strictly to the sensitivity of information such as forwarding tables, etc.
   网络设备，如路由器或交换机，通常至少被评为中等，主要是由于转发表等信息的高度敏感性。

5. Firewalls should be rated as High due to the sensitivity of the rule set.
   防火墙应被评为高级，因为规则集的敏感性较高。

Availability Requirement (AR)
可用性需求（AR）

The Availability Requirement of a system should be based on the uptime requirements and redundancy of the device or the applications hosted by the device. Devices that are part of redundant clusters will have lower Availability Requirements. See below for examples:
系统可用性要求应基于设备的正常运行时间和冗余性，或设备托管的应用程序的正常运行时间要求。作为冗余集群一部分的设备将具有较低的可用性要求。以下为示例：

1. Devices without full capacity redundancy that are rated with recovery requirements less than 24 hours should be rated High.
   设备无完全冗余能力且恢复要求低于 24 小时的，应评为高级。

2. Devices without full capacity redundancy that are rated with recovery requirements between 1-5 days should be rated Medium.
   设备无完全冗余能力且恢复要求在 1-5 天之间的应评为中等。

3. Devices with recovery requirements of more than 5 days should be rated Low.
   设备恢复时间超过 5 天的应评为低。

4. Clustered devices and/or those with full capacity redundancy should be rated as Low.
   集群设备或具有完全冗余能力的设备应评为低。

5. Devices that are required to have rapid response times for transactional purposes based on regulatory requirements, should be rated High.
   需要根据监管要求具备快速响应时间的交易设备应评为高级。

Supplemental Metrics  补充指标

A new, optional metric group called the Supplemental metric group provides new metrics that describe and measure additional extrinsic attributes of a vulnerability. The usage of each metric within the Supplemental metric group is determined by the scoring consumer. This contextual information may be used differently in each consumer’s environment.
一种新的、可选的度量分组称为补充度量分组，它提供了描述和衡量漏洞额外外在属性的新度量。补充度量分组中每个度量使用的确定由评分消费者决定。这种上下文信息在每个消费者的环境中可能被不同地使用。

No metric will, within its specification, have any impact on the final calculated CVSS score (e.g. CVSS-BTE). Organizations may then assign importance and/or effective impact of each metric, or set/combination of metrics, giving them more, less, or absolutely no effect on the final risk analysis. Metrics and values will simply convey additional extrinsic characteristics of the vulnerability itself.
没有指标在其规范范围内会对最终计算的 CVSS 评分（例如 CVSS-BTE）产生任何影响。组织可以随后分配每个指标的重要性及其有效影响，或者设置/组合指标，使它们对最终风险评估产生更多、更少或完全没有影响。指标和值将仅传达漏洞本身的额外外在特征。

Safety  安全

When a system has an intended use or fitness of purpose aligned to safety, it is possible that exploiting a vulnerability within that system may have Safety impact which can be represented in the Supplemental Metrics group.
当一个系统具有与安全一致的使用目的或适用性时，利用该系统中的漏洞可能产生安全影响，这种影响可以在补充指标组中表示。

Note that all Supplemental Metrics, including Safety, are completely optional. Suppliers and vendors may pick and choose whichever Supplemental Metrics they wish to populate on a case by case basis as they see fit. Lack of a Safety metric value being supplied does NOT mean that there may not be any Safety-related impacts.
请注意，所有补充指标，包括安全性，都是完全可选的。供应商和供应商可以根据自己的判断选择在特定情况下填充哪些补充指标。未提供安全性指标值并不意味着可能没有任何与安全性相关的影響。

Automatable  可自动化的

Some example reasons for why a step in the kill chain may not be reliably automatable include:
一些可能导致攻击链中的步骤无法可靠自动化的示例原因包括：

1. the vulnerable system is not searchable or enumerable on the network,
   该脆弱系统在网络中不可搜索或枚举

2. weaponization requires human direction for each target,
   武器化需要对每个目标进行人工指导

3. delivery uses channels that widely deployed network security configurations block, and
   交付使用广泛部署的网络安全配置阻止的通道

4. exploitation is not reliable, due to exploit-prevention techniques enabled by default; ASLR is an example of an exploit-prevention tool. These are example reasons, provided for illustration, and are not an exhaustive list of reasons why a kill chain step may not be automatable.
   利用不可靠，因为默认启用了利用预防技术；ASLR 是一种利用预防工具的例子。这些是提供说明的示例原因，并不是一个详尽无遗的理由列表，说明为什么链式攻击步骤可能无法自动化。

As one heuristic for yes, if the vulnerability allows unauthenticated remote code execution or command injection, the expected response is yes. Analysts should provide an argument or demonstration that all four steps are able to be automated rather than solely relying on heuristics.
作为是的一个启发式方法，如果漏洞允许未认证的远程代码执行或命令注入，预期的响应是是。分析师应提供论据或演示，表明所有四个步骤都可以自动化，而不是仅仅依赖启发式方法。

The definition of automatable is intended to stay materially the same as the definition of the decision point by the same name in the stakeholder specific vulnerability categorization (version 2).
自动化定义的意图与利益相关者特定脆弱性分类（版本 2）中同名决策点的定义在实质上保持一致。

Provider Urgency  供应商紧急程度

Many vendors currently provide supplemental severity ratings to consumers via product security advisories. Other vendors publish Qualitative Severity Ratings from the CVSS v3.x Specification Document in their advisories.
许多厂商目前通过产品安全公告向消费者提供补充严重性评级。其他厂商在其公告中发布 CVSS v3.x 规范文档中的定性严重性评级。

To facilitate a standardized method to incorporate additional provider-supplied assessment, it is proposed to adopt an optional “pass-through” Supplemental Metric called Provider Urgency.
为便于采用标准化的方法纳入额外的供应商提供的评估，建议采用可选的“传递”补充指标，称为“供应商紧急程度”。

Recovery  恢复

Recovery describes the resilience of a Component/System to recover services, in terms of performance and availability, after an attack has been performed. Values for Recovery include:
恢复描述了组件/系统在遭受攻击后，在性能和可用性方面恢复服务的能力。恢复的值包括：

• Automatic (A): The Component/System recovers services automatically after an attack has been performed.
  自动（A）：在攻击执行后，组件/系统会自动恢复服务。

• User (U): The Component/System requires manual intervention by the user to recover services, after an attack has been performed
  用户（U）：在攻击执行后，组件/系统需要用户手动干预以恢复服务

• Irrecoverable (I): The Component/System services are irrecoverable by the user, after an attack has been performed.
  不可恢复（I）：在攻击执行后，用户无法恢复组件/系统服务。

Value Density  价值密度

The following are suggestive examples of when to select the Diffuse or Concentrated metric values for this metric.
以下是一些示例，说明何时选择该指标的扩散或集中度度量值。

Diffuse: Examples of systems with diffuse value are email accounts, most consumer online banking accounts, common cell phones, and most personal computing resources owned and maintained by users. (A “user” is anyone whose professional task is something other than the maintenance of the system or component. A “system operator” is anyone who is professionally responsible for the proper operation or maintenance of a system.)
扩散型：扩散型价值的系统示例包括电子邮件账户、大多数消费者在线银行账户、普通手机以及大多数由用户拥有和维护的个人计算资源。（“用户”是指专业任务不是系统或组件维护的任何人。 “系统操作员”是指专业负责系统正常运行或维护的任何人。）

Concentrated: Heuristically, such systems are often the direct responsibility of “system operators” rather than users. (A “user” is anyone whose professional task is something other than the maintenance of the system or component. A “system operator” is anyone who is professionally responsible for the proper operation or maintenance of a system.) Examples of concentrated value are database systems, Kerberos servers, web servers hosting login pages, and cloud service providers. However, usefulness and uniqueness of the resources on the vulnerable system also inform value density. For example, encrypted mobile messaging platforms may have concentrated value, not because each phone’s messaging history has a particularly large amount of data, but because it is uniquely valuable to law enforcement.
集中式：从启发式角度来看，这类系统通常直接由“系统操作员”负责，而不是用户负责。（“用户”是指那些专业任务不是系统或组件维护的人。 “系统操作员”是指那些在专业上负责系统或维护操作的人。）集中式价值的例子包括数据库系统、Kerberos 服务器、托管登录页面的 Web 服务器和云服务提供商。然而，易受攻击系统上资源的实用性和独特性也影响着价值密度。例如，加密移动消息平台可能具有集中式价值，并不是因为每部手机的短信历史记录有特别大量的数据，而是因为它对执法部门具有独特的价值。

The definition of value density is intended to stay materially the same as the definition of the decision point by the same name in the stakeholder specific vulnerability categorization (version 2).
价值密度的定义旨在与利益相关者特定脆弱性分类（版本 2）中同名决策点的定义在实质上保持一致。

Vulnerability Response Effort
漏洞响应努力

The intention of the Vulnerability Response Effort metric is to provide supplemental information on how difficult it is for consumers to provide an initial response to the impact of vulnerabilities for deployed products and services in their infrastructure. The consumer can then take this additional information on effort required into consideration when applying mitigations and/or scheduling remediation.
漏洞响应努力度指标的目的在于提供补充信息，说明消费者在对其基础设施中部署的产品和服务中漏洞的影响做出初始响应的难度。消费者随后可以将这些关于所需努力程度的额外信息考虑在内，在应用缓解措施和/或安排修复时。

When calculating Vulnerability Response Effort, the effort required to deploy the quickest available response should be considered.
在计算漏洞响应努力时，应考虑部署最快可用响应所需的努力。

Glossary of Terms  术语表

As much as possible, we will use standard definitions for terms and prefer global, consensus, freely available definitions.⁴
尽可能使用标准术语定义，并优先选择全球共识、免费可用的定义。 ⁴

Affected: A system is affected by a vulnerability if a user or operator of the system must take action to remediate, mitigate, or otherwise address the vulnerability.⁵ If a system is affected by a vulnerability, the CVSS v4.0 Base score must not be 0.0.
受影响：如果一个系统的用户或操作员必须采取行动来修复、缓解或以其他方式解决漏洞，则该系统受到漏洞的影响。 ⁵ 如果一个系统受到漏洞的影响，CVSS v4.0 基础评分不得为 0.0。

Attacker: A human person that “...attempts to evade security services and violate the security policy of a system. That is, an actual assault on system security….”⁶, often but not always attempted by exploiting a vulnerability in the system. (Consistent with NIST CSRC definitions, an attacker is a person.)
攻击者：试图规避安全服务并违反系统安全策略的人。“……试图规避安全服务并违反系统安全策略。即对系统安全的实际攻击……。” ⁶ ，通常但并非总是通过利用系统中的漏洞来尝试。 (与 NIST CSRC 的定义一致，攻击者是人。)

Chained score: The Base Score produced by scoring two or more chained vulnerabilities.
链式得分：由评分两个或更多链式漏洞产生的基准得分。

Chained vulnerabilities: See Vulnerability Chaining.
链式漏洞：参见漏洞链。

Default credential: Data such as a user name and password that is initially configured and allows authentication unless it has been changed. A default credential may be shared by many systems or unique to individual systems. A system may force a default credential to be changed.
默认凭证：初始配置的用户名和密码等数据，允许进行身份验证，除非已被更改。默认凭证可能被许多系统共享，也可能仅属于个别系统。系统可能强制更改默认凭证。

Hard-coded credential: Data such as a user name and password that is always configured, always allows authentication, and cannot be changed or disabled.
硬编码凭证：始终配置、始终允许认证且无法更改或禁用的用户名和密码等数据。

Proof-of-Concept exploit code: Software or sufficient technical details that can be used to demonstrate the existence of a vulnerability.
概念验证利用代码：可用于证明漏洞存在的软件或足够的技术细节。

Privilege: A collection of rights (typically read, write, and execute) granted to a user or user process which defines access to computing resources. The terms “privilege,” “permission,” and “authorization” are used interchangeably.⁷
特权：一组（通常是读取、写入和执行）授予用户或用户进程的权利，用于定义对计算资源的访问。术语“特权”、“权限”和“授权”可以互换使用。 ⁷

Reasonable worst-case: An instance of a plausible path to the exploitation of a vulnerability, the worst-case after any unreasonable high-impact low-likelihood paths have been discountedIt is not a prediction of what will happen, rather an illustration of what could reasonably be foreseen by an experienced analyst and that would require response action by a security professional or team.⁸
合理最坏情况：一种合理的利用漏洞的路径实例，在排除所有不合理的高影响低概率路径之后的最坏情况。这并不是对将要发生什么的预测，而是一个经验丰富的分析师可以合理预见的情况，并且需要安全专业人员或团队采取响应行动。

Resource: Asset used or consumed during the execution of a process.⁹ Examples of resources include (but are not limited to) file contents, file identifiers, memory pointers, memory contents, CPU cycles, and network bandwidth.
资源：在过程执行期间使用或消耗的资产。 ⁹ 资源的例子包括但不限于文件内容、文件标识符、内存指针、内存内容、CPU 周期和网络带宽。

Security domain: Set of assets and resources subject to a common security policy.¹⁰
安全域：受同一安全策略约束的资产和资源集合。

Security policy: A set of policy rules (or principles) that direct how a system (or an organization) provides security services to protect sensitive and critical system resources.¹¹
安全策略：一组指导系统（或组织）如何提供安全服务以保护敏感和关键系统资源的策略规则（或原则）。

System, information system: An organized assembly of computing and communication resources and procedures — i.e., equipment and services, together with their supporting infrastructure, facilities, and personnel — that create, collect, record, process, store, transport, retrieve, display, disseminate, control, or dispose of information to accomplish a specified set of functions.¹² Uses of “system” means “Information system” unless otherwise specified. Information systems include, for example, IT systems, ICS systems, OT systems, computing hardware, and so on.
系统、信息系统：由计算和通信资源及程序组成的有序集合——即设备和服务，以及它们的支持性基础设施、设施和人员——用于创建、收集、记录、处理、存储、传输、检索、显示、传播、控制或处置信息，以实现一组特定的功能。除非另有说明，“系统”一词的含义为“信息系统”。信息系统包括，例如，IT 系统、ICS 系统、OT 系统、计算硬件等。

Subsequent System: A system whose security policy is violated as a result of the exploited vulnerability but that is not the Vulnerable System.
后续系统：由于利用了漏洞而导致其安全策略被违反，但并非易受攻击系统的系统。

Successful attack: A successful attack (or successful exploit of a vulnerability) is a situation where an attacker violates the security policy of an information system.
成功攻击：成功攻击（或成功利用漏洞）是指攻击者违反信息系统安全策略的情况。

User: An authorized human person. For CVSS, usually said of a person authorized to access a vulnerable system affected by the vulnerability being scored.
用户：授权的人类个体。在 CVSS 中，通常指被评分漏洞影响的易受攻击系统的授权访问者。

Vulnerability: A weakness or flaw in the functional behavior of an information system (software or hardware) that can be exploited, resulting in a negative impact to the Confidentiality, Integrity, and/or Availability of the vulnerable system or a subsequent system (that is, the violation of a security policy of an information system).¹³
漏洞：信息系统中（软件或硬件）功能行为中的弱点或缺陷，可被利用，导致受影响系统或后续系统（即，违反信息系统安全策略）的机密性、完整性和/或可用性受到负面影响。

Vulnerability chaining: The sequential exploitation of multiple vulnerabilities in order to attack an information system, where one or more exploits at the end of the chain requires the successful completion of prior exploits in order to be exploited.¹⁴
漏洞链式利用：为了攻击信息系统，依次利用多个漏洞的过程，其中链尾的某个或某些漏洞需要先前的漏洞利用成功完成才能被利用。

Vulnerable System: A system whose security policy is violated as the result of an exploited vulnerability and which contains the vulnerability.
易受攻击的系统：由于利用了漏洞而导致安全策略被违反，并且包含该漏洞的系统。

Scoring Rubrics  评分标准

The scoring rubrics are an aid to scoring vulnerabilities by supplementing the metric definitions in the Specification Document.
评分标准是评分漏洞的辅助工具，通过补充规范文档中的度量定义来帮助评分。

Version History  版本历史

Date  日期	Ver	Description  描述
2023-11-01	v1.0	Initial Publication  首次发表