在网络安全领域，及时安装安全补丁和应用更新被广泛认为是保护系统和数据免受攻击的基本措施。这种观点几乎成为了一种“政治正确”，无人敢于挑战。然而，现实情况复杂得多。
补丁很难打
我们在使用PC或手机的时候，补丁安装比较容易，基本自动安装加必要重启就可以了，但在大规模的生产环境的服务器上，这个事其实非常挑战，主要在于：
- 操作系统的升级可能需要重启，重启有可能带来业务中断（不是每个系统都设计成重启不断业务的）。许多系统有SLA(服务水平协议)，比如要求可用性达到99.99%(这就是俗称4个9的可用性)，按这个要求，每年大约只有8个小时能够中断服务。面对成千上百台服务器，要做到不中断业务，很难。
- 升级之前需要做兼容性测试。比如一个数据库的升级，是否会给依赖这个数据库的应用带来故障，这个是需要严格测试的。操作系统的升级也一样。如果是外购软件，这个测试很可能需要原厂商配合。哪个企业没有成百上千的应用？工作量不可想象。
- 缺乏大规模补丁自动化升级的工具。Windows和Android有，是因为这个其实程序简单，有人参与。在大规模自动化的情况下，升级会导致应用程序中断，那么升级顺序如何确定，升级后如何自动化判断升级是否成功？有些升级之间还有依赖关系，如何自动化处理？这都是比较头疼的事情。
- 很多情况根本无法升级。比如，现网有很多老旧系统，还跑在老版本的windows上，或者一些已经不再提供支持的Linux上（类似Centos），即使你想打补丁，也没人再发布补丁，也没有补丁可打了。
在很多大企业里，网络安全和运维是两个部门。安全部门下达补丁要求，而运维部门执行补丁安装，在补丁这个问题上，两个部门经常是对立的。对运维部门来说，变更是万恶之源。系统跑得好好的，变更可能导致意外甚至事故，而事故，是任何组织都不能容忍的。安全原因的变更，经常会受到运维的挑战：有安全问题，出事了吗？是不是吓唬人的？再说，即使出了安全问题，也是安全部门的事情。所以，安全要求打补丁的时候，运维心里都是一片羊驼。
你说运维不懂安全吗？其实不是，安全的概念深入人心。在我的经历中，处理大规模的重点安全问题，比如Intel的两个著名漏洞Meltdown and Spectre，比如前几年的Log4j漏洞，我发现运维部门其实比安全部门更着急。
为什么会这样？因为运维部门的安全和安全部门的安全是不一样的。
安全部门看到的安全，不要有漏洞，不要被人入侵，不要被偷走数据。
运维部门看到的安全，业务要能正常运行，不能中断。
双方一致的时候，比如Log4j,运维部门很清楚，这东西能把业务搞挂，所以它积极。
双方不一致的时候，比如操作系统，数据库这些补丁，本来系统躲在后边，一般攻击不到，反而打补丁容易把系统搞挂，被抵制是正常的。
华为云实践
经历了很多的冲突和妥协，华为云在这个问题上做了一些调整：
- 漏洞分类。除了在CVSS分级的基础上，加了两个属性，是否暴露在互联网上，是否受到媒体关注。有这两个属性之一，优先级大幅提升，快速处理，其余的按例行处理。
- 例行处理的，应用类漏洞优先级高于操作系统漏洞。因为应用类漏洞更容易受到攻击，而操作系统漏洞在重重保护之下，攻击难度非常大。
- 更特殊的情况单独处理。比如BMC(服务器主板上用于启动主操作系统的小操作系统，类似于BIOS),其实漏洞多，而且补丁经常得不到更新。而BMC极少用到，最后的方案就是给BMC单独建一张网，跟其它网络隔离，再加上最严格的访问控制，补丁优先级降到更低。
- 特殊情况特殊处理，有些漏洞虽然CVSS分数很高，但由于其部署位置难以攻击，且补丁安装有客观困难的，经过漏洞分析专家委员会分析决策后，也可以延后打。
经过这些方案的处理，安全部门和运维部门在大部分情况下可以达成一致，基本兼顾安全和业务之间平衡。
前几年跟一个CISO讨论安全的目标，他提了8个字：业务不断，数据不丢。我觉得今天这8个字仍然很到位，如果感觉不足，就再加两个，合规。
所以，搞安全的兄弟，安全补丁在处理的时候，应当适度灵活。