WordPress 安全团队正在做一件听起来有点反直觉的事：把用来「筛报告」的 AI 工具调转过来，让它主动去扫核心代码，在漏洞被别人报告之前先找出来。这套工具尚未上线，WordPress 官方也没有公布发布时间表。
Automattic 安全负责人 Rudy Faile 上周在 Making WordPress Secure 博客 上公布了进展。距离他宣布「核心安全计划」（Core Security Initiative）正好两个月——该计划旨在应对激增的 AI 辅助漏洞报告。
Faile 的原话很直接：
「光是对报告做出反应还不够，我们希望在别人之前找到漏洞。我们构建用来分流转入报告的 agentic 工具——它能读代码、能判断一份报告是否站得住脚——现在被指向了另一个方向：在任何人报告之前猎取核心漏洞。」
从 359 份积压到「两位数」
这套发现工作建立在一个已经在运行的 AI 分流系统之上。据 Faile 的说明，该系统会读取收到的报告、在安全环境中复现问题，并就每份报告是否有效、严重程度如何发布摘要与建议，最终判断权仍由安全研究员掌握。
效果相当明显：
- 自 9 月 1 日收紧计划范围并启用分流系统以来，未分流队列从 359 降到 两位数
- 今年已关闭近 3,000 份报告，而今年收到的报告量超过此前 12 年总和
- 对比之下，这个项目此前大约十年里每月只有 20 到 30 份报告
- 报告量在 7 月冲到 450 份、8 月 773 份；WordPress 的 HackerOne 页面目前显示过去 90 天内有 2,261 份报告
为什么用开放权重模型
Faile 说选择开放权重模型的核心原因是「可控」：
「我们之所以探索开放权重模型，是因为它们能让我们对如何构建、定制和评估发现工具有更强的控制力。模型只是等式的一部分，真正的工作在于那些 harness、工具链和流程——它们让我们能够系统地识别、验证并最终修复漏洞。」
按计划，工具发现的任何问题都会走与其他修复相同的发布流程。
不过工具尚未上线。Faile 告诉 The Repository，团队仍在做基准测试和测试验证：
「我们有意对上线时间保持沉默，因为我们更希望在部署之后再衡量它的效果，就像我们在漏洞分流上做的那样。」
最终目标是做一次对比：研究者提交并修复的漏洞，与自动化发现并修复的漏洞各占多少。Faile 同时确认，上周发布的 WordPress 7.1.4（修复了 22 个漏洞）中的安全团队自有发现并非来自这套新工具。该版本中的问题有相当一部分由 Ben Bidner、Alex Concha、Jon Surrell、Luis Herranz 和 Weston Ruter 等团队成员发现。
另一条腿：Anthropic OSS Scanner
WordPress 也已加入 Anthropic 的 OSS Scanner，这是一个免费项目，会用该公司最强模型对开源项目进行定期安全扫描。Anthropic 于 10 月 8 日开放报名，据 Betanews 报道。
Faile 写道，团队已经开始处理首轮扫描结果标记的问题，并链接到 7.1.4 版本——该版本向 Anthropic 致谢了两份报告。这已是 8 月以来第四个致谢 Anthropic 的核心安全版本。
对 Faile 来说，两条路线并不冲突：
「我不认为这些是相互竞争的工作。我们在攻击者之前发现漏洞的途径越多样、越有效，就越好。」
他的分工判断是：外部扫描器提供了独立的安全发现来源，而自有工具则让团队专注于 WordPress 特有的攻击面、尝试不同方法，并把发现能力直接嵌进安全工作流。
代价：赏金支出与反向信号
效率提升的另一面是账单。上个月 90 天内赏金支出超过 90,000 美元，而自 2017 年 HackerOne 计划启动以来，Automattic 一分未少地支付了每一笔赏金。
被问及是否因此调整赏金额度时，Faile 表示团队希望提高部分赏金：
「我们其实希望为外部研究者发现并负责任披露的关键/高影响漏洞支付更多。我们要奖励有意义的安全研究，而不是让它被劝退。」
其他开源项目却走向了相反方向：curl 项目在 1 月底终止了漏洞赏金计划，原因是低质量 AI 生成报告泛滥；Node.js 在 4 月暂停了自身的赏金计划，因为自 2016 年起为其支付提供资金的 HackerOne 互联网漏洞赏金计划停止接收新提交；10 月 1 日，Google 暂停了其开源项目赏金计划的新产品漏洞提交，理由是自动化报告激增且大多无效。
加速发布与自动化
在发布节奏上，团队在 41 天内发布了四个安全版本，从 9 月 17 日的 7.1.1 到 10 月 28 日的 7.1.4。Faile 写道，一个安全发布流程中的 109 个步骤已有 73% 具备某种自动化。
安全团队成员 John Blackbourn 上周告诉 The Repository，团队正在朝着他们称之为「完美安全发布」的目标努力，包括把过去需要人工在最多 25 个分支上执行的 backport 脚本化。
参照：Drupal 的赏金空缺
与 WordPress 以及 WordPress 生态中多家安全团队的做法不同，Drupal 核心项目当前完全没有运行任何漏洞赏金（bug bounty）计划。按照 Drupal 官方的漏洞报告说明文档，Drupal 协会给出的理由是：它是一家非营利组织，既无力为 Drupal.org 或 Drupal 软件本身支撑赏金项目，也没有可用于支付赏金的钱。
这意味着，对于 Drupal 的安全研究者而言，发现并提交漏洞并不存在经济回报，赏金缺失也就成了推动外部资金进入的直接原因。
核心变化：Faile 公开呼吁企业为 WordPress 安全计划注资
Faile 在文章中提出的诉求主要针对运行在 WordPress 上的企业：希望这些公司赞助专人投入漏洞分流（triage）与版本发布工作，并向赏金计划捐款。
这一呼吁并非孤立动作，而是呼应了 WordPress 执行总监 Mary Hubbard 上个月向生态内 30 多家最大公司发出的一封邮件——她在邮件中请求这些企业共同资助 WordPress 的安全项目。
当被问及自 Hubbard 发信以来是否已有企业承诺出资时，Faile 表示据他了解相关对话仍在进行中，并感谢那些正在与 WordPress Security Team 直接协作的机构。
影响与建议
- 独立核心提交者也在参与募资。独立核心提交者 Aaron Jorbin 在 Faile 文章的评论区回应，表示欢迎更多赞助方，并把自己的 GitHub Sponsors 页面 提供给有意资助的企业。他主导过过去四个版本中的两个，其中包括 7.1.4 版本。
- 对企业的现实影响：无论是出于漏洞披露责任、供应链安全，还是希望直接影响响应速度，WordPress 生态的大公司目前被明确要求承担安全项目的人力与赏金资金。
- 对使用 WordPress 站点的一方：漏洞赏金是否落地，直接影响到问题被发现后的修复优先级与披露流程。资金到位与否，是一个可以从发布节奏和修复速度上观察到的信号。
- 可执行的做法：若你的组织依赖 WordPress，评估是否赞助一个专职的 triage/release 岗位，或按 Faile 文中建议的方式直接为赏金计划捐款，两者都比单纯等待上游响应更直接。
