评分标准换了大版本，两条公告的严重度还能不能直接比

漏洞评分标准从3.1换到4.0，两条公告给出的严重度还能不能直接横向比较，答案是分两层看：定性分档可以直接比，具体分数不可以。FIRST 的规范文档写明新版本的模型与来自 CVSS v3.x 的定性严重程度分档边界保持兼容，四档区间仍是 0.1 到 3.9 为低、4.0 到 6.9 为中、7.0 到 8.9 为高、9.0 到 10.0 为严重。也就是说，同一条公告写着 High，换到哪个大版本读，档位含义没变。

分数与定性分档是两层

分数是计算结果，取决于评估者选了哪些指标、怎么取值；分档是把分数落到一个可沟通的区间上。跨版本比较时能靠的是分档，因为它的边界被明确保持兼容；分数则不然，同一个缺陷在两套标准下可能算出不同的数，指标定义、可乘的系数和权重的处理都有差别。

这就是为什么读公告要按顺序：先看它给的是哪个版本的评分，再看它给的档位，最后才看那个小数。只比小数会得出错误结论，比如把两套标准下同为 8.x 的条目当成同一风险，而它们的指标口径可能不同。

跨版本比较时的落差

落差不在档位名，而在指标本身。新版调整了部分指标的定义与取值方式，同一份技术事实可能被算进不同的位置；两处攻击面描述相似的公告，分数差别也可能来自评估者对利用条件的判断不同，而不是缺陷本身轻重。

另一个常被忽略的边界是评估范围。规范说明里写明，因数据泄露造成的经济损失这类因素不在评分范围内。所以「这条公告分数不高」不能推出「对业务影响小」，业务影响是站方自己叠上去的一层，包含数据性质、暴露面和恢复成本。

评分之外还要看什么

三件事比分数更决定处置顺序：利用是否需要凭据、受影响的配置在自己的部署里是否成立、有没有可升级到的修复版本。匿名可利用且在范围内、又没有可升版本的条目，无论档位高低都应先处置；需要管理员凭据的高分条目，反而可能排在后面。

自己站上的暴露面也要单独判断。同一个缺陷，开放注册的站点与只给内部账号使用的站点，风险并不一样，而公告不会替你区分。

自家一次高危修复怎么跟

可以拿一条自家版本对照读法。v3.6.6 修的两项都是高危：列表排序参数里的 SQL 注入，以及站点切换登录凭证可被伪造。这一版没有给你可比的第三方分数，处置依据是问题性质本身——前者可被构造参数触发，后者直接动摇访问控制。

跟进动作因此是成对的：升级程序版本、轮换服务端签名密钥、修改管理员密码，只做完前一步的话，已被伪造过的凭据仍然可用。顺序上先做一份可恢复的备份，把数据与静态文件一起带走，再动版本；改完之后要确认后台登录、站点切换与列表排序三类功能都正常，避免修一处坏一片。

常见问题

两条公告一条写 8.4 一条写 8.1，先跟哪条？ 档位同为高，不能靠小数排序；看是否匿名可利用、是否命中自己的配置、有没有修复版本。

评分高但只在特定引擎触发，要不要插队？ 命中就插队，不命中按正常节奏，但要把核查依据记下来。

公告没给分数怎么办？ 按影响类型读，写入类与认证类通常优先于纯展示类。

分数会不会随时间变化？ 会，评估者对利用条件的认知更新后可能重评，跟进以「是否已修、是否能升」为准。