发生了什么

HAProxy 首席软件开发人员、长期 Linux 内核贡献者 Willy Tarreau 在内核安全邮件列表上发布了一个惊人的数据点：过去两年间，AI 生成的漏洞报告使收到的安全披露数量增加了大约 10-25 倍。两 年前该列表每周收到 2-3 条报告，去年约为每周 10 条，到 2026 年初已增至每天 5-10 条。周五和周二似乎是高峰日，可能与研究人员的工作时间表或自动化批处理作业相关 。

西蒙·威利森 (Simon Willison) 引用了这一观察结果，他一直在追踪 LLM 对开源基础设施的下游影响。Tarreau 的记录之所以值得 注意，是因为它来自直接处理这些报告的人——而不是从调查数据中推断的研究人员。

技术深度解析

Tarreau 提出了两个值得分开的不同观点：

报告质量保持稳定

与早期 bug 追踪器中 AI 生成的噪音不同，Tarreau 表示这些报告中大部分在技术上是正确的。这是一个有意义的区别。LLM 辅助的 静态分析和模糊测试工具——如 semgrep、CodeQL 和用于分类的 GPT-4 类模型的组合——显然正在产生可操作的发现，而不仅仅是虚构的 CVE。内核团队 不得不引入额外的维护者专门处理吞吐量，而不是过滤垃圾。

重复报告是一个新问题

第二个新出现的模式：来自使用不同工具的不同研究人员的相同 漏洞的重复报告。这是一个在以前的报告量下不存在的协调失败。当两个研究人员独立地将类似的内核子系统代码馈送到不同的 AI 辅助扫描器时，他们可能通过略微不同的代码路径发现相同的内存安全问题。结果是维护人员需要进行重复的 分类工作，必须在分配 CVE 之前对发现进行去重。

推动这一趋势的工具生态可能包括：

  • LLM 辅助代码审查：GitHub Copilot、GPT -4o 或 Claude 等工具用于手动审计内核子系统中的经典漏洞类别（use-after-free、整数溢出、竞争条件）
  • AI 增强的模糊测试器：将 L LM 与 syzkaller 或 libFuzzer 集成以生成更有针对性的输入语料库的项目
  • 自动化静态分析管道：LLM 生成或优化的 CodeQL 查询或 semgrep 规则用于捕获 Linux 特定模式

Tarreau 没有指 明单一工具——"可能使用略微不同的工具"这一表述表明，报告量来自广泛 的研究人员群体独立利用 AI 辅助，而非来自某个协调项目。

规模背景

Linux 内核在每个合并窗口 接收约 10,000+ 次提交。其安全面——涵盖驱动程序、文件系统、网络栈和内存管理—— 非常庞大。每周有效安全报告增加 5-10 倍是运营负载的重大变化，而非微不足道的小 事。

谁应该关注

使用 AI 工具审计开源代码的安全研究人员应该意识到，重复披露 现在是一个真正的协调问题。在提交内核安全报告之前，检查类似问题是否已最近被披露——即使是非正式的—— 可以减轻维护者的工作量。

高知名度 C/C++ 代码库的开源维护者（不仅仅是内核——OpenSSL、 glibc 或 QEMU 等项目面临类似风险）应预期入站安全报告的结构性增加。假设低容量的分类 管道将会崩溃。

构建 LLM 辅助扫描器的安全工具开发者应考虑去重和 跨研究人员协调功能。在生成报告之前检查公共漏洞数据库和最近的邮件列表存档的工具可以减少噪音。

评估 AI 辅助代码审计工具的企业安全团队可以将内核安全列表作为领先指标：该工具正在大规模产生真实发现 ，这支持在专有代码库内部采用的案例。

本周行动 建议

  • 如果你维护一个 C/C++ 开源项目：审查你的安全报告接收流程。添加去重步骤，并考虑使用公开的披露 追踪器（即使是简单的 GitHub Security Advisory 草案），以便研究人员在提交前检查现有工作。
  • 如果你使用 AI 工具进行漏洞研究：在提交报告之前，对 lore.kernel.org 和 oss-security 邮件列表进行搜索，以检查最近的重复发现。
  • 如果你正在评估 AI 安全工具 ：Tarreau 的数据点对内部 ROI 论证很有用。有效的内核 CVE 是最难发现的；如果 AI 工具每天能发现 5-10 个，那么在复杂度较低的代码库上的信号噪声比可能更高。
  • 如果你正在构建 AI 辅助扫描器：在向用户展示发现之前，添加使用基于嵌入的相似性搜索对 NVD 和相关项目邮件列表存档进行提交前检查。

更广泛的含义是结构 性的：AI 辅助正在压缩在成熟、经过严格审计的代码库中发现有效漏洞所需的时间和专业知识。 Linux 内核安全列表是开源中最严格的列表之一。它正被大量正确的报告淹没这一事实表明，相同的动态正在 数百个人手不足的项目中悄然上演。