原文地址：https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/

声明：本文为 CSDN 翻译，未经许可禁止转载。

以下为译文：

我一贯没有写过任何有关 AI 或者如何（不）利用 AI 进行开拓的文章。
时下，我想立足于 curl 项目，向大家展示一下 AI 对它最显著的影响。

漏洞悬赏

所谓漏洞赏金，详细是指我们向报告安全问题的黑客供应真金白银的褒奖。
这样一个可以赢利的机会也吸引了很多「想要尝尝看」的人。

这些人基本上只是在源代码利用搜索模式，或者充其量只运行一些基本的安全扫描工具，然后报告他们所创造的东西，而不进行进一步的剖析，由此希望能得到几美元的褒奖。

对付 curl 项目而言，其开展的赏金活动已经实施了几年，垃圾报告的比例从未成为大问题。
此外，垃圾报告常日也很随意马虎和快速被检测出来并丢弃。
这些很少能导致真正的问题，或者摧残浪费蹂躏我们太多韶光。
它有点类似最屈曲的垃圾邮件。

我们的漏洞悬赏到目前为止已经支付了超过 70,000 美元的褒奖。
我们累计收到 415 份漏洞报告。
个中，64 份终极被确认为安全问题；77 份报告是信息类的，包含一些缺点或类似的问题。
这样算下来，有 66% 的报告既不属于安全问题也不是正常的 Bug。

越糟糕的废话越糟

当这些报告看起来像是故意义、也被包装得很好时，我们须要花更长的韶光去一步一步研究，终极创造它实在没有什么意义。
每份安全报告都必须有人花韶光查看并评估其含义。

“废话”越多，我们在关闭报告之前花费的韶光和精力就越多。
一份垃圾报告对项目毫无帮助。
相反，它会占用开拓者的韶光和精力，导致这种情形的部分缘故原由是由于安全事情被认为是最主要的领域之一，因此它每每险些赛过其他统统。

如果报告被证明是垃圾邮件的话，我们既没有提高安全性，也摧残浪费蹂躏了韶光来修复缺点或开拓新功能，更不用说仅是审查与处理垃圾报告会耗尽开拓者的精力。

AI 天生的安全报告

作为一种通用工具，AI 有利也有弊。
我相信 AI 终极可以被演习并用于以有效的办法创造和报告安全问题，但迄今为止，我们尚未找到良好的例子。

目前，不少用户彷佛热衷于利用当前的大模型，向它们抛出一些 curl 代码，然后将输出作为安全漏洞报告提交。
当然，让人难以检测的缘故原由之一是用户复制粘贴时也会包含他们自己的措辞。
全体报告不完备是 AI 说的话，但有时候很多是废话。

检测 AI 垃圾

报告者常日并非完备精通英语，有时很难立即理解他们的确切意图，可能须要一些来回的互换，直到把事情讲清楚——当然这是完备可以接管的。
措辞和文化障碍是真实存在的。

有时报告者利用 AI 或其他工具来帮助他们表达自己或翻译他们想要说的话。
作为在外语中更好地沟通的赞助手段，我对此无可非议，由于 AI 可以帮助纵然不精通英语的报告者也可以找到并报告安全问题。

因此，仅仅由于文本的某些部分具有 AI 或类似工具天生的迹象，也无法直接将报告内容定义为垃圾邮件。
它仍旧可能包含真实情形，并且大概是一个有效的问题。
这正是为什么验证报告内容以及确认它是一份垃圾邮件须要很永劫光的缘故原由之一。

证据 A：代码变动已被表露

在 2023 年秋季，我关照社区有一个即将表露的 CVE-2023-38545 漏洞（https://curl.se/docs/CVE-2023-38545.html），我们评定了其漏洞程度为高。

就在那个问题即将发布的前一天，有用户在 Hackerone 上提交了这份报告：Curl CVE-2023-38545 漏洞代码变动已被表露在互联网上。

这听起来相称糟糕，如果确实是真的，势必是一个大问题。

然而，细细看一下，这份报告散发出范例的 AI 风格的错觉：它稠浊和匹配了旧安全问题的事实和细节，创造并编造了一些与现实无关的新东西。
这些变动并没有在互联网上被表露。
实际上被表露的变动是针对之前的旧问题的。

在这份特定的报告中，用户友好地见告我们，他们利用了 Bard 来创造这个问题。
Bard 是 Google 的天生式人工智能。
这让我们更随意马虎意识到这个荒谬的报告，于是我们关闭了报告。

证据 B：缓冲区溢出漏洞

这是一个更为繁芜的问题，看起来不那么明显，包装得很好，但仍旧受到错觉的困扰。
这个案例展示了当工具被更好地利用并整合到沟通中时，问题会变得更糟。

在2023年12月28日的清晨，有用户在 Hackerone 上提交了一份报告（https://hackerone.com/reports/2298307）：WebSocket 处理中的缓冲区溢出漏洞。
当我创造这份报告时，在我的时区，是在早上。

同样，仅仅根据标题，这听起来就很糟糕和严重。
由于我们的 WebSocket 代码目前仍处于实验性阶段，因此它的 Bug 也不在我们的悬赏操持中，以是当有人报告 Bug 时，我们会认为这是真实的。

紧接着，我们开始查看这份报告，创造这是一个我以前从未见过的用户提交的，但他们在 Hackerone 上的“声誉”还算不错，而且这不是他们的第一个安全报告。

报告归档得很整洁，个中包含了详细信息，并用精确的英语书写，以及他还附上了一个修复方法。
对我来说，这份报告看起来没有什么错或者不好的地方，并且该用户对问题有着足够的理解还提出理解决方案。

基于此。
我大略查看之后进行了回答，关照用户他们的报告已收到，我们将调查此案。
当我发布这个回答时，我还不知道这个问题有多繁芜或随意马虎。

十九分钟后，我查看了代码，没有找到任何问题，于是再次阅读了代码，然后又读了第三遍。
这个报告者所说的缓冲区溢出到底在哪里？然后，我讯问，哀求对方澄清这种溢出将在何处以及如何发生。

在反复的问题和无数次错觉之后，我意识到这不是一个真正的问题，同一天下午我将问题关闭为不适用——没有缓冲区溢出。

我不能确定这组用户回答是否由 LLM 天生，但有几个迹象表明了它彷佛是 AI 天生的。

未来

随着韶光的推移，这类报告会变得越来越普遍，当然我们也须要不断地学会筛查及判别由 AI 天生的报告，并过滤个中没有用的报告。

我也确信未来将会涌现利用 AI 来实现这一目的的工具，它们至少在某些时候会发挥一定浸染，因此我不能也不会说，利用 AI 创造安全问题一定总是个坏主张。

然而，我认为，如果你只是添加一个如此眇小的人工检讨，任何此类工具的利用和结果都会变得更好。

我也绝不疑惑未来会有许多人想要通过捷径，去赚取一些奖金。
就像垃圾邮件发送者一样，这种本钱终极落在吸收方身上。
利用强大的 LLM，实在太诱人了。
恰是以，我也非常担心会收到越来越多由 LLM 天生的垃圾报告。