Cloudflare 开源审计技能，多一个验证者不等于多一份证明
据 Cloudflare 的 security-audit-skill 仓库，这套面向编码 Agent 的审计流程，将发现问题、独立验证和报告整理分为多个阶段，并要求用证据区分确认、待验证与驳回的发现。
作者：韩启明｜OC 政策与安全编辑
据 Cloudflare 的 security-audit-skill 仓库，这套面向编码 Agent 的审计流程，将发现问题、独立验证和报告整理分为多个阶段，并要求用证据区分确认、待验证与驳回的发现。
一句话结论：让第二个 Agent 尝试推翻第一个 Agent 的结论，是有价值的流程改进；但安全结论仍然必须落在可检查的证据上。
AI 审计最令人头疼的输出之一，是一份措辞非常确定、实际却跑不通的漏洞报告。代码片段看起来危险，不代表它能被外部输入触达；某处缺少检查，也可能被上游条件约束。把这些中间环节省掉，报告越像正式文档，越容易让人误信。
Cloudflare 的流程为此安排了不同阶段：先梳理审计范围，再寻找问题，随后由独立上下文中的验证者检查，最后生成结构化结果。验证者不是只负责补充理由，而应主动尝试否定发现。这个设计旨在减少最初假设一路被顺着写下去的情况。
三种状态，不该挤成一张严重性榜单
项目把发现分成确认、需要验证和驳回。确认结果需要完整的源码路径与有边界的观察证据；需要验证的项目应写出究竟缺哪项事实，而不是先标一个严重级别等人相信；已被证伪的线索则应保留为驳回。
这比把所有疑点都当作漏洞更适合后续处理。安全团队看到“缺少哪一步证据”，才能决定继续调查什么；若只有一段笼统的高危描述，常常需要从头还原分析。
独立上下文，不等于独立真理
第二个 Agent 不带着第一轮的全部对话，有助于减少锚定。但如果它们依赖相似的模型能力、看到了同样不完整的源码，仍然可能犯相似错误。多一轮“我同意”，不能替代缺失的调用链或运行证据。
因此，结构化格式只能解决报告是否齐全、是否容易处理，不能自动判断结论是否正确。一个 JSON 字段名叫 confirmed，并不让它天然变成确认事实。接收方仍需要核对证据与结论之间是否真的连通。
验证代码，也需要被限制
审计流程可能涉及测试仓库中的代码，而仓库内容本身不应被当成可信指令。项目要求相关执行处于操作系统强制的隔离环境中，限制网络、环境变量、可写目录和资源等。
这不是一句“请小心运行”能替代的控制。如果缺乏合适隔离，未完成的验证就应保持未完成状态，而不应为了把报告填成确认，直接在带有真实凭据的环境里试跑。审计工具自身不能成为新的泄露通道。
结果要能进入维护工作流
一份有用的审计报告，还应解释问题影响什么、证据在哪、复现有何条件，以及修复后如何确认问题消失。对于待验证项，留下具体阻塞事实比反复生成相似猜测更节省维护者时间。
同样，一次没有发现问题，并不意味着项目没有漏洞。覆盖范围、语言和框架理解、可用时间都影响结果。持续审计的价值在于积累证据和修复经验，而不是给仓库发一张长期有效的安全证书。
关键事实
- 发布：Cloudflare 开源面向编码 Agent 的多阶段安全审计流程。
- 验证思路：使用独立上下文主动检验与反驳初步发现。
- 结果状态：确认、需要验证、驳回应清晰区分。
- 执行边界：测试代码需要受强制隔离约束，不能以模型承诺代替沙箱。
OC 判断
OC 认可把“寻找漏洞”和“证明漏洞”拆开的方向。真正可靠的审计，不是发现越多越好，而是每个结论都知道证据走到了哪里。Agent 可以承担更多排查劳动，但维护者不该被迫用更多时间替它清理自信的误报。
为什么重要
- 对开发者：审计输出应该能复查和修复，而不只是制造警报。
- 对安全团队：待验证项需要明确缺口，确认项需要完整证据链。
- 对工具作者：隔离执行与结果分级是产品能力，不应留给提示词口头保证。
评论
围绕这篇文章补充信息、提出问题或分享观察。