关于 curl 的 AI 生成安全报告

LLM 生成的 Curl 漏洞报告

• 讨论的核心是一份关于 curl 的虚假安全报告；对许多读者来说，这份报告明显是由 LLM 生成或重度辅助生成的。
• 这份报告表面上看起来专业而详细，但它编造了代码、误读了真实代码，并且在被质疑后仍坚持己见。
• 有人认为这是一种新的“脚本小子”行为：运行扫描器或 LLM，粘贴结果，然后索要赏金或履历上的一行内容。

漏洞赏金、CVE 与激励机制

• curl 的漏洞赏金（最高约 1 万美元）以及提交 CVE 的声望，被视为低成本或自动化提交的强大激励。
• 评论者指出，在 LLM 出现之前，就已经长期存在琐碎的 CVE 尝试（例如“grep strcpy”）。
• 人们担心这种趋势会削弱 CVE 系统的公信力，并浪费分诊资源。

对所谓漏洞的技术讨论

• 多条评论解释说，curl 的这段代码是安全的：使用的是固定大小、编译期已知的缓冲区，并且数据是受控的；没有用户输入。
• 讨论围绕 strcpy、strncpy、strlcpy 和 snprintf 展开，以及它们各自适用的场景。
• 有些人承认静态分析器可能会标记这种模式，因为安全性依赖于某个函数契约（Curl_base64_encode），不过 LLM 的解释是错误的。
• 还有关于栈和堆的使用、内存清理模式，以及一些细微设计替代方案的旁支讨论。

LLM 垃圾内容对维护者和生态系统的影响

• 很多人对“几分钱”的 LLM 输出却能消耗专家数小时的时间感到强烈沮丧；有人提到了 Brandolini 定律。
• 这被视为对人类注意力的拒绝服务攻击，对已经时间紧张的开源维护者尤其有害。
• 人们担心维护者会变得更严厉，从而打击真正的新手贡献者。

识别与解读 LLM 生成文本

• 人们指出了一些可识别的模式：公式化结构、过度礼貌、不断道歉、企业化语气。
• 也有人担心，随着模型变得更好，或者被定制成更粗鲁、俚语化的风格，检测会越来越难。
• 反方观点是：一些非母语者确实会正当地使用 LLM 进行语法修正/翻译，所以“LLM 口吻”并不自动意味着内容是假的。

针对 LLM 驱动的漏洞赏金垃圾提交的防御建议

• 提出的建议包括：
  • 仅限申请制，或采用与经过筛选的研究者组成的“池”模型。
  • 设置较小的提交费用或账户押金，对非垃圾报告予以退还。
  • 白名单和信誉系统；在若干次善意提交后免收费用。
  • 使用专业分诊服务过滤垃圾内容（尽管这会转移成本）。

关于 LLM 能力与适当用途的看法

• 许多人把 LLM 描述为流利的“胡说生成器”：文本表面质感正确，但往往缺乏实质内容。
• 与图像模型相比：第一眼很惊艳，但仔细看就会发现瑕疵。
• 一些人认为 LLM 作为辅助工具很有价值（翻译、总结、起草），但当它们被当作独立“思考者”使用时就很危险。
• 更广泛的担忧是，LLM 内容会充斥评测、指南、法律文件和技术论坛，削弱信任并提高参与门槛。
• 少数观点则表达了些许宽慰：鉴于当前 LLM 的局限性，自己的工作岗位似乎还算安全。