curl 现在平均每天收到超过一份安全报告。

这个数字单看不吓人。放到 curl 这种基础软件项目里，就不一样了。Daniel Stenberg 在 5 月 26 日发文说，curl 安全团队收到报告的速度，已经是 2024 年的 4-5 倍，约为 2025 年的两倍。

更反常的是，这些并不主要是低质 AI 垃圾。Stenberg 的判断相反：报告质量比以往更高，通常非常详细，篇幅也很长。它们可信、具体，所以不能随手关掉。

我更在意的是这条变化：AI 把安全报告的入口效率提上去了，但维护端的验证、沟通和修复成本没有自动扩容。压力没有消失，只是转移到了开源项目的安全团队桌面上。

工单变多，也变得更难丢掉

这件事最容易被误读成“curl 漏洞突然变多，所以 curl 变差了”。目前看，不是这个意思。

Stenberg 提到的重点是报告流入速度和处理压力。近几年 curl 被确认的漏洞，严重性大多是 LOW 或 MEDIUM。最近一次 HIGH 级别 curl CVE，是 2023 年 10 月发布的 CVE-2023-38545。

也就是说，受影响的首先是 curl 项目及其安全团队，不是普通用户马上面对一轮高危漏洞爆发。

维度当前变化这意味着什么
报告速度较 2024 年高 4-5 倍，约为 2025 年两倍安全响应从阶段性任务变成日常高优先级任务
报告频率平均每天超过一份维护者很难靠“抽空处理”消化
报告质量更详细、更长、更可信不能简单当噪音丢弃，必须认真判断
漏洞严重性近年多为 LOW 或 MEDIUM不是高危集中爆发，但也不能等同于没有风险

这里的关键矛盾是：低严重性不等于低成本。

一份 LOW 或 MEDIUM 报告，仍然可能需要复现、确认影响范围、判断是否涉及 libcurl API、准备补丁、协调披露，再写清 CVE 说明。报告越详细，维护者越不能只用一句“无法复现”结束。

AI 在前端帮研究者写得更完整。后端仍然要人来判断真假、轻重和边界。

压力不在一次高危，而在每天都要响应

安全报告和普通 issue 不一样。可信安全报告天然会抢占注意力。

对 curl 这种基础组件来说，这种抢占更明显。curl 被大量系统、开发工具、云服务和嵌入式场景间接使用。哪怕漏洞等级不高，也不能轻率处理。

Stenberg 在文中写到，这是 curl 项目和安全团队从未经历过的压力。他还提到，妻子第一次表达了对他工作时长和工作生活失衡的担忧。

这句话很重。

它说明开源安全的成本并不只体现在项目看板上。很多时候，它会变成维护者个人的夜晚、周末和家庭压力。项目可以选择忽略报告，但维护者的责任感、良心和职业自豪感，往往让他们很难这么做。

这也是 AI 安全工具带来的现实约束。工具提高了发现和撰写报告的效率，却没有自动提供对应的维护预算、值班体系和审查人手。

入口变宽了，出口还是那几个人。

维护者和安全团队该怎么改动作

对开源维护者来说，这不是一句“多招人”就能解决的事。很多项目没有稳定资金，也没有专职安全响应团队。更现实的动作，是先把入口规则写硬。

例如，要求报告提交方提供最小复现样例、影响版本、触发条件和预期风险说明。缺少关键材料的报告，可以进入较低优先级队列。否则维护者会被长文档牵着走，时间花在补齐别人没做完的工作上。

对安全研究和工程团队来说，AI 辅助报告也该有新的交付标准。

如果团队用 AI 找到了疑似漏洞，只提交一篇很长的分析，不算完整交付。更有价值的做法，是同时给出可复现路径、最小测试用例、误报排除过程，以及对实际影响的克制判断。

这会直接影响工作流：

  • 开源维护者需要更早建立安全报告模板和分流规则，而不是等报告堆起来再人工筛；
  • 企业安全团队如果依赖 curl，应考虑投入测试、补丁审查或维护协作，而不是只等上游发布结论；
  • 研究团队使用 AI 提交报告时，要把“发现问题”推进到“帮助对方确认问题”。

这不是给报告提交方泼冷水。高质量安全研究当然有价值。

但高质量不等于低负担。一个很长、很可信、很复杂的报告，可能比一个低质误报更耗维护者精力。因为它不能被轻易忽略。

目前还看不清的是，这波 AI 辅助报告增长会不会稳定下来，也看不清 curl 这类关键开源项目能否获得匹配的人力和资金支持。

能确认的是，安全研究的生产率已经被 AI 往前推了一步。维护端如果还按旧账本结算，最先被压垮的，往往是最认真处理问题的人。