3. CVSS评分体系：CVSS v3/v4向量公式、基础/环境/时间指标、评分计算实战
CVSS，全称 Common Vulnerability Scoring System，说白了就是给漏洞打分的标准。我做了这么多年安全评估，见过太多人把 CVSS 分数当成「圣旨」——看到 9.8 就慌，看到 4.3 就忽略。其实这不对。你得理解它背后的逻辑，才能用好它。
这一节，我会带你拆解 CVSS v3 和 v4 的向量公式，讲清楚基础指标、时间指标、环境指标分别管什么，最后手把手算几个真实案例。嗯，保证你学完就能上手。
3.1 CVSS 的三大指标组
CVSS 评分体系由三部分组成，每一组解决不同的问题：
- 基础指标（Base Metrics）：漏洞本身的固有属性，不随时间、环境变化。比如攻击难度、是否需要权限。
- 时间指标（Temporal Metrics）：随时间变化的因素。比如漏洞是否已被公开利用、是否有官方补丁。
- 环境指标（Environmental Metrics）：跟你自己的系统环境相关。比如你的资产重要性、安全控制措施。
最终得分 = 基础分 × 时间因子 × 环境因子。但实际计算时，每个指标组内部还有一套加权公式。
核心原则：基础分是「锚点」，时间分和环境分是「调节器」。我见过很多团队只盯着基础分做决策，结果把低危漏洞当成高危修，浪费大量人力。你想想看，一个基础分 7.5 的漏洞，如果它只在特定配置下才触发，环境分一调可能就降到 4.0 了。
3.2 CVSS v3 向量公式详解
CVSS v3 的向量字符串长这样：
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H每个缩写代表一个指标。我习惯把它分成三组来记：
3.2.1 可利用性指标（Exploitability Metrics）
| 指标 | 全称 | 可选值（从高到低） |
|---|---|---|
| AV | 攻击向量 | N（网络）> A（相邻网络）> L（本地）> P（物理） |
| AC | 攻击复杂度 | L（低）> H（高） |
| PR | 所需权限 | N（无）> L（低）> H（高） |
| UI | 用户交互 | N（不需要）> R（需要） |
举个例子：AV:N 表示攻击者可以从远程网络发起攻击，不需要物理接触。AC:L 表示攻击手法不复杂，不需要特殊条件。PR:N 表示不需要任何账号权限。UI:R 表示需要受害者点击某个链接或打开文件。
我的经验：在 CVSS v3 中，AV:N + AC:L + PR:N + UI:N 这四个组合在一起，基本就是「最坏情况」——远程、无脑、无权限、无交互。这种漏洞的基础可利用性得分会非常高。我曾经在应急响应中遇到一个这样的 RCE 漏洞，从发现到被大规模利用只用了 6 小时。
3.2.2 影响指标（Impact Metrics）
| 指标 | 全称 | 可选值 |
|---|---|---|
| C | 机密性影响 | H（高）> L（低）> N（无） |
| I | 完整性影响 | H（高）> L（低）> N（无） |
| A | 可用性影响 | H（高）> L（低）> N（无） |
这三个指标决定了漏洞被利用后，对目标系统造成的损害程度。C:H/I:H/A:H 就是「三高」——数据全泄露、系统被篡改、服务不可用。这种漏洞通常对应 RCE 或 SQL 注入。
3.2.3 作用域（Scope）
S:U 表示作用域不变（Unchanged），S:C 表示作用域改变（Changed）。
作用域这个概念，很多人一开始会搞混。我简单解释一下：如果漏洞利用只影响当前组件，就是 U；如果漏洞能跨越安全边界影响其他组件，就是 C。比如一个 Web 应用的漏洞导致底层操作系统被控制，那就是作用域改变。
避坑指南：我曾经在评估一个容器逃逸漏洞时，把作用域写成了 U。后来发现漏洞能从容器影响到宿主机，明显是 C。这个错误直接导致基础分从 7.5 变成了 9.0。所以判断作用域时，一定要想清楚「安全边界」在哪里。
3.3 CVSS v4 的新变化
CVSS v4 在 2023 年底正式发布。相比 v3，它做了几个重要调整：
- 新增攻击要求（AT）：区分攻击是否需要特殊设备或条件。比如是否需要物理接触特定硬件。
- 细化用户交互（UI）：v4 把 UI 拆成了主动交互和被动交互。主动交互指受害者主动操作（如点击链接），被动交互指受害者只是被动接收（如打开邮件预览）。
- 新增漏洞响应努力（RE）：衡量修复漏洞需要的工作量。
- 移除作用域（Scope）：v4 不再单独计算作用域，而是通过影响指标的细化来体现。
v4 的向量示例：
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N可以看到，影响指标从 C/I/A 变成了 VC/VI/VA（漏洞对机密性/完整性/可用性的影响）和 SC/SI/SA（对下游系统的影响）。
我的建议：目前业界主流还是 v3.1，但 NVD 已经开始支持 v4。我个人建议你至少把 v4 的向量结构看懂，因为未来 1-2 年内，v4 会逐步成为主流。特别是做供应链安全评估时，很多新漏洞已经用 v4 打分了。
3.4 评分计算实战
理论讲完了，咱们来动手算一算。我会用三个真实案例，分别演示 v3 和 v4 的计算过程。
3.4.1 案例一：Web 应用 RCE 漏洞（CVSS v3）
假设一个 Web 应用存在远程命令执行漏洞，攻击者无需认证，只需发送一个 HTTP 请求即可触发。漏洞影响机密性、完整性、可用性，且作用域不变。
向量：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
计算步骤：
- 计算可利用性子得分：
Exploitability = 8.22 × AV × AC × PR × UI
代入值：AV=1.0, AC=1.0, PR=1.0, UI=1.0
Exploitability = 8.22 × 1.0 × 1.0 × 1.0 × 1.0 = 8.22 - 计算影响子得分：
Impact = 6.42 × (1 - (1-C)×(1-I)×(1-A))
代入值：C=0.56, I=0.56, A=0.56
Impact = 6.42 × (1 - 0.44×0.44×0.44) = 6.42 × 0.914 = 5.87 - 因为作用域不变，基础分 = min(Impact + Exploitability, 10) = min(5.87 + 8.22, 10) = 10.0
最终基础分：10.0（严重）
注意：你可能会问，为什么 Impact 只有 5.87，加上 Exploitability 就封顶了？因为 CVSS 的设计逻辑是：一个漏洞即使影响不大，但如果极其容易被利用，它仍然可能是高危。这个 RCE 漏洞就是典型——攻击门槛极低，所以直接满分。
3.4.2 案例二：本地提权漏洞（CVSS v3，带时间指标）
一个本地提权漏洞，攻击者需要低权限账号，且需要用户交互（比如运行一个恶意程序）。漏洞已公开利用代码，但厂商已发布补丁。
基础向量：CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
时间向量：E:F/RL:O/RC:C
基础分计算：
- Exploitability = 8.22 × 0.395（AV:L）× 0.44（AC:H）× 0.275（PR:L）× 0.62（UI:R）= 8.22 × 0.0296 = 0.24
- Impact = 6.42 × (1 - 0.44×0.44×0.44) = 5.87
- 基础分 = min(5.87 + 0.24, 10) = 6.1（中危）
加入时间指标调整：
- E（利用代码成熟度）：F（功能代码可用）= 0.95
- RL（修复等级）：O（官方补丁）= 0.95
- RC（报告置信度）：C（已确认）= 1.0
- 时间分 = 6.1 × 0.95 × 0.95 × 1.0 = 5.5（中危）
你看，虽然基础分是 6.1，但因为官方已经出了补丁，时间分降到了 5.5。这就是时间指标的意义——它告诉你「现在」这个漏洞有多危险。
3.4.3 案例三：CVSS v4 计算示例
一个 API 未授权访问漏洞，攻击者从网络发起请求，无需认证，无需交互。漏洞导致敏感数据泄露（机密性高），但完整性和可用性不受影响。
v4 向量：CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
v4 的计算公式比 v3 复杂，但核心逻辑类似：
- 可利用性子得分 = 基于 AV、AC、AT、PR、UI 的加权组合
- 影响子得分 = 基于 VC、VI、VA、SC、SI、SA 的加权组合
- 最终分 = 可利用性子得分和影响子得分的函数
这个案例的最终 v4 基础分约为 7.7（高危）。相比 v3，v4 对「仅机密性影响」的漏洞评分更精确，不会因为其他指标为 N 就过度降低分数。
实战要点：我建议你准备一个 CVSS 计算器（NVD 官网或本地工具）。手动算一次之后，再用工具验证。我刚开始学的时候，经常把 PR 和 UI 的权重系数搞混。多算几次就熟了。
3.5 CVSS 评分体系知识结构图
下面这张图帮你理清 CVSS 的整体框架和计算流程：
3.6 常见误区与避坑指南
最后，我总结几个我在实际工作中经常看到的误区：
- 误区一：只看基础分，不看时间分和环境分。一个基础分 9.8 的漏洞，如果只在特定硬件上存在，且你的环境没有该硬件，环境分可能降到 3.0 以下。别盲目恐慌。
- 误区二：把 CVSS 分数当作唯一决策依据。CVSS 不考虑业务影响。一个 7.5 分的漏洞如果影响你的核心支付系统，优先级可能比一个 9.0 分但只影响测试环境的漏洞高得多。
- 误区三：忽略作用域（Scope）的判断。我见过有人把容器逃逸漏洞的作用域写成 U，导致评分偏低。记住：只要漏洞能跨越安全边界，就是 C。
- 误区四：v3 和 v4 混用。两个版本的评分标准不同，同一个漏洞在 v3 和 v4 下的分数可能差 1-2 分。做报告时一定要注明版本。
我曾经踩过的坑：有一次做漏洞评估，我直接用了 NVD 上的基础分 9.8，没做环境调整。结果安全团队花了两周修复一个实际上只影响内网非核心系统的漏洞。后来我养成了一个习惯：每次评估都至少算一遍环境分，哪怕只是粗略估算。这个习惯帮我省了不少冤枉时间。
好了，CVSS 评分体系的核心内容就这些。记住：分数是工具，不是目的。理解每个指标背后的含义，你才能真正用好它。