如何让人工智能发现真正的代码漏洞,而不会产生大量误报
如果你曾经尝试过用"查找漏洞"的提示词让LLM分析源代码,你可能记得结果。模型通常会产生一堵理论观察的墙:这里缺少OWASP清单验证,那里可以再加一层清理,这个变量命名可疑。实际上,90%的此类发现都是噪音,只是浪费开发者的时间。
Cloudflare团队开源了security-audit-skill。这是一组面向编码代理的指令和管道,他们用它来构建内部工具,用于持续审计代码仓库。
常规AI审计的主要问题是什么
大多数静态分析器和简单的神经网络提示词都存在两个问题:它们不验证可利用性,并且会产生上下文幻觉。神经网络看到一个危险函数,但没有注意到输入数据已经被上面三层过滤了。
Cloudflare采取了相反的方法,在严格原则基础上构建了这个技能:
- 仅针对实际可利用的内容生成报告。像"理论上攻击者可以"这样的短语会被立即过滤掉。
- 发现bug的人没有权限验证它。一个独立的代理作为反对者角色运行验证。
- 如果第一层可靠地阻止了攻击向量,那么缺少第二层保护层不算作漏洞。
- 严重性评估基于实际影响,而非形式上的清单匹配。
六阶段管道如何运作
该工具不是使用一个长提示词,而是将工作分解为六个顺序阶段。阶段内部有并行子代理各自执行严格定义的任务。
+-------------------------------------------------------------+
| 1. Recon -> Карта архитектуры и точек входа |
| 2. Hunt -> Параллельные атаки по разным векторам |
| 3. Validate -> Попытка опровергнуть каждую находку |
| 4. Report -> Формирование читаемых отчетов |
| 5. Structured -> Генерация findings.json со схемой |
| 6. Verify -> Сверка фактов со свежими агентами |
+-------------------------------------------------------------+
1. 侦察
代理调查项目、定义信任边界、识别入口点,并绘制整体架构。结果生成的文件 architecture.md 作为攻击代理的地图。
2. 狩猎
多个代理从不同角度并行测试代码库。项目被分割成带有不同攻击类提示的单独文件:
- 注入、访问控制和业务逻辑。
- Web协议细节、缓存和认证(
WEB-PROTOCOL-AND-AUTH.md)。 - 客户端威胁如DOM注入和原型污染(
CLIENT-SIDE.md)。 - 原生代码的内存安全和二进制漏洞(
MEMORY-SAFETY-AND-BINARY.md)。 - LLM系统问题:提示词注入、上下文泄漏和工具调用操纵(
AI-AND-LLM.md)。
每个狩猎代理可以生成额外进程,深入挖掘可疑的调用链。
3. 对抗性验证
这是最有用的阶段。新的代理接收潜在bug列表,并故意尝试证明攻击不会起作用。如果保护措施已到位或向量被相邻模块阻止,发现会被无情地划掉。
4. 报告和结构化输出
生成文件 REPORT.md 和 FINDINGS-DETAIL.md,包含中等级别及以上漏洞的详细追踪,以及 findings.json。结构化JSON由基于Node.js的脚本 validate-findings.cjs 验证,不依赖外部依赖。
5. 独立验证
最终质量控制。拥有干净上下文的代理逐行验证报告中的声明与实际代码,以消除行号或函数名中的幻觉。
安装和运行
该包通过Skills CLI连接到任何支持工具调用和并行子代理的编码代理。
项目安装:
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
全局安装:
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit --global
之后,只需在代理中打开代码库并用纯文本写入:
security audit this codebase
或指定特定目录和报告路径:
do a security review, output to ~/audits/my-project
有趣的细节:运行可以累积。作者在测试中发现,由于遍历路径的随机性,一次运行大约只能发现一半的真实问题。该技能可以读取之前的运行结果 findings.json,跳过已知的bug,并探索未触及的代码分支。
谁适合使用
该工具需要具有并行工具调用支持的有能力的模型,因此在弱本地设置上运行可能不起作用。
但如果你已经在使用代理进行重构或编写测试,在发布或重大合并之前添加一个作为细致安全审计员的角色是个好主意。"攻击者"和"怀疑者"的角色分离方法明显减少了处理误报的手动工作。
相关项目