软件安全：持续监测和挑战

关键要点

在Log4j危机之后，及时修补和软件供应链安全终于得到了应有的重视。然而，这一事件深刻的教训是，单纯依赖应用安全的信任是有风险的。确保你的应用安全状态的唯一方式就是对一切进行测试，绝不轻信。

修补并不总是意味着安全

保持软件修补是一项广泛共识的基本最佳实践。对于第三方软件，及时更新到最新版本是防范已知安全漏洞的唯一途径。尽管这一点常常被推荐但由于资源有限或兼容性问题，有时并不现实，大家都知道，安全补丁并不总是如预期的那样奏效，尤其是对于需要快速修补的高风险漏洞。

通常，一种漏洞可能存在多种攻击方式，而一个有缺陷或不完整的补丁可能只能缓解部分攻击，却未能处理其他潜在漏洞。随着安全界对高风险漏洞的关注加剧，通常会出现新的漏洞披露，从而需要更快地推出补丁。

举个例子，Log4j的2150版本迅速修复了最初的RCE漏洞，但很快又发现了另一个漏洞。此后推出的2160版本虽然修复了前一个问题，但又出现了另外两个漏洞。根据目前的资料，2171被推荐为安全版本，更多技术分析请参考我们关于Log4Shell的文章。在2021年10月，Apache 2449版本中发现了路径遍历漏洞。修复在2450中推出，但结果证明这个补丁是不完整的，最终需要在2451中才解决了根本原因。

在网络安全领域，不完整的安全补丁并不罕见。

修复安全缺陷从不是易事

面对第三方产品或组件的漏洞，许多组织别无选择，只能等待补丁的发布，安装并希望其有效。但对于内部开发的网络应用来说，修复安全问题是否更为迅速、便利且有效？理论上应该如此，但全面修复安全问题并在不影响应用其他方面的情况下按时完成实际上是一项微妙的平衡行为。

开发者在解决安全缺陷时可能面临至少十几种障碍，如技能差距、低效的工作流程、工具不成熟及时间压力等。一个明显的主题是，安全问题往往与非安全漏洞分开处理和报告。每一个安全单据都将开发者从流畅的工作环境中拉出，却没有提供足够的指导来识别和修复根本原因。

即使你拥有合适的技能、资源和工具，安全问题也从来都不简单，总会有那些需要时间和精力去调查和修复的漏洞。

无论具体原因如何，漏洞修复往往需要不止一次尝试。尽管借助合适的工具和工作流程，你可以在内部工作中更快地进行迭代。为了迅速、全面地测试补丁是否真正解决了漏洞，仍然是一个不小的挑战。

将零信任理念应用于网络应用安全

从更广的视角来看，安全补丁和漏洞修复只是对应用环境更改的特殊情况。从安全的角度来看，每一次更改，无论是小补丁、配置调整还是重大新发布，都有可能引入新的漏洞或未能修复已经存在的漏洞。你不能盲目相信自己仍然安全，唯一的确保就是对一切进行测试，且要频繁测试。

零信任的理念在全球组织中逐渐受到重