问是否建议修补已宣布的未使用服务或功能的漏洞？

EN

这是一个风险评估和威胁建模风格的问题，而不是一个艰难的是或否。

您是否愿意承担不修补服务的风险，这可能会在将来被利用--可能会有人在以后运行它。或者您不接受更新操作系统/软件的风险，这可能会对运行中的服务造成不利影响。

只有您的个人情况才能回答这些问题，而且通常会有不同的答案，取决于您正在评估的服务器/应用程序的威胁环境和重要性。

简单地说，对大多数人来说，是的！

这是因为通常很难像您希望或需要的那样隔离特性或服务，而且记录和管理可能在未来场景中使用的未修补代码或服务也很费时。即使是未使用的特性或服务，也避免了在未来架构或用例更改中“忘记”或管理错误的补丁和更新的风险。

然而，正如ISMSDEV所指出的，更准确的答案是，这取决于您的风险评估。所有补救工作，如修补和更新，都应作为风险管理过程的一部分进行管理，而这是在风险/成本/收益等式中获胜的唯一有效方法(除非您已经取消了sec资源的上限！)如果您决定不进行补丁更新，那么您至少应该记录决策，了解由此产生的风险(如何管理将来的用例更改等)，并根据不修补和更新引入的新风险进行重新评估。

因此，简而言之，您正在进行的风险评估过程应该在每种情况下都为您回答这个问题。

列出的两个答案都是正确的。一般来说，即使没有使用服务，修补它仍然是一个好主意，因为它可以帮助减少或消除漏洞。除非您处于一个非常严格的管理环境中，否则很难说“我们不使用该服务，也永远不会使用”。事情发生了变化，并且必须调查是否更新该服务，即使它应该是该推出的一部分，这需要时间，而且可能无法完成。通过自动修补，您可以防止错过该步骤，并在意外或恶意打开该步骤时对其进行修补。

尽管如此，ISMSDEV的反应也是有效的。我还没有为一家拥有无限资源的公司工作。我们都很忙，维护未使用的服务会占用实际生产工作的时间。如果您所处的环境需要保持对更改的严格控制，则修补未使用的服务将需要努力验证更改不会影响其他内容。这会导致开销和对未使用的东西进行验证的延迟，除非您能够证明该费用的回报，否则这可能被认为是浪费金钱。

这样的反应会怎样呢？这个问题并没有解决这个更大的问题:什么样的环境？如果是一堆公司台式机，那么答案很可能是“是”。如果是服务器、制造设备或其他条件和可靠性至关重要的设备，那么对这些设备进行更多的管理可能更有意义。