漏洞评分只是起点。用真实资产、在野利用证据、可达路径和验证结果建立可执行的修复队列。
扫描器一次列出几百个漏洞时，团队最缺的往往不是另一个总分，而是一张能落实到负责人的修复队列。本文给出适用于网站与云服务团队的排查流程；具体漏洞是否影响你的环境，仍应以厂商公告、实际版本和配置核对为准。
先确认“这个漏洞属于哪个正在运行的资产”
从组件名与版本开始，关联部署位置、运行实例、业务负责人和更新时间。镜像里存在某个包，不代表生产流量一定经过它；反过来，代码仓库已经升级，也不代表旧容器、备用节点和灾备环境已经替换。将“仓库版本”“构建产物”“实际部署”分成三列，可以减少这种判断错位。
优先级需要几种不同的证据
CISA 的 Known Exploited Vulnerabilities（KEV）目录记录已知被利用的漏洞，可以作为修复优先级的一项输入。它不能代替本地资产核对；没有进入目录，也不能据此判定风险很低。
- 利用证据：是否存在可信的在野利用通报，厂商是否已给出紧急处置建议。
- 实际暴露：入口是否面向互联网，是否需要登录，受影响功能是否启用，攻击路径是否真实可达。
- 影响范围：涉及身份系统、敏感数据、共享基础设施，还是隔离的低权限组件。
- 处置条件：是否有受支持补丁，临时措施能否验证，变更会影响哪些关键业务。
不要只按 CVSS 从高到低机械排序。例如，外网入口上存在已被利用的漏洞，通常值得先进入紧急评估；另一个高分漏洞若依赖未启用的功能，也应记录不适用的证据，而不是简单忽略。
让每张工单都有完成标准
工单至少写清受影响实例、目标版本、责任人、期限、临时缓解方式和验证方法。无法立即更新时，缩小入口、关闭受影响功能等措施必须结合具体公告决定，并设定到期复查；不能仅凭“加了 WAF 规则”就关闭漏洞工单。
升级之后，检查实际运行版本、重启或替换是否覆盖所有节点，再回归登录、支付或业务写入等关键流程。若存在疑似入侵迹象，还需启动调查，打补丁本身不能证明已有入侵被清除。
建议保留的复盘记录
记录本次排序依据、延期原因、验证时间和剩余例外。下一轮评估时优先复查这些例外，避免临时措施成为长期无人维护的状态。WordPress 场景还可结合插件更新后的回归清单执行。
参考：CISA KEV 官方目录。资料核对：2026-10-04。本文为通用实践建议，不是某个漏洞的实时影响清单。
