17611538698
webmaster@21cto.com

cURL 作者深受 AI 虚假报告之苦,将底层缺陷公之于众

开源 0 35 4小时前
daniel:// stenberg://:

21CTO导读:cURL作者和他的开源项目宣布将缺陷和bug完全公之于众。

在众多开源项目中,一部分都开始使用人工智能,但它催生了大量虚假的所谓“安全报告”,这些报告均由其快速生成,令维护和开发人员不堪重负;另一方面,如果运用得当的话,先进的人工智能分析器能够发现 cURL 和其他开源项目中那些以往任何工具都无法发现的深层漏洞。

但是由于第一项,AI生成的大量的虚假漏洞报告让人们苦恼不已,尤其是cURL。

叫停cURL漏洞赏金计划

Stenberg 从一开始就重视发现漏洞,这突出了他和团队的责任心。他这样做的,也是这样说的:“我们会进行多次审计。”

为了有效收集问题和漏洞,他成立了 HackerOne 计划,并和互联网漏洞赏金计划(Internet Bug Bounty Program)合作。

自 2019 年 4 月启动计划的六年来,cURL已经对外支付了超过 85000 美元。后来,他在一个时间段做了一番复盘,在 500 份漏洞报告中大部分是 AI 生成的垃圾报告,有效的仅10-15%左右。这些垃圾指的就是用 LLM 生成的冗长、自信满满,但往往完全捏造的漏洞报告。

他描述了一份关于所谓HTTP/3“流依赖循环漏洞”的报告。如果情况属实,那是一个“极其严重、危及生命的”安全漏洞。报告还附带了GDB(GNU调试器)会话和寄存器转储文件——结果发现其中引用的函数在cURL中根本不存在。这一切全是假的。

经过多年的多次总结,Stenberg 果断叫停了 cURL 的漏洞赏金计划。他和 cURL 安全团队受够了“人工智能垃圾”的困扰。

Stenberg 总结,大量的低质量人工智能报告的出现与cURL的HackerOne漏洞赏金计划密切相关——该计划对严重漏洞提供高达1万美元的赏金,对低危漏洞则提供500美元的赏金。他指出,这种赏金机制鼓励报告者让人工智能工具“查找安全问题”,然后将结果粘贴到报告中,标记为“严重”,并寄希望于获得巨额赏金,而几乎不做任何验证。

斯坦伯格指出到2025年底,“这个虚假比例已经上升到大约每20个或30个漏洞中就有一个,这很准确。” 这使得安全漏洞报告的分类变成了“恐怖报告”,耗尽了项目七人安全团队的时间、精力,甚至“生存意志”。这种人工智能放大的噪音不仅浪费了志愿者的精力,最终还会危及更广泛的软件供应链:如果维护人员因为这些垃圾报告而麻木,代码中真正的漏洞就会被忽略。

通过正式关闭 cURL 漏洞赏金计划,该团队希望“取消奖金”至少能终结这种特定的激励机制。


阻止人类滥用人工智能的行为

Stenberg表示,从 2026年 10 月 26 号起,低危和中危严重性报告将提交到这个开源数据传输工具的公共 GitHub 存储库中。

他这样郑重地向开源社区宣布:

“如果安全研究人员有疑问,仍然可以在 HackerOne 上提交问题,我们会告知他们我们认为问题的严重程度。过去几年中,超过 90% 的提交问题都能很快被评估为低于‘高’级别。”

他用数据和时间完全确定大部分安全研究人员和开发者提交的bug或漏洞都是低危问题。

Stenberg 表示,公开处理可以让更多的人在版本发布前评估报告、开发修复程序、编写建议并检查相关问题。

公开处理漏洞报告并不会减少每个报告的工作量,但可以分散工作量,并使最终的经验教训和文档更容易查找。至少理论上是这样。

公开披露漏洞也给了攻击者更多时间在修复程序发布前利用漏洞。维护者也承认这令人遗憾,但无法避免。

“我们之所以将这种做法限制在低于‘高’的水平,是因为:至少这些问题并不严重。”

Stenberg 表示,利用人工智能的研究人员正在生成不太可能在实际应用中出现的不寻常的选项组合,然后将细微的差异视为漏洞。

“我们不能再这样螺旋式地发展下去,否则我们将失去理智。我们没有足够的资源、人力,甚至意愿来处理如此源源不断的漏洞报告。我相信很少有软件项目能够长期承受这种持续高负荷的报告洪流。必须做出改变。”  

“人工智能只是一种工具”


Stenberg强调“人工智能只是一种工具”,经验丰富的工程师在使用人工智能为开源安全带来了实实在在的好处。

他解释说:“我们现在使用多种人工智能分析工具……它们确实能发现许多其他工具以前从未发现过的问题,而且是以其他工具以前无法发现的方式发现的。”

借助这些工具,他们修复了“100 多个”已出现的漏洞,而这些漏洞是多年来使用激进的编译器标志、模糊测试器、传统静态分析和多次人工安全审计后仍然出现的。

他表示,这是因为这些人工智能工具能够以“近乎神奇”的方式跨协议、规范和第三方库进行推理。例如,根据一份Telnet规范(斯坦伯格说,这份规范“自2012年以来就没人看过”),Telnet实现中使用的某个特定字节是无效的。他还指出,这些工具还可以标记函数注释和实现之间的不一致之处,从而发现一些细微的逻辑错误。

他还使用三个不同的AI代码审查机器人来审查他的代码拉取请求。这些机器人会在凌晨两点运行,那时没有人工审查员在工作,它们能够发现不同类型的问题,并且经常能发现缺失的测试或对外部库行为的错误假设,尽管它们并不能取代测试套件。

尽管这些都不错,但Stenberg对使用人工智能生成生产代码深表怀疑。他表示自己不使用人工智能编码工具,对它“不以为然”,也不认为cURL项目组的任何成员会依赖它们进行严肃的开发工作。他指出,人工智能分析器给出的代码修复建议“永远不够好”,不能盲目接受。他将它们比作有时有用的“热情初级程序员”,其建议必须经过仔细筛选和全面的测试才能验证。

在法律方面他告诉人们,人工智能生成的代码贡献并不会从根本上改变cURL的风险模型。该项目一直以来都必须相信贡献者有权提交他们发送的代码,无论这些代码是“有人自己编写的、复制的、用人工智能生成的,还是五年前从Stack Overflow复制的”。

Stenberg将cURL的遭遇置于更广泛的开源背景下进行分析。很多的开源项目也同样深受AI生成的垃圾代码和内部安全团队发现的大量真实漏洞交汇的困扰。他以FFmpeg与谷歌的纠纷为例,描述了“巨头”如何利用人工智能和庞大的安全部门发现大量真实漏洞,然后向小型志愿者项目施压,要求他们在严格的披露期限内修复这些漏洞,却不提供补丁或资金支持。

结语

展望未来,Stenberg 表示,他预计人工智能将继续“以各种方式增强我们所做的每一件事”。他还敦促各个项目尝试采取措施,防御垃圾举报和人工智能抓取工具。例如,他建议使用经过审核的举报者“秘密俱乐部”或更严格的提交要求,即使这些措施与开源的传统开放性相悖。

归根结底,他传递的信息与其说是关于人工智能本身,不如说是关于人类的选择。那

些用于“恐怖袭击报告”和占用大量网络带宽的人工智能爬虫的工具,同时也显著提升了cURL代码的安全性。至于如何利用这些工具造福人类还是作恶,则取决于维护者、公司和社区的有效判断。

作者:洛逸

评论

我要赞赏作者

请扫描二维码,使用微信支付哦。

分享到微信