技术深度剖析
这款AI漏洞扫描器的失败，根源在于当前大语言模型的基础架构局限。Claude和Codex，如同所有基于Transformer的模型，通过预测基于从海量代码和文本语料中学习到的模式的下一个最可能token来运作。这使得它们擅长生成语法正确的代码片段和识别常见代码模式，但无法赋予它们对系统级安全进行推理的能力。
考虑漏洞检测的核心任务：真正的安全分析需要理解整个执行上下文——数据如何在应用中流动，存在哪些信任边界，身份验证和授权如何实施，以及攻击者可能的入口点是什么。当LLM面对单个函数或文件时，它无法访问这个更广泛的上下文。它无法追踪用户输入从Web表单经过多层中间件、数据库查询和输出渲染的路径。它无法模拟攻击者探测边缘情况的视角。
该开发者的扫描器采用了两阶段流水线：首先，Codex基于代码库生成候选漏洞模式；其次，Claude评估这些候选模式并生成严重性报告。这种方法之所以失败，是因为它依赖于静态模式匹配。例如，扫描器将一个使用`eval()`的函数标记为“严重远程代码执行风险”。孤立地看，`eval()`确实危险。但在实际应用中，`eval()`的输入是来自配置文件的硬编码常量，而非用户提供的数据。扫描器无法知道这一点，因为它从未分析过调用链。
一个试图解决此问题的相关开源项目是Semgrep（GitHub: semgrep/semgrep，11k+星标）。Semgrep使用支持数据流分析的模式匹配引擎，能够追踪变量如何在代码中传播。然而，即使是Semgrep，在跨文件和跨服务分析方面也面临挑战。另一个项目CodeQL（GitHub: github/codeql，7k+星标）使用声明式查询语言定义安全查询，并对代码结构执行类似数据库的分析。这些工具在特定漏洞类别上优于LLM，因为它们基于代码库的形式化模型运作，而非概率性的文本生成。
| 工具 | 方法 | 跨文件分析 | 误报率（估计） | 上下文理解 |
|---|---|---|---|---|
| Claude/Codex 扫描器 | LLM模式匹配 | 无 | ~70% | 非常低 |
| Semgrep | 模式 + 有限数据流 | 部分 | ~30% | 低 |
| CodeQL | 声明式查询 + 完整数据流 | 完整 | ~15% | 中等 |
| 人类安全工程师 | 专家推理 | 完整 | ~5% | 高 |
数据要点： 表格显示了清晰的层级。仅依赖LLM的方法产生了高得不可接受的误报率（根据此实验和类似公开测试估计约70%），使其无法用于生产环境。即使是像Semgrep和CodeQL这样的专用静态分析工具，虽然更好，但仍落后于人类专家。差距不仅在于准确性，还在于推理类型——LLM无法执行复杂漏洞（如业务逻辑缺陷或竞态条件）所需的深度、多步逻辑推理。
关键参与者与案例研究
该开发者的实验是更广泛趋势的一部分。几家公司曾尝试将AI商业化用于安全领域，结果喜忧参半。Snyk（被Synopsys收购）已将AI集成到其漏洞扫描中，但主要用于优先级排序和修复建议，而非初始发现。GitHub提供由CodeQL驱动的代码扫描，使用确定性分析而非LLM。Palo Alto Networks投资了AI驱动的安全运营中心，但这些中心侧重于日志分析和事件响应，而非代码级漏洞挖掘。
一个值得注意的案例是Microsoft的Security Copilot，于2023年推出。它使用GPT-4通过总结事件和生成查询来协助安全分析师。早期用户反馈表明，虽然它可以加速分类，但它经常产生威胁情报幻觉并错误归因攻击模式。微软通过添加严格护栏并要求对所有输出进行人工验证来回应。
另一个例子是Socket.dev，它使用AI检测开源软件包中的供应链攻击。其方法结合了基于LLM的分析、静态分析和依赖图遍历。他们报告误报率约为20%，这优于纯LLM，但仍需要人工审查。
| 产品 | 核心技术 | 用例 | 报告误报率 | 是否有人工介入？ |
|---|---|---|---|---|
| Snyk AI | 混合（静态 + 机器学习） | 漏洞优先级排序 | ~25% | 是 |
| GitHub 代码扫描 | CodeQL（确定性） | 代码级漏洞检测 | ~15% | 可选 |
| Microsoft Security Copilot | GPT-4 + 护栏 | 安全事件分析与查询 | 未公开（用户报告高幻觉率） | 是（强制） |
| Socket.dev | LLM + 静态分析 + 依赖图 | 供应链攻击检测 | ~20% | 是 |