补丁管理（patch management）是指定期发现、排序、测试并安装企业所用软件的更新（补丁），范围从网站插件一直到服务器操作系统。大多数补丁修复的是已经公开的缺陷或安全漏洞。漏洞一旦公开，攻击者就会去找还没有更新的系统，所以从补丁发布到实际安装之间隔了多久，影响很大。
对中小企业来说，更新本身通常并不难。问题多半出在：不清楚哪些系统需要更新，不清楚由谁负责，或者担心更新后系统出故障。
哪些地方需要打补丁
一个企业网站或 Web 应用，依赖的远不止当初委托开发的那部分代码：
- 操作系统：服务器、虚拟机和员工电脑。
- 服务器软件：Web 服务器、数据库，以及 PHP、Node.js、.NET 等运行环境。
- 平台和 CMS：例如 WordPress、Magento 或其他电商和内容管理系统。
- 插件、主题和扩展。
- 程序库和依赖包：自研代码中使用，很多由包管理工具自动引入。
- 网络和安全设备：防火墙、路由器和 VPN 设备都有各自的固件。
- 云服务和托管服务：服务商负责其中一部分的补丁，其余仍由你自己负责。
一套实用的补丁流程
1. 建立清单
不知道自己有哪些系统，就谈不上打补丁。用一份简单的清单记录每个系统、所用软件和版本、负责维护的人以及部署位置。清单里要包括插件和主要程序库，而不只是服务器。
2. 关注更新和安全公告
订阅所用软件厂商和开源项目的安全公告，同时留意 CMS 或主机控制面板里的更新提示。如果开发方或支持服务商已经在跟进，最好向对方确认一下。
3. 按风险排序
并不是每个更新都要马上处理。CVSS 这类严重程度评分可以参考，但另外两个问题往往更关键：这个漏洞是否正在被攻击者利用，受影响的系统是否能从互联网直接访问。美国网络安全和基础设施安全局（CISA）发布的“已知被利用漏洞”（Known Exploited Vulnerabilities，KEV）目录，收录了有证据表明已被实际利用的漏洞，可以用来判断哪些补丁应优先处理。公开网站上的严重漏洞，一般应排在内部工具的小修复之前。
4. 先测试，再上线
先把更新装到预发布环境，再检查对业务最重要的流程，比如登录、结账、预约和表单。回归测试无论手动还是自动，都能帮助确认现有功能在更新后依然正常。
5. 安排维护窗口
事先约定在访问量较低的时段做例行更新；如果网站可能短暂无法访问，要提前通知员工或客户。紧急安全补丁未必等得到下一个窗口，所以要另外准备一条更快的处理通道。
6. 准备回滚方案
更新前先做备份或快照，并确认怎么恢复。记下原来的版本号，万一更新出问题，可以尽快退回。
7. 核实并记录
更新后确认新版本已经生效、网站运行正常。网站监测可以发现之后出现的报错或宕机。每次更新了什么、什么时候更新、由谁操作，都要记录下来。
已停止支持的软件
每个软件版本最终都会停止支持（end of life），此后厂商不再发布安全补丁，新发现的漏洞也就不会再修复。要记录操作系统、运行环境和平台的支持期限，在到期前提早安排升级。跨越好几个大版本的升级往往需要开发工作量，更新一拖再拖，正是技术债累积的原因之一。
由谁负责？
打补丁的责任经常说不清，尤其是网站由一家公司开发、由另一家公司托管的时候。应当写明每一层由谁处理：主机服务商、开发方、内部 IT 还是支持服务商。软件支持 SLA 可以写明包含哪些更新、紧急安全补丁多快完成，以及如何测试。如果没有书面约定，就应当默认没有人在做。
Web 应用防火墙（WAF）可以在补丁测试期间降低风险，但不能代替更新。technine.io 的托管支持及 SLA 服务把安全补丁和依赖包更新纳入日常维护。
常见问题
多久打一次补丁比较合适？
不少团队会按固定周期（比如每月）做例行更新，紧急安全补丁则在测试完成后尽快安装。合适的频率取决于每个系统对外暴露的程度和重要性。
要不要开启自动更新？
有些组件适合自动更新，比如维护良好的软件发布的小型安全更新。对业务关键的网站和定制系统，先测试再更新通常更稳妥，因为未经测试的更新可能让插件或系统集成在没人察觉的情况下失效。
用了托管主机方案就够了吗？
要看方案内容。主机服务商通常会给服务器和操作系统打补丁，但不一定包括 CMS、插件或自研代码。要确认方案具体覆盖哪些层面。
更新后网站出问题怎么办？
先恢复备份或旧版本，再到预发布环境排查原因。如果这次更新是安全补丁，在找到可用的更新之前，可以先采取临时措施，比如加一条防火墙规则，或者暂停受影响的功能。