当CVSS响起时

“CVSS 9.8，远程可利用，无需认证，高危。”
—— 每当我在漏洞报告中看到这句话，我的心里总会泛起一阵复杂的情绪。
“CVSS 9.8, remotely exploitable, no authentication required, HIGH severity.”
— Every time I see this line in a vulnerability report, a complex emotion stirs within me.

作为一名信息安全工作相关人员（Information Security Professional），我每天都在和漏洞（vulnerability）打交道。而CVSS（Common Vulnerability Scoring System，通用漏洞评分系统），就像一位沉默的“法官”，为每一个漏洞打上一个分数，决定它在我们心中的优先级。

但你知道吗？每当我看到那个数字——无论是 7.5 还是 10.0——我的第一反应从来不是“哦，高危”，而是：

“这分数，真的能代表风险吗？”
“Does this score truly reflect the actual risk?”

一、初识 CVSS：我以为我有了“标尺”

刚入行时，CVSS 对我来说，是秩序的象征（a symbol of order）。

以前，我们判断一个漏洞要不要修，靠的是：

• “这个服务重要吗？”（Is this service critical?）
• “会不会被攻击？”（Can it be attacked?）
• “老板觉得严重吗？”（Does management think it’s severe?）

——混乱、主观、充满争论。

直到 CVSS 出现。它用一套公式，把漏洞的攻击向量（Attack Vector, AV）、攻击复杂度（Attack Complexity, AC）、权限要求（Privileges Required, PR）、用户交互（User Interaction, UI）以及影响范围（Scope, S）量化成一个 0.0 到 10.0 的分数。

它告诉我们：

• ≤3.9：低危（Low）
• 4.0–6.9：中危（Medium）
• 7.0–8.9：高危（High）
• ≥9.0：严重（Critical）

那一刻，我仿佛拿到了一把“安全尺子”（a security ruler）。
我可以指着报告说：“这个是 9.8，必须马上修！”——终于，有了依据，有了底气。

二、熟悉 CVSS：我开始怀疑那把“尺子”

可时间久了，我发现：CVSS 评分，有时比漏洞本身更让人头疼。
Over time, I realized: sometimes, the CVSS score is more troubling than the vulnerability itself.

场景一：“9.8 的漏洞，修了三个月还没排上日程”

某天，扫描工具报出一个 Apache Log4j 的漏洞，CVSS 10.0，远程代码执行（Remote Code Execution, RCE），零点击（zero-click）。所有人惊呼：“Log4Shell！”
可开发团队说：“这个组件在内部工具里，不对外，修它会影响上线。”

我沉默了。

CVSS 告诉我这是“核弹级”漏洞（nuclear-level vulnerability），但业务上下文（business context）告诉我：它可能不会被利用。

🔍 CVSS 评估的是“技术严重性”（technical severity），而不是“实际风险”（actual risk）。

场景二：“3.5 的漏洞，却成了攻击入口”

另一个例子：一个内部系统的弱密码策略（weak password policy），CVSS 3.5，属于“低危”（Low）。

没人关注。

结果，攻击者通过社会工程（social engineering）获取了一个账号，从这个“低危”入口一路横向移动（lateral movement），最终拿下域控（Domain Controller）。

CVSS 没错——它确实不是“漏洞”，而是“配置问题”（configuration issue）。
但它忽略了：攻击是从边缘开始的，不是从“高危”开始的。
Attackers don’t start from “high-severity” flaws — they start from the edges.

三、理解 CVSS：它不是风险，而是“潜在技术影响”

我渐渐明白：

CVSS 评分的，不是“风险”（risk），而是“漏洞的潜在技术严重性”（potential technical severity of a vulnerability）。

它回答的是：

• 这个漏洞理论上能造成多大破坏？（What’s the theoretical impact?）
• 攻击者需要什么条件才能利用？（What conditions are required for exploitation?）

但它不回答：

• 这个系统是否暴露在互联网上？（Is the system internet-facing?）
• 攻击者是否有动机攻击它？（Is there an attacker motivation?）
• 企业是否有补偿性控制（compensating controls）？如 WAF（Web Application Firewall）、EDR（Endpoint Detection and Response）、网络隔离（network segmentation）

换句话说：CVSS 是漏洞的“体能测试”（stress test），而不是“实战表现”（real-world performance）。

四、超越 CVSS：我们需要“上下文”来补全拼图

于是，我开始学会在 CVSS 旁边，加上自己的“注释”：

我们开始引入：

• EPSS（Exploit Prediction Scoring System，漏洞利用预测评分系统）：预测漏洞被利用的概率
• 威胁情报（Threat Intelligence）：是否有活跃利用？是否在野（in-the-wild）？
• 资产重要性（Asset Criticality）：数据库 vs 测试服务器
• 缓解措施（Mitigations）：WAF 规则、网络隔离、最小权限（least privilege）

真正的风险 = CVSS × 可利用性 × 业务影响
True Risk = CVSS × Exploitability × Business Impact

五、我与 CVSS 的和解

如今，我依然每天看 CVSS。

但我不会再被那个数字“绑架”。

我知道：

• CVSS 是起点，不是终点（CVSS is the starting point, not the endpoint）
• 高分要警惕，但不必恐慌（High score? Be cautious, not panicked）
• 低分要关注，尤其在关键路径上（Low score? Still monitor, especially on critical paths）

我们不能因为一个漏洞是 CVSS 10.0 就全员加班，也不能因为它是 3.0 就置之不理。

六、写给未来的我们

CVSS 已经进化到 CVSS v4.0，引入了更多维度：

• Subsequent System Impact（后续系统影响）
• Security Requirements（保密性 Confidentiality、完整性 Integrity、可用性 Availability 权重）

这很好。但再完美的评分系统，也无法替代人的判断（human judgment）。

作为安全人，我们要：

• 懂技术（Understand the tech）：才能理解 CVSS 的计算逻辑
• 懂业务（Understand the business）：才能判断真正的风险优先级
• 懂攻击者（Think like an attacker）：才能预判他们的路径（attack path）

✅ 结语：看到 CVSS，我在想什么？

我在想：

这个漏洞，在我们的环境中，真的会被利用吗？
Can this vulnerability actually be exploited in our environment?

修复它的代价，比被攻破的代价小吗？
Is the remediation cost lower than the breach cost?

如果我是攻击者，我会从这里下手吗？
If I were an attacker, would I start here?

CVSS 给我一个数字。
而我的职责，是把这个数字，翻译成真正有意义的行动。

评分决定优先级，但上下文决定风险。
Scoring determines priority, but context determines risk.
—— 一个安全人的日常所思所想
—— A security practitioner’s daily reflection

📎 附录：常用术语中英文对照表