开发人员发布安全更新的时间与用户实际应用安全更新的时间之间存在一种竞争条件。与此同时，攻击者将能够了解该漏洞并攻击尚未修补的系统。这个问题可以完全避免吗？如果没有，尽可能减轻它的最佳做法是什么？
在某些情况下，这听起来可能不是一个大问题，例如，当补丁是针对难以利用的复杂问题时，尤其是当软件是封闭源代码时。在这种情况下，攻击者将需要几天的时间来开发漏洞，并且用户有足够的时间来更新系统。但在其他情况下，这种竞争条件的影响实际上是灾难性的。想象一下 GitHub 上的一个开源项目中的以下提交：
- echo '<span>' . $username . '</span>'; // line removed
+ echo '<span>' . htmlspecialchars($username) . '</span>'; // line added
这显然是对持久性 XSS 漏洞的修复。即使假设安全更新在提交后仅一小时公开发布，并且用户将在发布后仅一小时进行更新（这完全不现实），这将导致两个小时的窗口即使是没有经验的攻击者也能在一分钟内利用的漏洞。对于非常流行的软件，自动攻击在安全更新发布后仅几个小时就开始的情况并不少见，有时甚至在正式发布前不久就开始了。
那么可以做些什么来完全避免或部分缓解这种竞争状况呢？认真对待系统安全的供应商和客户使用了哪些最佳实践？以下是我想到的一些可能的解决方案：
- 不要让源代码随时可用，可能是通过编译或混淆它。这是专有软件经常做的事情。我想微软依赖于这样一个事实，即对他们的补丁进行逆向工程需要时间，同时所有用户都可以进行更新。
- 不要宣传安全修复程序。只需修复并发布它，无需告诉任何人您已修复任何内容，或在任何地方留下任何提示。这可能会延迟攻击，但也可能会延迟更新，因为用户可能会认为“这听起来不重要，我稍后会更新它”。
- 强制自动修补安全漏洞。在发布任何公告或提供任何安全建议之前，系统将尽快自动修补，仅修复安全问题，避免破坏任何功能。这听起来是个好主意，前提是所有系统几乎同时在短时间内打上补丁。默认情况下，Wordpress 会为其核心执行类似的操作，但我不知道更新所有安装需要多长时间（有数百万个）。
- 依靠安全公司的服务来领先于攻击者。有些安全公司声称可以像攻击者一样监控各种事情（检测和调查新的攻击，查看官方公告，甚至从黑帽社区收集信息等），并通过特殊的方式帮助您领先于攻击者建议、网络防火墙等。这似乎是另一种流行的解决方案，但它并没有真正解决比赛问题，它只是试图加快比赛速度。此外，此解决方案可能对流行的软件有所帮助，但我想很难找到可以帮助不太常见的应用程序的服务。
我现在想不出别的。