curl 作者 Daniel Stenberg 从 curl 生态角度出发对 LLM 的影响发表了看法。他表示，AI 自动生成的漏洞报告对 curl 项目的安全工作造成了困扰。具体是指一些用户利用 LLM 生成虚假漏洞报告，这些报告看似专业，但实际上并不存在安全问题，这浪费了 curl 项目开发人员的时间和精力，也增加了安全评估的工作量。

Daniel 的分析是，curl 项目提供漏洞赏金计划，吸引安全研究人员报告安全问题，一些利用 LLM 的用户希望通过快速提交看似合理的报告获利，但实际上并没有发现真正的安全漏洞。而 LLM 技术在这个过程中让他们生成“假”漏洞报告的操作变得更加便捷，并且使得开发人员需要花费更多时间精力去鉴别，同时也使得真正的安全问题容易被忽略。

他具体举了两个案例：

案例一说的是漏洞报告（CVE-2023-38545）仅仅只是预告了还没正式披露，但有人用 Bard 先生成了一份虚假的提前放出。

2023年秋季，我向社区告警了一个即将公开的CVE-2023-38545。我们评估其严重性为高。

就在该问题即将发布的前一天，一位用户在Hackerone上提交了这份报告：Curl CVE-2023-38545漏洞代码更改已在互联网上公开

听起来非常糟糕，如果真的是事实的话，那就会有问题。

然而，这份报告充满了典型的AI风格幻觉：它混合并匹配旧安全问题中的事实和细节，创造并编造出与现实无关的新东西。变化并未在互联网上公开。实际上被披露出来的变化是针对以前、较老、如预期那样处理过的问题。

在这个特定报告中, 用户提醒我们他们使用Bard找到此问题。

案例二说的是疑似有用户使用 LLM 工具上报了一个 curl 缓冲区溢出漏洞，并且表述语法正确、信息详尽，还带有建议修复方案等内容，显得特别专业、真实可信，同时报告人还在漏洞披露平台上有很高的声誉。

这是一个更复杂的问题，不太明显，做得更好但仍然受到幻觉的困扰。展示了当工具被更好地使用和更好地融入通信时，问题如何变得更糟。

2023年12月28日早上，一位用户在Hackerone上提交了这份报告：WebSocket处理中的缓冲区溢出漏洞。那时候是我所在时区的早晨。

再次根据标题来看，这听起来相当糟糕。由于我们的WebSocket代码仍处于实验阶段，并且因此没有被我们的bug赏金计划覆盖，所以当我开始查看这份报告时还能保持轻松态度。它是由我之前从未见过的用户提交的，但他们在Hackerone上有很高声誉 - 这并非他们首次提交安全报告。

该报告整理得相当清楚。它包含详细信息，并用正确英语书写。它也包含了一个建议修复方案。对我而言, 它并没有表现为错误或者差劲，看起来就像这个用户发现了某种坏事，并且似乎足够理解问题以提出解决方案。就安全报告而言，这看起来比一般人的首次报告要好。

在报告中，你可以看到我第一次模板回复，通知用户我们已经收到他们的报告，并且我们将调查此案件。当我发表那篇文章时，我还不知道这个问题会有多复杂或者简单。

十九分钟后，我查看了代码，没有找到任何问题, 再读了一遍代码然后再读了第三遍，报告人说存在缓冲区溢出的地方究竟在哪里？然后我提出了第一个问题，询问这个溢出具体会在哪里以及如何发生。

经过反复提问和无数次迷惑之后, 我意识到这并非真正的问题, 同日下午我就把该议题关闭为不适用，并没有缓冲区溢出。

虽然不能确定用户回应是否由LLM生成但它确实显示出几个迹象。

Daniel 总体观点是，随着 AI 技术的发展，垃圾报告的伪装性越来越高，即使报告内容包含部分事实和细节，也可能存在大量虚构和误导信息，需要更多时间和精力去核实。同时虚假报告不仅浪费时间，还可能导致真正的安全问题被忽略，甚至造成开发人员工作时间的延误。

他表示利用 AI 进行安全研究并非完全是坏事，但必须避免将其用于生成虚假报告。未来可能会出现更先进的 AI 工具，能够真正帮助发现安全漏洞，但前提是使用得当，同时需要人类的监督和核实。