漏洞优先级：哪些系统应先检查？

先确认公告是否适用于您的系统

公告中出现产品名称，只是检查的起点。实际部署版本、受影响组件，以及厂商公告列明的前提条件，才决定系统是否受影响。网页显示的版本可能已经过时，产品清单也可能遗漏正在运行的服务。因此，应与负责运维的团队或服务商一起，将公告与最新资产清单进行核对。

分别记录生产环境、测试环境、不同地点和客户环境中的实例。对 IT 服务商而言，多个客户使用同一种产品，并不意味着可以只做一条统一记录。若版本尚不清楚，受影响情况仍待确认。这是一项需要查明的具体任务，不能据此认定系统安全。

下方决策图是我们的编辑分析，将技术情况放到企业环境中考虑：哪些系统受影响、谁能访问，以及有哪些漏洞利用证据？同时记录相关数据、权限和业务流程。

互联网可访问的系统值得重点关注，但内部系统同样需要评估。已登录用户或已被入侵的设备，可能形成另一条访问路径。只有在防护措施确实阻断相关攻击路径时，才能将其作为降低暴露风险的依据。

从公告到决策

结合业务影响、责任人和处理时间。

确认实际运行版本和修复效果。

编辑决策图：结合业务环境评估三个检查层面，不自动生成风险评分。

不要将这些值相加，生成一个看似精确的总分。记录信息来源和查询日期，并将最终决策与支撑它的信号分别记录。 [1] [2] [3] [4]

左右滑动可查看完整表格。

CVSS、EPSS 和 KEV：各自表达的信息及其局限。
信号	描述什么	仅凭它不能得出什么结论
CVSS 基础评分（CVSS-B）	根据漏洞自身特征评定的技术严重程度，与您的具体运行环境无关。	团队应该先修复哪个漏洞。判断优先级还需要结合具体系统和业务情况。
EPSS	对未来 30 天内，在真实攻击中观察到已公开 CVE 被利用的概率估计。	您的企业遭受攻击的概率，也不能据此证明攻击已经在进行。
CISA KEV	收录已知被利用漏洞的目录。漏洞被列入目录，是检查受影响系统的重要信号。	没有被列入目录，既不能证明安全，也不能证明没有攻击。

当系统确实受影响、存在可用访问路径，并有可靠的利用证据时，应直接交由相关负责人决定处置。评估厂商补丁，以及厂商建议的临时措施，例如关闭受影响功能或限制访问。措施必须适用于您的实际配置。

举一个简化的例子：同一产品中，受影响且面向互联网的员工访问门户，可能比隔离的测试实例更需要优先处理。判断依据是可被访问的账户和业务后果，而不只是产品名称。对于其他系统，数据丢失、生产中断或广泛权限，可能决定处理顺序。

同时安排必要的功能测试、维护窗口和回退方案。如果推迟更新，应明确责任人，并确定重新评估的具体日期。

补丁管理也包括确认补丁是否正确安装。为了让结果可追溯，应记录哪个实例发生变化、当前实际运行的版本，以及如何验证修复。补充功能测试，并更新资产清单。

对于临时措施，还应记录其局限，以及何时用永久修复替代。如果发现此前可能已遭入侵的证据，应转入事件响应流程。仅仅安装补丁，无法回答系统是否已被入侵这一问题。 [5]