开源项目 Curl 创始人：AI 正在搞砸捉 Bug 工作，浪费开发人员的时间和精力

AI 开启了应用的新时代，我们日常可以用它来协助写作、编写代码、撰写文案、生成海报...而它究竟对一线工作者能提效多少，近日，Curl 创始人兼首席开发者 Daniel Stenberg 结合自己的经历，带来了最新的使用感受。

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

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

作者 | Daniel Stenberg      编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

以下为译文：

我一直没有写过任何有关 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 生成的垃圾报告。

推荐阅读：