AI News HubLIVE
站内改写3 分钟阅读

GitHub将对部分漏洞赏金猎人改用礼品而非现金支付

漏洞赏金计划长期以来是网络安全的核心机制之一,但AI辅助提交的报告泛滥迫使GitHub收紧标准:要求提供可工作的概念验证,低严重性发现可能仅获得公司礼品。此举反映了业界对AI生成低质量报告的普遍担忧。

来源The New Stack AI作者: Paul Sawers

几十年来,漏洞赏金计划一直是网络安全领域的关键减压阀,为独立研究人员提供了一条结构化的途径,让他们能够在攻击者利用漏洞之前披露漏洞。然而,随着AI辅助报告的大量涌入,这一体系的部分环节正在发生剧变。

GitHub上周宣布,由于安全研究中AI工具的使用日益增多,提交数量急剧上升,公司将收紧其漏洞赏金计划的标准。

在博客文章中,GitHub漏洞赏金计划的高级产品安全工程师Jarom Brown表示,公司发现越来越多提交缺乏概念验证、影响演示或明确证据表明可被利用的安全边界已被突破。他写道:“整个行业的项目都在应对同样的挑战,有些已经完全关闭。”

AI垃圾报告泛滥

GitHub强调,它并不反对研究人员使用AI。事实上,该公司预计AI将日益成为现代安全研究工作流程的核心。问题在于,AI辅助生成的推测性或验证不充分的报告数量不断增长。

“工具并不重要。重要的是工作的质量。”Brown继续说道。

这一消息发布前一周,Anthropic推出了其首个公开的HackerOne漏洞赏金计划,在此之前,该公司依赖更严格控制的内部安全测试。而仅仅几周前,Anthropic还发布了Claude Mythos和Project Glasswing,这是一个受限制访问的网络安全计划,围绕一个更先进的前沿模型展开,该公司声称该模型能够比当前公开系统更有效地识别和链接软件漏洞。

Anthropic将Mythos定位为更广泛努力的一部分,旨在更强大的进攻性AI工具普及之前加强防御性网络安全能力。然而,该公司同时向传统的人工主导漏洞赏金计划扩展,也凸显了AI安全行业内部日益紧张的关系:即使企业推销功能强大的自主网络系统,他们仍然明显依赖人类研究人员来识别、验证和重现真实世界的漏洞。

现在需要概念验证

根据更新后的标准,GitHub表示研究人员现在将面临更严格的要求,包括可工作的概念验证演示、安全影响证明、对扫描器或AI生成结果的验证,以及遵守GitHub公布的不可接受漏洞列表。

那些识别低风险加固机会或文档空白的报告可能不再符合现金奖励条件。相反,GitHub表示,一些仍会导致修复的低严重性发现将获得公司礼品而非赏金。

该公司还敦促研究人员缩短提交内容并使其更易于验证,认为过于冗长的报告使安全团队更难识别真正可利用的发现。而问题的一部分再次归因于AI。

“你的报告越清晰、越直接,我们就能越快地处理它。”Brown写道:“冗长的报告,例如多页理论叙述、重复的背景信息或AI生成的填充内容,会拖累分类速度,因为实际的发现被埋没了。”

cURL的早期警告

GitHub的评论是在开放源代码安全社区对所谓“AI垃圾”漏洞报告日益不满之后发表的。今年1月,开源数据传输工具cURL的创始人和首席开发者Daniel Stenberg表示,该项目将关闭其漏洞赏金计划,因为维护者被低质量的AI辅助提交所淹没。

“我们实际上是在遭受分布式拒绝服务攻击,”Stenberg当时写道。“如果可以,我们会向他们收取浪费我们时间的费用。我们仍然没有看到任何通过AI帮助完成的有效的安全报告。”

Stenberg后来澄清说,他并不反对AI辅助安全研究本身,指出了研究人员成功利用AI工具发现合法漏洞和代码问题的例子。他的批评针对的是为了追求漏洞赏金而生成的验证不充分的提交。

这与GitHub的立场一致。该公司强调,AI辅助的发现仍然受欢迎——前提是研究人员在提交前进行适当验证。

“人类研究人员对提交的准确性负责。”Brown写道。

GitHub划定的界限

GitHub的博文花大量篇幅讨论了围绕平台安全边界的误解,特别是涉及AI工具、恶意存储库和提示注入攻击。

该公司认为,许多涉及有害AI输出或恶意存储库的报告通常属于所谓的“共享责任模型”。GitHub表示,用户仍然负责决定他们信任或执行哪些存储库、脚本、工作流和AI生成的输出。

“当一次‘攻击’要求受害者主动寻找并参与攻击者控制的内容时,”Brown写道,“安全边界在于用户决定信任该内容。”

GitHub列举了几个通常不被视为符合赏金条件漏洞的例子,包括涉及故意输入AI系统的提示注入攻击、克隆存储库内的恶意Git钩子,以及AI工具处理不可信输入后产生危险输出。

共享责任示例

这一区别之所以重要,是因为随着AI编码代理变得更加自主并更深入地集成到软件开发环境中,提示注入和恶意AI生成代码已成为核心关注点。

对于GitHub来说,界限似乎在于攻击者是否绕过了实际由GitHub控制的安全边界——或者仅仅是说服用户信任了恶意内容。