SQLite 关键 CVE，还是 LLM 垃圾输出？
最近几起“关键”的 SQLite 漏洞后来被证明是伪造的，很可能由大型语言模型生成，但仍然通过官方 CVE 流和企业扫描器传播开来。评论者认为，这暴露出现有漏洞生态系统已经变得多么超载且噪声巨大，尤其是对于那些受合规、保险或内部政策约束、必须不加上下文地修补每个 CVE 的组织。虽然很多人认为 LLM 是发现真实漏洞的强大工具，但他们警告说，AI 生成的垃圾内容正在抬高分流成本、削弱对 CVE 数据的信任，并带来添加更强验证步骤的压力——而这甚至可能再次借助 AI 来完成防御侧工作。
对组织和安全工作流的影响
- 许多评论者表示，由 SOC2、ISO27001、HIPAA、保险条款、政府项目等驱动的“修补所有 CVE”政策本来就几乎不可行；虚假或低质量的 CVE 让情况更糟。
- 安全团队报告称，他们大部分时间都在否定那些不可利用或无关的发现（例如：无头服务器上的蓝牙漏洞、Linux 栈中的仅 Windows 相关问题）。
- 审计员、保险公司和内部政策通常让“打补丁或升级”比争辩某个漏洞无关更容易，即使它明显不可触达。
- 一些组织通过例外/基于风险的 SLA 来缓解，但批准例外往往很痛苦，而且在政治上也很棘手。
CVE 生态系统的问题
- CVSS 基础分被认为并不能很好地代表真实风险；环境/上下文评分既困难又耗时。
- 许多 CVE 针对的是晦涩或未使用的组件（例如，随库捆绑的工具），却仍然会迫使全球范围升级。
- 链式利用和纵深防御使“不可利用”的说法更复杂：小漏洞在组合起来时也可能变得严重。
- NIST/NVD 不堪重负；CVE 分配大多只是文书工作，并信任提交者，不要求系统性的 PoC。
- 大型项目成为 CNA 后试图重新夺回控制权，但现在又被 AI 生成的报告淹没；一些漏洞悬赏项目由于垃圾内容过多而取消了奖励。
LLM 在漏洞发现中的作用
- 讨论串普遍同意，LLM 现在确实能找到真实漏洞，尤其是在老旧的 C/C++ 代码中；维护者报告称真实问题数量正在上升。
- 但与此同时，LLM 也会幻觉出代码、版本和利用方式，导致虚假的 CVE 和大量徒劳的分流/筛查工作。
- 有人担心攻击者会把扫描型 LLM 与编写利用代码的 LLM 以及大规模算力结合起来，自动化深度、横向渗透。
- 预计下一步会出现能自动复现 PoC 并在人工看到报告前筛掉垃圾内容的 agent，但成本和可靠性仍未确定。
关于 LLM 能力与可信度的争论
- 一派强调 LLM 是随机的下一个 token 预测器，在安全关键工作流中必须由人严格验证，警告不要过度信任它们。
- 另一派则认为，尽管它们是概率性的，但已经表现出非平凡的问题求解与代码分析能力，应被视为强大但会犯错的工具。
- 更广泛的哲学争论则围绕：大脑是否“只是”概率机器，以及这对机器智能意味着什么。
建议的缓解措施与治理
- 建议包括：对高严重度 CVE 要求可工作的利用代码；更细粒度、感知使用场景的漏洞扫描器；自动化 PoC 运行器；为 NIST 提供更好的资金支持；以及在关键领域对滥用 AI 可能引入职业执照或更强的问责机制。