关于 WordPress 安全，最常见的建议无非是「随时把一切都保持更新」的各种说法。这话没错，但也不够具体，难以真正派上用场。有些更新很关键，需要当天处理；有些则很次要，可以等到下一个维护窗口。把它们一视同仁，要么导致不断出现打扰性的更新，要么更常见地导致网站被「冻结」——因为每次更新都让人觉得有风险，于是没有人再更新任何东西。
下面是一套务实的 WordPress 安全更新分级处理方法，并配有三个真实案例，说明这套方法如何应用。
三级严重程度体系
第一级：紧急。当天处理。已在实际环境中被主动利用、可远程执行代码、可绕过身份验证，或任何已经发布补丁的漏洞——无论是哪一天、什么时间。
第二级：重要。7 天内处理。已确认的漏洞，暂未观察到被主动利用，CVSS 评分在 7.0 到 8.9 之间。在下一个计划维护窗口打补丁，但不要拖上两周。大多数安全更新都属于这一级。
第三级：次要。下一次例行维护时处理。低严重度漏洞（CVSS 低于 7.0）、包含安全改进但没有关键修复的更新，或一般性的维护版本。可在每月的常规维护中处理。
如何判断严重程度
WPScan 漏洞数据库（单次查询免费）和 Patchstack 都提供 WordPress 插件和主题漏洞的实时信息源，并附带 CVSS 评分。对于你所使用的每个插件，都可以订阅告警。Wordfence 的插件也会在管理后台显示相关的 CVE。
面对任何漏洞披露，都要问三个问题：该漏洞是否已公开并正在被利用？CVSS 评分是多少？利用它是否需要已登录的用户，还是任何人都能触发？「公开、无需认证、评分 9 以上」是最糟糕的组合，几乎总是意味着第一级。
案例一：第一级插件漏洞
一款常用的表单插件发布了修复身份验证绕过问题的补丁。CVSS 评分 9.8。补丁发布当天就有人报告了主动利用。受影响版本：补丁之前的所有版本。
应对：在数小时内打上补丁。如果网站无法立即修复，就先停用该插件，直到可以修复为止。这类漏洞正是那种能在一个周末内大规模攻陷网站的漏洞。
案例二：第二级主题问题
一款被多家代理商客户使用的主题披露了一个存储型 XSS 漏洞。CVSS 7.4。仅限已认证的攻击者。未观察到被主动利用。
应对：安排在本周的维护窗口处理。先在暂存环境中测试更新，然后在五个工作日内推送到生产环境。风险真实存在，但并不紧迫。
案例三：第三级例行补丁
一款常用的 SEO 插件发布了一个次要版本，在功能开发之外附带了「安全改进」。没有提及具体的 CVE，没有严重度评分，也没有活跃威胁。
应对：在每月的常规维护中与其他例行更新一并处理。紧急程度低。
更完整的应对流程
对于第一级，应对是：立即停用或打补丁，扫描网站是否有被入侵的迹象（被修改的文件、新增的管理员用户、意外的计划任务），并且如果该漏洞在打补丁前已公开超过一天，就假定网站可能已被触碰。
对于第二级，应对是：在暂存环境打补丁、测试、推送到生产环境并记录存档。
对于第三级，应对是：与其他更新打包，在一个计划批次中一并处理。
是什么拖慢了站长
及时应用更新的最大障碍是担心把网站弄坏。「万一插件更新把网站搞崩了怎么办？」是一个合理的顾虑，而答案是：先在暂存环境，再上生产环境。以暂存环境为先的工作流程，能把更新从一项高压决策变成一项例行任务。
第二个障碍是不知道哪些更新重要。上文的分级处理方法解决了这个问题。一旦企业有了一套方法，决策就会变成例行公事，而不是每次都要凭判断权衡。
如果在内部完成这样的分级处理超出了你团队的能力范围，维护计划正是为此而生。Defyn 的维护计划包含针对每个网站实际使用插件的持续漏洞监控，因此分级决策会替你完成，恰当级别的应对也会在正确的时间窗口内执行。大多数使用这些计划的客户，直到月底补丁报告出现时，才第一次听说某个漏洞——而这正是你希望从一套安全工作流程中获得的体验。
