输入关键词，沿着知识网络探索。

选择一个条目查看预览。

#security #vulnerability-management #cvss #standard

Common Vulnerability Scoring System

Common Vulnerability Scoring System（CVSS）是 FIRST 维护的开放漏洞严重度表达标准。它把攻击前提和技术影响编码为可审计的向量，并将一次评估映射为 0.0—10.0 分及可选的 None／Low／Medium／High／Critical 等级。CVSS 回答的是“在给定指标取值下，这个漏洞的技术严重度是什么”；它不分配 CVE、不给出未来利用概率，也不直接等于某个组织的业务风险或补丁顺序。

引用一个 CVSS 数字时，至少应同时保留 CVSS 版本、评分提供者、完整向量、适用产品或环境和观测时间；若为 v4.0，再保留 score nomenclature。裸写“CVSS 7.8”会丢失评分是 v3.1 还是 v4.0、由谁给出、使用了什么攻击前提，以及 Threat／Environmental 是否已显式纳入。

v3.1 与 v4.0 不是同一把尺

FIRST 在 2019 年 7 月 12 日发布 v3.1 公告；v3.1 主要澄清 v3.0 的定义、公式和取整，没有新增指标。v4.0 于 2023 年 11 月 1 日正式发布，重构了指标、计算方法和结果命名。当前 FIRST 页面以 v4.0 为现行版本，同时继续保留旧版规范与计算器。

维度 CVSS v3.1 CVSS v4.0
指标组 Base、Temporal、Environmental Base、Threat、Environmental、Supplemental
Base Exploitability AV、AC、PR、UI AV、AC、Attack Requirements、PR、UI
技术影响 C／I／A；Scope 表达影响是否跨安全边界 分开记录 Vulnerable System 的 VC／VI／VA 与 Subsequent System 的 SC／SI／SA
利用成熟度 Temporal 中的 Exploit Code Maturity，另有 Remediation Level、Report Confidence Threat 只保留 Exploit Maturity；旧 RL／RC 退役
环境修正 CR／IR／AR 加 Modified Base metrics CR／IR／AR 加与新 Base 对应的 Modified metrics，并允许 MSI／MSA 的 Safety 值
补充语境 无独立组 Safety、Automatable、Recovery、Value Density、Vulnerability Response Effort、Provider Urgency；均不改变数值分数
数学模型 公开权重与代数公式 专家排序的 equivalence sets／MacroVectors 加组内插值

因此，v4.0 不是给 v3.1 向量换一个版本前缀。Attack Complexity 的部分旧含义被拆到 Attack Requirements，User Interaction 被细分为 Passive／Active，Scope 被两个系统的影响指标替代，计算模型也改变。跨版本趋势分析必须保留原始向量和版本，不能把同一 CVE 的 v3.1 与 v4.0 数字当作无损换算或直接解释成严重度升降。

两个版本沿用相同的定性区间：0.0 为 None，0.1—3.9 为 Low，4.0—6.9 为 Medium，7.0—8.9 为 High，9.0—10.0 为 Critical。区间相同不代表底层评估或分值可直接横比。

v4.0 的四层信息

指标组 回答的问题 典型责任位置 不能推出什么
Base 在合理最坏实现下，利用需要什么条件，会对易受攻击系统及后续系统造成什么技术影响 通常由产品提供者、CNA 或代评分方给出；11 个 Base metrics 必填 不能推出已被利用、某资产可达或业务损失
Threat 当前利用成熟度是 Attacked、Proof-of-Concept 还是 Unreported 由威胁情报提供者或掌握持续威胁情报的消费者 enrichment；未定义 E:X 在计算中按最坏的 E:A 处理 E:X 默认按 E:A 计算不是利用证据；显式 E:A 只表示该 assessment provider 依据其证据判断为 Attacked，仍不等于 KEV 收录、跨来源确认或具体资产已遭利用
Environmental 本地资产的 C／I／A 重要性、部署条件和缓解措施如何改变评估 最了解实际部署、控制与资产价值的消费者重算 一个组织的 Modified metrics 不能成为所有部署的通用 Base
Supplemental 安全、攻击链自动化、恢复、价值密度、响应工作量和供应商紧迫度等额外语境 通常由产品维护方或代评分方赋值；消费者据此调整本地响应；Provider Urgency 可沿供应链传递 Supplemental 值不进入 CVSS 数值，U:Red 或 S:P 不是“加分项”

v4.0 用 CVSS-B、CVSS-BT、CVSS-BE、CVSS-BTE 标记哪些 Threat／Environmental metrics 被显式使用。数值计算始终考虑 Base、Threat 与 Environmental；未显式提供 T／E 时使用 X 的计算默认。一次评估是一个数值及其 nomenclature，不是四个可以并列挑选的子分数。Supplemental 不产生 “S” 数值后缀。

完整向量比裸分数重要。FIRST 要求发布分数时同时发布向量；向量保存了指标取值，数值本身无法反推出这些判断。v4.0 的 11 个 Base metrics 不允许 X，必须完整赋值；Threat／Environmental 的 X 有计算默认，Supplemental 的 X 不改变数值。因此“字段没填”和“事实已被确认”为不同状态。

严重度、可利用性与风险必须分层

v3.1 User Guide 明确写出 “CVSS Measures Severity, not Risk”。v4.0 的 Threat 和 Environmental 能让结果更接近时间与部署语境，但 CVSS-BTE 仍不是完整风险概率：它没有自动纳入资产外网暴露、攻击者偏好、业务依赖、补丁副作用、停机成本、合规期限和组织风险承受度。

更稳健的决策链是：

CVE 标识 → 产品适用性 → CVSS 技术严重度 → 利用证据或预测 → 本地资产与处置约束 → 修复决策

这些异质信号如何在有限补丁容量下组合、设 override 和校验时间泄漏，另见 漏洞优先级信号组合；组合关系不能被压成另一个 CVSS 数字。

FIRST 的 EPSS FAQ 还特别反对把 EPSS 概率与 CVSS 序数分数直接相乘：两个量的语义和标度不同，乘积没有可解释的概率或风险单位。把多种信号组合进本地模型可以是组织决策，但必须明确输入、阈值、目标结果和验证方法，而不是靠算术拼接制造一个看似精确的“风险分”。

分数由谁给出

CVSS 是方法，不是一个全局唯一评分数据库。同一 CVE 可以同时出现产品 CNA、ADP、NVD、发行版或其他提供者的评估；它们可能使用不同版本、公开资料、适用产品和观测时间。正确的引用对象是“某 provider 对某范围在某时点给出的某版本向量”，不是“这个 CVE 的真实 CVSS”。

National Vulnerability Database（NVD）摄入已发布的 CVE Record，并对纳入当前 scope 与排期的记录补充 CPE、CWE、CVSS 和 configuration mapping；并非每条已发布记录都会立即或最终出现独立 NVD metric。NVD FAQ 说明其分析基于当时可得公开资料，不会把第三方向量不加判断地复制成自己的结论；公开信息不足或冲突时还可能采用合理最坏情形。NVD API 的 metric 对象保留 source 与 type，正是为了让消费者区分评分来源，而不是把所有数字折叠成一列。

NVD API 的 Primary／Secondary 不等于 CVE Program 的 CNA／ADP 角色。Primary 包括 NVD，也可包括在相应 submission category 达到 CVMAP Provider level 的 CNA；Provider submission 被抽审时，响应可同时把 NVD 标为 Primary、该 CNA 标为 Secondary。因而 Secondary 既可能是 CNA，也可能是 ADP，不能据此判断来源角色、正确性或优先级；CNA／ADP 身份应回到 CVE Record 的 containers.*.providerMetadata 核验。

2026 年 8 月 11 日对 NVD current-state API 的访问观察给出两个直观例子；这些 endpoint 会继续更新，以下同时固定响应 timestamp 与记录 lastModified：

NVD 的 CVMAP 机制按 CNA × submission category 衡量最近合格样本与 NVD enrichment practices 的一致度及抽审状态，给出 Reference／Contributor／Provider 等 acceptance level。它不是一般质量排名或 FIRST 对评分正确性的认证，也不意味着某 provider 的所有历史分数都适用于本地环境。

实证研究揭示的限制

CVSS 的价值在于把判断拆成可讨论的指标，而不是消除判断者差异或自动预测攻击。

这些研究共同支持三个工作规则：不要用单一 Base threshold 替代威胁和资产分析；不要把 provider 分歧静默平均；不要用历史版本混杂的分数训练或评估模型而不保留版本、向量与来源。

操作核对表

处理一条漏洞记录时：

  1. 固定 CVE ID、受影响产品、版本和配置，不先从分数倒推适用性。
  2. 记录 CVSS 版本、provider、完整 vector、nomenclature 与时间戳；同页多条 metric 分开保留。
  3. 检查 Base 判断是否来自产品提供者、NVD 或 ADP；若不同，逐项比较向量，而不是只比较总分。
  4. 查明 Threat 值是 X 的默认最坏值还是显式评估，并继续追溯显式 E:A 来自在野攻击报告还是 exploit tooling；另查 EPSS、KEV、PoC 与内部遥测。
  5. 用实际暴露、缓解措施和资产关键性重算 Environmental；不要把别人的环境向量移植为通用结论。
  6. 把 Supplemental 当作响应语境，不把它解释成隐藏的数值加权。
  7. 最终补丁优先级写清业务、停机、合规和处置成本；CVSS 只是输入之一。

证据边界

相关页面