一个SQL注入点，网络在漏洞库里的安全评级是“高危”，CVSS评分9.8。漏洞但放到一家只有二十台服务器、等级数据价值约等于零的网络初创公司身上，它可能连个水花都溅不起来。安全反过来，漏洞一个看似不起眼的等级逻辑漏洞——比如密码重置接口不校验旧密码——在银行系统里，那就是网络能搬空金库的钥匙。所以，安全别迷信那个数字。漏洞

漏洞等级的等级本质，是网络风险度量，不是安全技术难度标尺。CVSS（通用漏洞评分系统）试图用一组向量——攻击向量、漏洞攻击复杂度、所需权限、用户交互、影响范围——来量化漏洞的“内在属性”。它假设了一个理想环境：攻击者能触达，系统有敏感数据，影响是直接的。可现实里，这个假设经常不成立。

我见过一个真实的例子。某政务平台，一个文件上传漏洞，理论上可以上传WebShell，拿下服务器权限。按CVSS标准，这妥妥的“严重”。但实际测试发现，服务器上跑了WAF，上传目录禁了脚本执行，而且后端存储用的是对象存储，跟应用服务器物理隔离。攻击者折腾半天，最多往云桶里扔个垃圾文件。这个“严重”漏洞，实际危害连“中危”都够呛。

反过来，有些漏洞在CVSS里得分不高，实战中却能致命。比如一个越权接口，攻击者只需改个ID就能查看他人订单。CVSS给它的分可能只有5.3（中危），因为“机密性影响”是“部分”，而且需要“低权限”。但在电商场景里，订单包含手机号、地址、支付记录，一个越权能批量遍历所有用户数据——这性质就变了。评级表上写着“中危”，风控部门看到这个级别可能排到下个月，但攻击者当晚就能把数据拖走。

所以，真正靠谱的等级划分，得结合资产价值、暴露面、缓解措施和业务影响来动态调整。我习惯用四象限：高暴露+高价值（比如公网API的RCE）——立即修复，通宵也得干；高暴露+低价值（比如官网的反射型XSS）——排期修复，但别拖太久；低暴露+高价值（比如内网核心库的弱口令）——尽快修，但可以先做访问控制兜底；低暴露+低价值（比如测试环境的目录遍历）——记录在案，有空再说。

这种划分方式，比单纯看CVSS数字实用得多。你拿着“严重”的评级去找开发，人家可能回你一句“这功能本来就没打算公网开”。但你拿着“能拖走全量用户手机号”这个事实去，没人敢不修。漏洞等级，说到底是个沟通工具——你得让决策者明白，不修这个洞，具体会损失什么。

别忘了还有个变量：时间。同一个漏洞，在0-day刚暴露时是“严重”，厂商发布补丁后降为“高危”，等大多数系统完成升级，它可能就变成“中危”甚至“低危”。威胁情报里有个概念叫“利用成熟度”，跟漏洞的“新鲜度”强相关。一个2017年的Apache Struts2 RCE，放到今天，大部分暴露面已经被防火墙和WAF挡掉了，实际可利用性大打折扣。

所以，我的建议很简单——别把评级当圣旨。看漏洞报告时，先问三个问题：这个系统暴露在公网吗？它存了什么数据？被攻破后最坏的后果是什么？想清楚这三件事，你自己心里就有个比CVSS更准的等级了。工具是辅助，判断才是核心。