CVSS 3.1 的通用基础分是 9.8。这个数字出现在 2021 年 Log4Shell 漏洞的漏洞评分里，当时几乎所有安全团队都在连夜打补丁。评分但如果你问一个干了十年的系统运维，9.8 和 10.0 在实际应急时有多大区别，通用他大概会告诉你：区别不大，漏洞反正都得修。评分

通用漏洞评分系统（Common Vulnerability Scoring System）最早由 NIAC 在 2004 年提出，系统后来交给 FIRST 维护。通用它的漏洞核心思路很直白——把漏洞的严重程度拆成几个可量化的维度，算出一个 0 到 10 之间的评分分数。0 是系统毫无影响，10 是通用灾难级。听起来很科学，漏洞对吧？评分

但 CVSS 有个容易被忽略的问题：它衡量的是漏洞本身的技术严重性，不是你的业务风险。一个 CVSS 9.8 的漏洞，如果只存在于内网测试环境、没有任何敏感数据、也不对外暴露，它的实际风险可能远低于一个 CVSS 6.5 但直接暴露在公网、连着核心数据库的漏洞。这个道理说起来简单，实际操作中却经常被忽略。我见过太多团队拿着扫描器输出的 CVSS 分数从高到低排队修，修完 9 分以上的，觉得万事大吉，结果被一个 5.3 的漏洞打穿。

CVSS 3.1 的评分由三组指标构成。基础指标（Base）描述漏洞固有特性，比如攻击向量、攻击复杂度、权限要求、用户交互、影响范围，以及机密性、完整性、可用性三个维度的影响。这些指标一旦确定，分数就固定了。临时指标（Temporal）考虑漏洞利用代码的成熟度、修复级别、报告可信度。环境指标（Environmental）最灵活，允许你根据自己组织的实际情况调整。问题在于，大多数工具只输出基础分，临时和环境指标几乎没人填。这就像买鞋只看尺码不看脚型。

2023 年 CVSS 4.0 正式发布。新版本引入了“攻击要求”概念，把“用户交互”拆得更细，还增加了安全度量组。FIRST 的官方说法是 4.0 能更好地区分漏洞的利用前提。但现实是，截至 2024 年底，主流漏洞库和扫描器对 4.0 的支持仍然参差不齐。很多 CVE 编号的漏洞同时挂着 3.1 和 4.0 两个分数，安全工程师在工单系统里看到两个数字，往往不知道该信哪个。

更实际的麻烦在于评分的主观性。CVSS 的每个指标都有明确定义，但落到具体漏洞上，不同评估者给出的分数可能差出两三分。比如“攻击复杂度”这一项，有的评估者认为需要特定配置才算“高”，有的认为只要不是默认配置就算。这种模糊地带在 3.1 里尤其明显——官方文档给的是原则，不是判定表。

我的看法是：CVSS 是个有用的参考坐标，但不是决策依据。把它当成漏洞严重性的“出厂标称值”，然后结合资产重要性、暴露面、已有缓解措施、威胁情报里的实际利用情况，重新排优先级。一个 CVSS 7.5 的漏洞如果有公开 EXP 且你的资产在 Shodan 上能搜到，它的处置优先级应该高于一个 CVSS 9.1 但利用条件极其苛刻、且你已经部署了虚拟补丁的漏洞。

工具是死的，判断是活的。CVSS 给了你一把尺子，但量什么、怎么量，还是得自己来。