同样是 9 分的两个漏洞，为什么处置顺序不一样
两个评分相同的高危漏洞，为什么实际处置顺序不同，评级里的指标组合该怎么读？原因在于分数是算出来的结果，不是风险排名本身。规范文档明确写着：数值相同的 CVSS 分数，因用于计算的指标不同而含义差别很大。
分数是怎么算出来的
CVSS v4.0 的 Base 指标评估得出 0.0 到 10.0 的评分，并且会与假设威胁与环境指标取最高严重度的默认值组合，再按严重性分级落到区间上：0.1 至 3.9 为低、4.0 至 6.9 为中、7.0 至 8.9 为高、9.0 至 10.0 为最高一档。这套设计的目的，是让不同来源的公告有一个可比的外壳；但它同时意味着，两条同为 9 分的记录，可能一条是”无需身份即可触发、影响全部数据”，另一条是”需要管理员账号才能触发、只影响可用性”。
同分为何不同风险
| 指标维度 | 会明显改变处置顺序的取值 | 对内容站的实际含义 |
|---|---|---|
| 攻击向量 | 可经网络远程触发 | 公网可访问的接口都要假定被扫 |
| 所需权限 | 无需身份即可利用 | 未登录可打的问题优先于后台内问题 |
| 用户交互 | 不需要诱导点击 | 自动化扫描即可命中，等待成本高 |
| 影响的范围 | 涉及机密性或完整性 | 数据外泄与内容被篡改优先 |
| 环境条件 | 依赖特定组件在装 | 没用到该组件时可降级处理 |
排序差别就落在这几行的组合上。同分只说明加权结果一样，不说明被利用的门槛一样。
排序该看触发门槛
把处置顺序排出来的实用方法，是先问触发条件是否已经具备：这个缺陷依赖的功能有没有开、有没有对外暴露、攻击者需不需要先拿到账号。内容站上常见的两条判断是——列表与查询拼接类的注入点，因为对外列表页默认公开，优先级通常高于需要登录后才能触及的问题；而登录链路一旦被绕过，影响面直接扩到后台所有能力，即便单次影响看起来局限，也要按高优先级排。
自家修复项怎么落进日历
AnQiCMS 的 v3.6.6 列出两项高危修复：列表排序参数存在的 SQL 注入，以及站点切换使用的登录凭证可被伪造、改为一次性票据处理。这两项分别对应上表里的两类门槛——对外可见的查询入口，和身份凭证本身。公告的升级建议同时包含轮换服务端签名密钥与修改管理员口令，说明处置动作不止于替换程序文件。排维护日历时，”是否对外暴露相关入口”决定了要不要按紧急窗口处理，”是否需要轮换凭证”决定了升级之后还要留多少动作。
基础能力负责缩小面，不负责排序
JWT 认证、内容敏感词过滤与防采集干扰码属于站内既有防护层，它们的作用是把常见的 SQL 注入与 XSS 尝试挡在应用逻辑里，而不是替你把公告排出先后。评级读法解决”先修哪个”，基础能力解决”没来得及修的这段时间风险有多大”，两件事不能互相顶替。
常见问题
只看分数最高的一档安排工作会不会漏？ 会。同档内触发门槛差别很大，需要登录才能利用的问题和无需身份即可打的问题，放在同一个窗口里处理会让对外暴露面多留几天。
评级相同、组件不同，怎么决定先后？ 加上”自己是否在用”这一层：未安装或未开启的组件相关缺陷可以直接降级，用到且对外暴露的优先。
分数没到最高档就一定能延后吗？ 不一定。若缺陷影响的是发布链路或凭证体系，即便分数在高一档，也应按紧急跟进处理。