AI 编程助手参与安全审计并不罕见，但真正的难点在于：模型发现的“疑似漏洞”，如何变成安全团队愿意接手复核的可靠结论。Cloudflare 开源的 security-audit 项目，给出的答案不是继续提升模型能力，而是引入一套严格的流程控制。该项目目前采用 MIT 许可证，GitHub 星标为 13,825，定位是一个面向 coding agent 的技能模块，用于执行多阶段安全审计，并输出可机器读取、可独立校验的发现结果。
按照官方说明，security-audit 并非简单的提示词模板，而是一个编排系统。它把侦察、狩猎、验证、复核等任务拆分给相互隔离的子 Agent 执行，每一步都生成结构化记录，并由独立校验器检查。Cloudflare 官方博客中提到，这套项目也是其漏洞发现 harness 的单仓库起点，后续演化为覆盖更广的漏洞发现平台。
六阶段流程：从只读侦察到独立复核
security-audit 的工作方式接近一条审计流水线。用户在 coding agent 中指向目标代码库后，输入如 “security audit this codebase” 或 “find security vulnerabilities in ./src” 等指令，即可触发该技能。当请求匹配 security audit、find vulnerabilities、pen-test 等触发词时，系统自动激活。
第一阶段是侦察。多个 research Agent 并行运行，返回带 file:line 引用的结构化源码事实，并生成 architecture.md 与 coverage-ledger.json。这一阶段保持只读，不接触外部服务。
第二阶段进入漏洞狩猎。系统根据覆盖率账本，将“覆盖率单元”分配给隔离的 general Agent。每个 hunter 只读取自己负责的源码块，只写入自己的 scratch/ 目录，并返回结构化结果。与此同时，coverage critic 会检查哪些单元被遗漏，哪些分配出现重叠。
第三阶段是对抗性验证。每个去重后的候选问题，都会交给一个全新的、没有参与过该问题狩猎的 verifier。验证器的任务不是补证，而是尝试证伪。其提示词明确要求：你没有写出这个候选，请尝试从源码和有限本地证据中反驳它。
第四阶段和第五阶段继续强化独立性。系统会生成 confirmed、needs_validation、rejected 三类裁决，并写入 findings.json，再由 validate-findings.cjs 校验。随后，全新的 Agent 会复核最终源码声明；如果发生实质性替换，替换后的内容还会交给另一个独立 verifier。
第六阶段是报告生成。系统基于已验证记录和覆盖率账本，输出 REPORT.md、FINDINGS-DETAIL.md 和 NEEDS-VALIDATION.md。
关键设计：裁决表示证据完整度，而不是风险高低
security-audit 最值得关注的地方，在于它对“结果可信度”的拆分方式。项目中的 verdict 并不直接等同于高、中、低风险，而是描述证据链完整程度：confirmed、needs_validation、rejected 三个状态，分别对应已确认、仍需验证和已被否定。
这意味着，一个有源码证据支撑的疑点，不会自动被视为确认漏洞。当某个线索因沙箱限制无法执行验证时，它会保持 needs_validation，而不是被草率标成 confirmed，也不会被直接丢弃。
项目还强调一条原则：检查某个发现的 Agent，不能是最初发现它的 Agent。这样做的目的，是避免模型在“自己发现问题、自己验证问题”的过程中产生确认偏差。
在严重度判断上，security-audit 采用“可能性 × 影响”的方式，而不是看问题偏离检查清单的程度。一个符合清单项但缺乏实际影响的问题，不会被认定为漏洞；如果某一层防护已经阻断攻击路径，另一层防护缺失只会被视为加固建议。
另一个重要文件是 coverage-ledger.json。普通安全审计往往是一次性的，跑完一轮后，下一次审计几乎从零开始。security-audit 通过覆盖率账本记录哪些单元已覆盖、哪些已确认、哪些仍存疑，使审计结果可以增量累积。
在同一仓库的后续运行中，系统会读取上一轮的账本和 findings，只针对未覆盖缺口和发生变更的源码重新狩猎；对当前源码仍有证据支撑的旧发现予以保留，而不会把过时或未解决的旧问题误标为已覆盖。每个单元都有明确状态，包括 planned、in_progress、completed 和 deferred。如果某个单元因 Agent 数量限制无法分配，会被显式标记为 deferred，而不是静默消失。
Cloudflare 的实测结果也解释了这种设计的必要性：单轮运行找到的漏洞，大约只有多轮运行累计找到的一半。
沙箱边界明确：无法安全验证时宁可保留待验证
在执行层面，security-audit 对运行目标代码设置了严格前提。项目明确要求，执行目标控制的代码必须在操作系统强制的沙箱中进行。沙箱需要具备阻止网络外联、阻止访问凭据与敏感文件、阻止持久化写入、阻止提权或进程逃逸等能力。
如果这些控制不可用，工作流不会执行目标代码，相关线索会保持 needs_validation 状态。这个选择并不追求“自动跑 PoC”的演示效果，而是把验证边界说得足够清楚：在缺乏安全隔离的情况下，不运行可能恶意的代码。
在数据格式上，findings.json 遵循 report-schema.json 定义的 schema，并配合零依赖校验器使用。父 Agent 在创建账本后、每次更新账本后，都会运行 validate-coverage-ledger.cjs；在第四阶段以及每次第五阶段替换后，则运行 validate-findings.cjs。这种“机器可读 + 独立校验”的组合，使审计结果更容易接入下游工具链，而不是停留在一份仅供人工阅读的报告里。
对 AI 安全审计的启示
security-audit 展示出的判断是：AI 安全审计的瓶颈，不只是模型能否发现漏洞，更是发现结果能否被信任。
- 对抗性验证是可信度的核心。很多 AI 审计工具的问题在于发现与验证由同一模型完成，容易形成自我确认。security-audit 用“检查者不是发现者”的流程约束降低这种偏差。
- 裁决语义与风险等级分离。confirmed、needs_validation、rejected 表示证据链走到了哪一步，而严重度则在 confirmed 内部单独描述。这种分层更适合机器处理，也更容易被安全团队审阅。
- 覆盖率账本让审计从一次性任务变成可累积过程。每次运行都建立在既有覆盖基础上，只补缺口、重验变更，更接近持续安全，而不是周期性审计。
对于已经在使用 coding agent 处理安全工作的团队，或者想研究如何让 AI 输出更可信的安全结论，security-audit 提供了一个相对完整的开源样本。项目地址为 https://github.com/cloudflare/security-audit-skill，可通过 Skills CLI 安装：
npx skills add https://github.com/cloudflare/security-audit-skill –skill security-audit
如需用户级安装，可加上 –global 参数：
npx skills add https://github.com/cloudflare/security-audit-skill –skill security-audit –global
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/cloudflare-kai-yuan-securityaudit-ba-bian-cheng-agent-gai
