系统：运行中
EN FR ES ZH
⌕
← 返回所有攻击
GOVERNANCE MEDIUM NEW

压力：开源安全团队在 AI 辅助漏洞洪流下的处境

2026 年 5 月 26 日，curl 项目主开发者 Daniel Stenberg 发表《The pressure》：平均每天超过一份可信安全报告，半个发布周期已确认 12 个 CVE，其他维护者也在同步证实这一趋势。

2026-05-28 // 8 min affects: curl, linux-kernel, apache-log4j, firefox, haproxy, open-source-ecosystem

这是什么？

2026 年 5 月 26 日，curl 项目主开发者 Daniel Stenberg 发表了一篇简短而个人化的文章 The pressure，描述 AI 辅助漏洞研究正在对世界上最普及的开源软件之一的安全流程造成什么影响。数据非常直接：安全报告流入速率达到 2024 年的 4 至 5 倍、2025 年的 2 倍，平均每天超过一份报告，在距离下一次发布还剩半个周期时，已经确认了 12 个 CVE，这意味着 curl 在 2026 年中点之前就已经走在至少 30 个 CVE 的轨道上。

这不是一份漏洞公告。我们之所以报道这件事，恰恰是因为 Stenberg 所描述的现象已经不再仅限于 curl。Simon Willison 在同一天的链接博客中总结了这篇文章。Help Net Security 在 8 天前就记录了更广泛的模式：Linus Torvalds 称 Linux 内核安全邮件列表”几乎完全无法管理”，GitHub 产品安全团队发布了新的提交要求以过滤被 AI 充水的报告。本文要讨论的，是这场运营层面的转变，而不是 bug 计数本身。

它是如何发生的

这里没有利用代码。机制是运营性质的，过去 18 个月里它经历了两个截然不同的阶段。

阶段                 时间段           主导信号                       维护者的应对
-------------------- ---------------- ----------------------------- -------------------------------
1. AI 残渣            2024 年中 →     看似合理、实际幻觉的低质量    赏金计划提高门槛或直接关停
   （AI slop）        2026 年          漏洞报告
2. 高质量混乱         2026 年 3 月 → 详细、可信、常常重复的         「前所未有的压力」；
                     至今             AI 辅助报告                    重新校准 SLA、团队容量、
                                                                     披露流程

第一阶段——AI 残渣。 2025 年全年到 2026 年初，设有公开赏金计划的项目被表面看上去合理、但经不起核实的报告淹没。Stenberg 在 2026 年 1 月的文章 The end of the curl bug-bounty 记录了 curl 的轨迹：确认漏洞的比例从 2024 年的 15% 以上跌至 2025 年的 5% 以下，赏金计划于 2026 年 1 月 31 日关停。Apache Log4j、Nextcloud 等项目走过了同样的路线。Help Net Security 引用 Stenberg 自己的账目，将 AI 残渣估算为 2025 年 curl 提交总量的约 20%，而真正漏洞只占全部提交的约 5%。

第二阶段——高质量混乱。 2026 年 4 月 22 日的 High-Quality Chaos 记录了拐点。在 curl 将报告渠道转移到 GitHub、随后无赏金地回到 HackerOne 之后，残渣大幅下降，确认漏洞率”回到甚至超过了 AI 出现之前的 2024 水平，约 15-16% 区间”——但绝对报告量仍在上升。几乎每份报告都带有 AI 辅助的痕迹，包括”非常详细、人类不可能产出的重复报告”。5 月 26 日那篇文章是同一个人，六周之后，描述当一个安装量约三百亿台的项目的好报告也突破每天一份时，对一支维护团队意味着什么。

向 Stenberg 公开确认观察到同一趋势的项目非完整列表：Apache httpd、BIND、Django、Elasticsearch Python client、Firefox、git、glibc、GnuTLS、GStreamer、Haproxy、Immich、libssh、libtiff、Linux 内核、OpenLDAP、PowerDNS、Python、Prometheus、Ruby、Sequoia PGP、strongSwan、Temporal、Unbound、urllib3、Vikunja、Wireshark、wolfSSL。

为什么重要

三个层面的转变让这成为一个安全议题，而不是社区管理议题。

第一，瓶颈不再是发现漏洞，而是披露流水线。 Help Net Security 引用 Assetnote 的 Shubham Shah：组织现在审查合法报告所需的时间显著拉长——维系顶尖研究者参与的反馈回路正在退化。如果维护团队的分流速度跟不上 AI 辅助研究的提交速度，无论上游工具多优秀，项目的有效修复时间都会被拉长。同一个能为防御者找到 bug 的模型，也能为攻击者找到同一个 bug；队列越长，窗口越长。

第二，成本由一个规模很小、没有保障的群体在承担。 Stenberg 的文章罕见地坦率：每周 50 小时、“全部七天”，妻子开始要求他放慢节奏。curl 项目不属于任何公司，不附属于任何伞形基金会，人数与五年前大致相同。Apache Log4j PMC 成员 Piotr P. Karwasz 在 1 月那篇博客的评论中 反映了同样的困境。对于支撑全球软件相当大一部分的库来说，这就是一个单点故障。

第三，主导变量已从检测转向治理。 Mozilla 发布的 Mythos 辅助 Firefox 分流公开说明 描述了在 Firefox 150 之前修复的 271 个潜在缺陷，并指出”缺陷是有限的”。即便如此，这条有限的尾巴仍需经过人工审核披露、修复、发布、下游打包以及最终用户更新。这些环节今天还不能以 AI 速度被压缩。

防御建议

这里的防御手册是运营性而非技术性的，对维护开源库、运营漏洞赏金计划，或在规模上消费上游公告的团队都适用。下述建议均不需要前沿级别的模型访问权。

  1. 让提交要求匹配新的现实。 GitHub 在 2026 年 5 月发布的修订版漏洞赏金规则是一份可用模板：必须提供能演示具体安全影响的可工作 PoC，AI 辅助发现需经验证后才能提交，报告应简洁而非被 AI 灌水，明确关闭落入已公开”不合格类别”的报告。Linux 内核关于负责任使用 AI 的指南 是第二个参考。两者篇幅都短，可下放到更小的项目。

  2. 当残渣占主导时，将报告渠道与现金奖励解耦。 curl 在 2026 年 1 月做出的决定——保留披露渠道但取消赏金——是目前可见最干净的自然实验：变更之后，确认漏洞率回到 AI 出现之前的水平。教训不是”废除赏金”——大型厂商依然能受益——而是”赏金激励需要为 AI 时代的提交专门设计”。HackerOne 和 Bugcrowd 都在人工审核之上叠加 AI 辅助分流；在投入人力之前，先问清楚平台过滤了什么、漏检率如何。

  3. 同时重新校准补丁 SLA 与披露 SLA。 如果您对浏览器引擎、内核、普及型库的 CVE 内部目标仍然是”自披露起 30 天”，这个数字是在可信发现速率更低的时代设定的。在披露端——从接收报告到公开 CVE 的时间——瓶颈现在来自维护者的分流容量，而不是研究者的节奏。同时跟踪这两个数字，并向上层作为一条曲线汇报。

  4. 资助你嵌入的库。 Stenberg 在 5 月 26 日文章中唯一明确提出的请求，就是依赖 curl 或 libcurl 的商业软件公司去资助团队。同样的逻辑适用于上面列出的所有项目。一份支持合同或一个赞助岗位的成本，远低于关键库安全流水线熄灯的下行风险。对安全和合规团队而言，这是一项预算条目，不是一项 CSR 条目。

  5. 在防御侧镜像 AI 工作流。 产生这场入站洪水的模式——模型从公开源码中浮现候选 bug 类别——在内部代码上同样可复现，无需 Mythos 级别访问。在你嵌入的库版本中，针对已披露的 CVE 排查你自己代码里未修复的类似物。在官方 PoC 落地之前，从公告文本生成最小可复现。这种不对称只有在防御者也使用同样工具时才向防御者倾斜。

  6. 把维护者流失视作供应链风险。 主要维护者减少投入、离开项目或耗竭，对所有下游来说都是一次供应链事件。把”谁在维护它、以多大容量在维护？“这一问题加入对任何高于既定关键性阈值的库的尽职调查清单。上面那份项目列表是一个合理起点。

  7. 参与 OSSF 工作组。 Open Source Security Foundation 的 Vulnerability Disclosures Working Group 正在征集关于 AI 辅助提交最佳实践的反馈。如果贵组织在规模上提交报告、运营赏金计划或消费上游公告，您的运营数据对这项工作有价值，最终产出的政策模板也可在贵方自有计划中复用。

现状

项引用日期备注
Stenberg, The pressuredaniel.haxx.se2026-05-26>1 报告/天；半周期 12 个 CVE 已确认
Willison 链接博客摘要simonwillison.net2026-05-26同日扩散，security/AI 标签
Stenberg, High-Quality Chaosdaniel.haxx.se2026-04-22确认漏洞率回到 15-16%
Stenberg, End of the curl bug-bountydaniel.haxx.se2026-01-26赏金计划于 2026-01-31 结束
Help Net Security, AI is drowning maintainershelpnetsecurity.com2026-05-18引用 Torvalds、GitHub、HackerOne
GitHub Security 赏金计划更新github.blog2026-05新要求，PoC 强制
OSSF Vulnerability Disclosures WG #178github.com/ossf2026关于反 slop 实践的公开征集

对这件事正确的框架不是”AI 制造了太多 bug”——而是 “整个软件生态所依赖的、由人工审核的披露流水线，是为’发现 bug 比修复 bug 慢’的世界尺寸设计的；这个假设对所有项目都不再成立。” 在维护一切的人正在明确发出信号。基于这个信号采取行动的成本——资金、政策、工具——远小于在某个关键库的安全团队消失之后再行动的成本。

Sources