收到高危漏洞通报先做四件事
漏洞应急最容易走两个极端：一是看到 CVSS 高分就全员停机升级，二是评估拖着不动。可复用的方法只有四步：定位受影响组件与版本、判定可达性（端口是否暴露、功能是否开启、前置条件是否满足）、结合可达性定级与修复时限、修复后验证并归档证据。CVSS 分数只描述漏洞本身，是否真的能被利用取决于你的部署方式，所以可达性判断是整条链路的核心环节。
基本信息
| 加固项 | 漏洞应急评估与闭环 |
|---|---|
| 适用平台 | 全部平台（操作系统、中间件、应用、容器镜像） |
| 权限要求 | 安全与运维协同，定级需负责人确认 |
| 达标判据 | 每起高危漏洞都有评估结论与处置记录（含“不受影响”的判定依据） |
| 参考框架 | NIST SP 800-40、等保漏洞管理要求 |
典型使用场景
- 收到厂商或监管的高危漏洞通报后的快速响应
- 攻防演练期间对暴露面相关漏洞的优先处置
- 季度资产盘点时补充组件版本信息
- 处置后回答审计提问：“为什么这台机器判定不受影响”
- 复盘时核对响应时限是否达标
评估四步骨架
评估四步骨架
# 1) 资产与版本：谁在用这个组件
# grep -Ri '组件名' /opt/*/deps.txt 2>/dev/null | head
# rpm -qa | grep -i <组件名>; dpkg -l | grep -i <组件名>
# 2) 可达性：端口是否暴露、功能是否开启、是否需要认证前置
ss -tulnp | grep <端口>
# 3) 定级与时限：按可达性打折或升级，明确修复截止时间
# 4) 处置与验证：升级或加缓解措施，修复后复测并归档证据
systemctl status <服务> --no-pager | head -5可达性判定维度
| 维度 | 高风险情形 | 可降级情形 |
|---|---|---|
| 网络暴露 | 端口对公网开放 | 仅内网可达且有访问控制 |
| 功能开关 | 相关模块已启用 | 模块未启用或已禁用 |
| 认证前置 | 未认证即可触发 | 需要高权限账号才能触发 |
| 组件版本 | 版本落在影响范围内 | 版本已高于修复版本 |
| 代码路径 | 实际业务调用到受影响函数 | 功能未使用，仅组件存在 |
评估结论必须书面化，且“不受影响”也要写清依据：版本不在影响范围、相关功能未启用、端口未暴露，三条中具体是哪一条。这类记录是审计与复盘最看重的部分，也能避免同一个漏洞在下一轮检查时被反复翻出来重新评估。
定级不要只看 CVSS：不可达的组件全量紧急升级会浪费维护窗口，还引入变更风险；反过来，可达的高危漏洞拖过时限则等于把决定权交给攻击者。响应时限应当在制度里先定好（例如高危 24 小时内完成缓解、72 小时内修复），而不是每起漏洞临时讨论。