3. CVSS评分体系：从向量到优先级，一套科学的漏洞度量语言
CVSS，全称Common Vulnerability Scoring System，说白了就是一套给漏洞“打分”的标准。我刚开始做安全运维那会儿，漏洞报告一来，全靠拍脑袋判断“这个严重不严重”。后来引入了CVSS，才真正有了统一的度量衡。你想想看，一个漏洞是打9.8分还是4.3分，背后对应的修复策略完全不同。
这一章，我会把CVSS 3.1的向量拆开揉碎，带你搞清楚基础指标怎么算、时间指标怎么调、环境指标怎么定制，以及最终分数对应的风险等级到底意味着什么。
3.1 CVSS 3.1向量：一串字符背后的秘密
CVSS 3.1的向量长这样：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H。我第一次看到这串字符时，觉得像天书。其实它就是一个结构化的“漏洞画像”，每个字段代表一个维度。
核心结构：向量 = 版本号 + 基础指标组 + 时间指标组（可选） + 环境指标组（可选）
基础指标组是必填项，也是我们日常最常打交道的部分。它包含以下8个维度：
| 指标 | 全称 | 可选值 | 我的理解 |
|---|---|---|---|
| AV | 攻击向量 | N（网络）/ A（相邻网络）/ L（本地）/ P（物理） | 攻击者离目标有多远？网络远程能打，还是必须插U盘？ |
| AC | 攻击复杂度 | L（低）/ H（高） | 攻击者需要特殊条件吗？比如需要特定时间窗口？ |
| PR | 权限要求 | N（无）/ L（低）/ H（高） | 攻击前需要登录吗？普通用户权限还是管理员？ |
| UI | 用户交互 | N（无）/ R（需要） | 需要受害者点一下链接吗？还是后台静默执行？ |
| S | 作用域 | U（不变）/ C（改变） | 漏洞影响是否跨越了安全边界？比如从容器逃逸到宿主机。 |
| C | 机密性 | H（高）/ L（低）/ N（无） | 数据会不会泄露？ |
| I | 完整性 | H（高）/ L（低）/ N（无） | 数据会不会被篡改？ |
| A | 可用性 | H（高）/ L（低）/ N（无） | 服务会不会宕机？ |
我的习惯：拿到一个CVE，我第一件事就是看它的CVSS向量。如果AV是N（网络）、PR是N（无需权限）、UI是N（无需交互），那基本就是“高危预警”了。比如Log4j那个漏洞，向量里这三个全是N，一看就知道要连夜加班。
3.2 基础指标计算：公式背后的逻辑
基础分（Base Score）是CVSS的核心，范围0-10。它由两个子公式组成：
- 可利用性子分数（Exploitability）： 衡量攻击难度。公式：8.22 × AV × AC × PR × UI
- 影响子分数（Impact）： 衡量破坏程度。公式：6.42 × (1 - (1-C) × (1-I) × (1-A))
最终基础分 = 如果影响子分数 ≤ 0，则基础分为0；否则根据作用域（S）是否改变，套用不同公式。
嗯，这里要注意。作用域（S）这个字段，很多人会忽略。它其实是一个“放大器”。如果S是C（改变），意味着漏洞可以跨越安全边界，比如从低权限的Web应用打到高权限的数据库。这种情况下，影响子分数会被加权计算，分数往往更高。
我曾经踩过的坑：有一次评估一个容器逃逸漏洞，我按常规打了9.8分。后来仔细一看，S字段是C（作用域改变），实际计算出来是10分。虽然只差了0.2分，但在我们的内部流程里，10分意味着必须立即启动应急响应。所以，千万别小看S字段。
下面这张图，帮你理清基础分的计算流程：
3.3 时间指标：漏洞的“保质期”
基础分是静态的，但漏洞是动态的。今天还没POC，明天可能就出EXP了。时间指标就是用来反映这种动态变化的。它包含三个字段：
- E（利用代码成熟度）： 从U（未证明）到F（功能代码可用）到H（有公开EXP）到C（有自动化攻击工具）。
- RL（修复级别）： 从O（官方补丁）到T（临时修复）到W（变通方案）到U（不可用）。
- RC（报告置信度）： 从U（未知）到R（合理）到C（已确认）。
时间分 = 基础分 × E × RL × RC。每个因子都小于1，所以时间分 ≤ 基础分。
我的经验：我每周都会更新一次关键漏洞的时间分。比如一个CVE，上周E还是U（未证明），这周突然变成了H（有公开EXP），时间分可能从8.0飙升到9.5。这时候，优先级就得立刻调高。
3.4 环境指标：你的环境你做主
这是CVSS里最灵活、也最容易被忽视的部分。环境指标允许你根据自身业务场景，对基础分进行“定制化调整”。
它包含两个维度：
- 安全需求（CR/IR/AR）： 你的业务对机密性、完整性、可用性的要求有多高？比如金融系统对机密性要求极高（CR:H），而工控系统对可用性要求极高（AR:H）。
- 修改后的指标（MAV/MAC/MPR/MUI/MS/MC/MI/MA）： 如果漏洞在你环境中的实际攻击条件发生了变化，可以在这里调整。比如一个漏洞原本是AV:N（网络），但你的服务器在内网且不对外暴露，就可以改成AV:A（相邻网络），从而降低分数。
环境分 = 基于修改后的指标重新计算基础分，再乘以安全需求因子。
我曾经犯过的错：有次评估一个内部系统的漏洞，我直接用了NVD上的基础分9.8。后来安全审计时被问：“这个系统在内网，且只有管理员能访问，为什么还打9.8？” 我哑口无言。从那以后，我坚持对每个关键系统都做环境分定制。说白了，基础分是“通用评分”，环境分才是“你的评分”。
3.5 评分阈值与风险等级划分
分数算出来了，怎么用？CVSS 3.1定义了五个定性等级：
| 分数范围 | 等级 | 我的建议行动 |
|---|---|---|
| 9.0 - 10.0 | 严重 (Critical) | 立即修复，24小时内必须完成。启动应急响应流程。 |
| 7.0 - 8.9 | 高危 (High) | 尽快修复，72小时内完成。纳入本周迭代计划。 |
| 4.0 - 6.9 | 中危 (Medium) | 按正常排期修复，但需持续监控。 |
| 0.1 - 3.9 | 低危 (Low) | 记录在案，低优先级处理。 |
| 0.0 | 无风险 (None) | 无需处理，但需确认评分无误。 |
但我要提醒你，阈值只是参考。我见过很多团队死磕“7.0以上必须修”，结果一个6.9的漏洞被忽略了半年，最后被利用。所以，我的建议是：
- 结合环境分： 基础分6.9，但环境分可能因为你的业务场景变成8.5。这时候按环境分来。
- 关注时间分： 一个基础分7.5的漏洞，如果时间分因为EXP公开而涨到9.0，优先级立刻提升。
- 不要只看分数： 分数是工具，不是圣旨。一个分数不高但影响核心业务的漏洞，优先级可能比一个高分但影响边缘系统的漏洞更高。
总结一下我的工作流：
- 拿到CVE，先看基础向量，快速判断“是不是高危苗子”。
- 查时间指标，看有没有公开EXP，有没有官方补丁。
- 结合业务环境，定制环境分，得到“真实评分”。
- 对照阈值表，但结合业务影响，最终确定修复优先级。
CVSS评分体系，说白了就是一套“翻译工具”，把漏洞的技术特征翻译成业务语言。你掌握得越深，在跟老板汇报“为什么这个漏洞必须今晚修”时，底气就越足。