近期，Mythos 项目宣布对 1000 个开源项目进行扫描后发现了约 2.3 万个潜在漏洞。该数字一经公布，便点燃了安全社区的多方讨论——争议的核心并非漏洞数量本身，而是这些报告中相当一部分是否真正具有危害性，以及它们对本已超负荷运转的漏洞处理生态造成的额外压力。
正如这位 Slashdot 评论者所指出的：“大量安全报告其实是虚假的，即使它们被分配了 CVE，被‘安全研究者’称为漏洞，其他人也可能忍不住翻白眼。” 在 Mythos 给出的 2.3 万条结果中，有多少是真实可利用的缺陷，又有多少只是代码风格问题或无害异常？社区普遍认为，倘若 LLM 生成的报告也存在类似情况，团队将不得不在“真假漏洞”的筛选上额外耗费大量精力。
漏洞定义的争议
curl 项目曾专门撰写文章回应这类自动发现的“漏洞”。项目维护者强调，一个真正的漏洞必须能够被实际利用。许多被 LLM 标记的问题在本质上只是代码中的轻微瑕疵，可能永远无法在真实场景触发利用。在尚无漏洞利用证明前，它们往往只能被列为低优先级，虽然仍值得修复，但不应与严重安全缺陷混为一谈。
社区中有人调侃道：“他们一直在用‘漏洞（vulnerability）’这个词，我不认为他们清楚这个词的真正含义。” 这一评论反映出对安全词汇滥用现象的普遍不满：传统上要求具备可利用性的安全漏洞定义，正被自动化工具的广泛标注所模糊化。
安全生态的承压现实
即便忽略报告质量争议，单纯漏洞发现速度超过修补能力的局面已经足够令人担忧。当探测工具普及到每个人手中，在线业务就变得处处充满风险。即使信任某个上游公司的安全性，它们的支付依赖链也可能使用了被污染的第三方包。一位评论者悲观地写道：“我们到底要怎么才能把这东西维持住？用更多的胶带呗——互联网几十年来一直都是这么撑过来的。”
修补速度缓慢反映了一个根深蒂固的问题：无论是商业产品还是开源项目，开发团队总是将可见的功能迭代置于安全编码与 bug 修复之前。有评论回忆道：“还记得你在 10 年前向 Firefox 报告的那些漏洞吗？” 暗示安全修复长期不受重视。
与此同时，AI 引发的岗位裁员潮与海量漏洞报告形成讽刺对照：一边裁掉软件工程师，一边又突然需要大量人力来处理自动生成的修补建议。评论者质问：“这难道不是一种错误吗？”
自动扫描的可持续性
也有观点认为，Mythos 目前扫描的主要是长期积累的陈旧代码——此前 LLM 从未大批量分析过这些仓库。一旦开源项目采纳并修补了这些报告，积压问题会迅速归零。届时，这类工具将如何向投资方证明其持续价值？“你还打算靠什么来定期销售你的服务？” 这种质疑暗示自动化漏洞检测可能面临一次性任务与商业模式可持续性之间的困局。
在代码领域有一句经典论断：“每个非平凡的程序都至少存在一个 bug。” 新技术手段让这一事实更加显性化，但过度标记也带来了新的管理难题。对于已经不堪重负的安全维护者来说，他们需要的是真正有意义的发现，而不是又一道需要人工过滤的噪音洪流。
目前，关于 Mythos 项目的技术细节、具体误报率以及开源社区的实际接纳程度尚无更多公开信息。围绕 2.3 万这个数字的讨论，已然折射出整个行业在自动化安全检测领域的机遇与矛盾。
本文参考来源：Slashdot
微信扫描下方的二维码阅读本文
