Mythos 发现了一个 Curl 漏洞

是的，就像单数形式一样。早在 2026 年 4 月，Anthropic 得出的结论是，他们的新 AI 模型 Mythos 非常善于发现源代码中的安全缺陷，这引起了媒体的广泛关注。显然，Mythos 在这方面非常擅长，以至于 Anthropic 还没有向公众发布这个模型，而是将其暂时分发给选定的几家公司，让一些好的公司（？）先行一步，在普通民众上手之前先解决最紧迫的问题。整个世界似乎都失去了理智。这就是我们所知的世界末日吗？这无疑是一个非常成功的营销噱头。我的（非）访问权限 与 Glasswing 项目达成的部分协议是，Anthropic 还通过 Linux 基金会向“开源项目”提供了对其最新 AI 模型的访问权限。 Linux 基金会让他们的项目 Alpha Omega 处理这部分，他们的代表联系了我。作为curl 的首席开发人员，我获得了访问神奇模型的机会，我欣然接受了这个提议。当然，我想看看它能在curl 中找到什么。我签署了访问合同，但之后什么也没发生。几周过去了，我被告知某个地方出现了问题，访问被延迟。最终，我得到了一个可以访问该模型的其他人可以使用 Mythos 为我运行curl 扫描和分析并向我发送报告的机会。对我来说，区别并不那么重要。无论如何，我并不是有很多时间去探索许多不同的提示并进行深入的冒险。无论是谁做的，使用该工具来生成第一次正确的扫描和分析都会很棒。我很高兴地接受了这个提议。 （我故意省略了参与完成curl分析的个人的身份，因为这不是这篇博文的重点。）curl的人工智能扫描在第一份Mythos报告之前，我们已经使用几种不同的非常强大的人工智能工具扫描了curl（我的意思是除了一直运行一些“正常”静态代码分析器之外，使用最挑剔的编译器选项并对其进行多年的模糊测试等）。主要使用 AISLE、Zeropath 和 OpenAI 的 Codex Security 来通过 AI 审查代码。在最近 8 到 10 个月左右的时间里，这些工具和他们所做的分析已经触发了 2 到 300 个错误修复，这些错误修复合并到了 curl 中。这些 AI 工具报告的大量发现已被证实存在漏洞，并已作为 CVE 发布。大概有十几个或者更多。如今，我们还使用 GitHub 的 Copilot 和 Augment code 等工具来审查 Pull Request，他们的评论和投诉可以帮助我们获得更好的代码并避免合并新的 bug。我的意思是，我们当然仍然会合并错误，但 PR 审查机器人会定期突出显示我们修复的问题：如果没有它们，我们的合并会更糟。除了人类评论之外，还使用人工智能评论。他们帮助我们，但不会取代我们。我们还看到大量高质量的安全报告涌入：安全研究人员现在广泛而有效地使用人工智能。在curl项目中，安全性是我们的首要任务。我们遵循每一条准则，并正确进行软件工程，以减少代码中的缺陷数量。扫描缺陷只是确保这艘船安全的众多步骤之一。在软件安全方面，您需要进行长期而艰苦的搜索才能找到另一个与curl 一样多或比curl 更进一步的软件项目。确保curl安全所涉及的步骤2026年5月6日我们满怀期待地收到了用Mythos生成的第一份源代码分析报告。我们还有另一个机会找到需要改进的地方和需要修复的错误。为了做出更好的卷发。这个初始扫描是在curl的git存储库及其最近某个提交的主分支上进行的。据统计，在 src/ 和 lib/ 子目录中分析了 178K 行代码。该分析详细介绍了执行搜索的几种不同方法和方法，以及它如何集中精力寻找哪些缺陷。报告顶部有一条有趣的注释说：curl 是现有模糊性和审计最多的 C 代码库之一（OSS-Fuzz、Coverity、CodeQL、多次付费审计）。在热路径（HTTP/1、TLS、URL 解析核心）中找到任何内容是不可能的。 ......并且它正确地发现这些区域没有问题。 Mastodon 上关于人们对 Mythos 扫描 curl 的期望的完全不科学的民意调查 当我们排除空白行时，curl 卷曲的大小目前为 176,000 行 C 代码。源代码由66万字组成，比小说《战争与和平》整个英文版多出12%。平均而言，curl 的每个生产源代码行已被编写（然后重写）4.14 次。我们已经对此进行了完善。目前，git master 中仍然保留的现有生产代码是由 573 个不同的个人编写的。随着时间的推移，到目前为止，共有 1,465 人将他们提出的更改合并到了 curl 的 git 存储库中。我们有p