漏洞等级定义方法
去年某电商平台被曝出一个SQL注入漏洞，漏洞攻击者能直接拖走用户订单表。等级定义安全团队评估后定为“高危”，漏洞但修复优先级却排在一个“中危”的等级定义越权查看物流信息漏洞之后。理由是漏洞后者更容易被批量利用，影响面更广。等级定义这事说明一个问题：漏洞等级不是漏洞数学公式算出来的，它带着强烈的等级定义业务上下文。
CVSS评分（通用漏洞评分系统）给了我们一套基础坐标系。漏洞基础分看攻击路径、等级定义复杂度、漏洞权限要求、等级定义影响范围。漏洞比如一个需要物理接触设备才能触发的等级定义漏洞，和能远程匿名打穿服务器的漏洞漏洞，基础分差出好几倍。但CVSS有个毛病：它不考虑你的资产值多少钱。一个在测试环境里跑的Log4j漏洞，CVSS可能给9.8，可对你来说它连“低危”都算不上，因为那台机器明天就下线。
所以实际定级时，我会把CVSS基础分当起点，然后套三层过滤器。
第一层，看利用条件。需要登录才能打的漏洞，比匿名可打的低一档。需要诱导用户点击的，再低一档。如果利用链上有个环节依赖特定浏览器版本或者特定配置，继续降。反过来，如果POC已经在GitHub上公开，或者野外在传EXP，那就往上提。去年Spring4Shell刚爆出来那天，我们内部直接把所有相关服务的漏洞临时定为“紧急”，哪怕CVSS只有9.0——因为利用门槛太低了。
第二层，看数据流向和权限边界。一个能读/etc/passwd的本地文件读取漏洞，如果服务跑在容器里且只读挂载，危害有限。但如果那个容器挂载了宿主机的Docker socket，性质就变了，直接算“严重”。同样，一个越权漏洞，如果只能看到自己的订单，那是低危；如果能遍历所有用户的收货地址，高危起步。这里有个容易忽略的点：横向移动的可能性。一个内网Redis未授权访问，单看它自己可能只是中危，但如果它能被用来打内网其他机器，比如写SSH key或者计划任务，那就得按“严重”处理。
第三层，看业务补偿措施。WAF能不能拦？有没有网络分段？日志监控能不能发现？如果这些都有，降一级。如果什么都没有，纯裸奔，升一级。我见过一个团队把某个RCE定为中危，因为他们的WAF规则恰好能拦住那个特定payload。这其实很危险——WAF规则可能被绕过，或者哪天运维手滑关掉了。我的主观判断是：补偿措施只能用来微调，不能用来把“高危”压成“中危”。
再说一个真实案例。某金融APP有个漏洞：修改请求里的用户ID，能看到别人的账户余额。CVSS给6.5，中危。但业务方坚持要按“严重”修。为什么？因为金融监管有硬性要求，任何能导致用户敏感信息泄露的漏洞，不管技术难度多高，都必须24小时内修复。你看，合规要求可以直接覆盖技术评分。
最后说个反直觉的：有些漏洞不该定级。比如一个需要本地管理员权限才能利用的提权漏洞，在服务器上可能算中危，但在员工个人电脑上——员工本来就是管理员——这个漏洞等于没有。定级前先问一句：攻击者需要先拿到什么？如果那个前提本身已经是严重事故了，这个漏洞的等级就该往下压。
漏洞等级定义没有银弹。CVSS是尺子，但量什么、怎么量，得看你的资产、你的对手、你的业务底线。我见过太多团队把CVSS分数直接抄进工单，结果修了一堆“高危”但无关痛痒的漏洞，真正要命的那个反而因为分数不高被晾在一边。定级的人得懂技术，更得懂业务。否则就是拿把游标卡尺去量太平洋。