如果更新到受影响软件的最新版本无法修复报告的漏洞或错误配置，或者没有更新来解决问题，则需要一个过程来分类和确定优先级。
漏洞评估将突出显示需要注意的任何安全、配置或更新管理问题。 若要管理攻击面，应至少每月对整个资产进行一次漏洞评估。 如果您的组织从未运行过组织范围的漏洞扫描，则第一个报告可能包含数百甚至数千个漏洞。 了解攻击面（外部与内部）也很重要。
更成熟的组织应考虑更定期的评估，特别是对于外部可访问的服务。 如果您使用的是内置于云环境中的等效工具，则应遵循提供商建议的节奏。
尽管供应商通常有发布更新的节奏，但可以随时发布更新（称为带外更新）。 如果发现严重漏洞，则可能会发生这种情况。 如果这可能会影响您的组织，那么制定一个流程非常重要，该流程允许您随时评估关注的漏洞。
区分旨在识别漏洞的漏洞评估系统和用于确定软件版本的软件资产管理非常重要。 在某些情况下，单个工具可以同时执行这两种功能，但情况并非总是如此。 有关更多信息，请参阅我们的漏洞扫描工具和服务指南。
定期扫描制度对于让您了解您的组织可能面临的风险至关重要。 它不需要由外部合作伙伴操作，工作人员也不需要任何特殊培训。 NCSC 提供有关如何选择、实施和使用自动漏洞扫描工具的指导。
漏洞和配置扫描还可以突出显示软件更新无法解决的问题，或者自动更新机制无法正常工作的问题，这意味着需要手动修复。 这些漏洞应使用原则 4 中概述的过程进行分类。 漏洞扫描对于突出显示未安装更新的情况也特别有用。
如果您开发软件或运行系统，您还应该考虑建立一个流程，允许安全研究人员向您报告他们发现的任何漏洞。 NCSC 漏洞披露工具包旨在简化披露流程的设置。
有时，安装受影响软件的最新版本可能无法修复报告的漏洞或配置错误，甚至可能没有更新来解决问题。 在某些情况下，不更新可能是合适的：例如，如果系统即将停用，并且漏洞难以发现且难以利用。 通过合理的控制，例如确保继续退役，不续约是完全合理的。
但更多时候，由于员工时间限制或对更新软件兼容性的担忧等限制，组织觉得他们无法解决问题。 充分了解这对组织的潜在影响非常重要。
虽然漏洞评估软件或供应商咨询可能会为发现的问题（例如通用漏洞评分系统或 CVSS）提供严重性评级，但您必须考虑组织的业务影响和风险。
有时，组织可能会评估自动更新的风险太高。 在这种情况下，应将系统添加到例外列表中，并且更新将通过组织要求的任何安全测试。 由于额外的测试可能需要大量时间，因此应将其限制在可用性至关重要且没有安全恢复到已知良好状态的机制的系统中。
如果出于任何原因没有可用的更新，则需要一个过程来对修复进行会审和确定修复的优先级。
您应该合并所有问题并应用相同的分类和优先级排序过程，以便系统所有者能够完全了解相应地管理问题。
会审过程应首先将所有相似的发现或需要相同缓解的结果组合在一起：例如，所有 SSL 问题都成为一个问题。 或者，您可以按类别对它们进行分组，例如外部暴露的漏洞。
一旦分组，它们应分为三类：要解决的问题、要确认的问题或要调查的问题。
修复“适用于将确保系统默认更新的问题，或者将对其实施重新配置或缓解的问题。 应优先考虑漏洞：面向 Internet 的服务或应用程序。
如果成功利用，它将产生最大的负面影响，例如关键共享基础设施中存在的影响
在确定列表的优先级和编制列表时，应记录问题解决的日期。 这可能是供应商表示将发布修复程序的日期，也可能是估计何时可以实施配置更改。 如果修补程序是临时供应商解决方法或缓解措施，则应有时间限制并主动跟踪它，以便在提供并应用完整的供应商修补程序后可以将其删除。
承认“无论你决定在这个时候不解决什么原因。 不立即解决漏洞是有正当理由的，这些原因应与计划的审查日期一起记录在案。 如果它们存在的风险级别足够高，请在风险登记册中记录问题。 如果将来利用漏洞，则承认问题（而不是解决问题）的理由应足以证明所做出的决定是合理的。 您还应该考虑实施额外的监控，以便在已知漏洞已被利用时提醒您。 调查分类无法将其归类为“修复”或“确认”问题。 调查只能用作临时状态。 这可能是因为解决问题的成本未知，或者有多种可能的解决方案，需要做更多的工作来确定哪一个最有效。 漏洞评估软件并非万无一失，可能会发生误报。 如果您怀疑此问题，则应先对其进行调查，然后再将其作为问题删除。 此类问题的时间表将取决于问题的严重性。