Cloudflare 开源 security-audit-skill：把 Coding Agent 改造成六阶段对抗式审计流水线

一、导读

Cloudflare 把内部漏洞发现流水线（VDH）的"种子"开源了。cloudflare/security-audit-skill 不是扫描器，而是一份可执行的多智能体审计方法论：确定性编排、隔离猎人、对抗验证、机器可读契约、跨轮次覆盖台账。它最反直觉的工程结论是——单次运行大约只能覆盖多次累计发现的一半漏洞，覆盖靠流程而不是单模型推理。代价同样清晰：不自带模型与沙箱，对依赖库 CVE 与领域正确性缺陷几乎无覆盖（社区盲测为 0%）。本文依据抓取日为 2026-09-18 的仓库源码、Cloudflare 官方博客与社区 issue/PR 写成。

二、项目速览

项目	详情
仓库	cloudflare/security-audit-skill
团队	Cloudflare 安全研究团队（贡献者列表首位 literally-dan）
主语言	JavaScript（约 250 KB 的 Markdown 方法论 + 零依赖 Node 校验器）
Star 总数	10,418（GitHub API 2026-09-18；Trending 页同日显示 10,413）
当日涨星	+3,606（GitHub Trending daily 2026-09-18 抓取，当日第一）
License	MIT
首次发布	2026-06-18 初始提交；截至 2026-09-18 无 Release、无 Tag
近期状态	14 次提交，最近推送 2026-09-14；开放 issue 30、开放 PR 19
定位	把通用编码智能体改造成可复现、可审计的安全审计员

三、为什么是它

这是一次官方博客配套开源。《Build your own vulnerability harness》写明："随这篇博客一起，我们发布当初用来开发这套 harness 的初始 skill。"博客给出的相位表与生产 harness 阶段几乎一一对应，等于官方附赠了一份架构说明书。

它填的是一块真实空缺。Cloudflare 先否定了"把通用编码智能体直接指向仓库"的路线，理由有两条：一是上下文形状不匹配，编码智能体一次只持一个假设，在十万行级仓库上"有效覆盖可能只有千分之一左右"，随后上下文填满、压缩触发、早期发现被丢弃；二是吞吐形状不匹配，真实审计需要成百上千个窄假设并行推进。于是审计从一次会话变成一条流水线，而本仓库就是那条流水线被塞回一个目录的形态：每个阶段一份 Markdown 契约，阶段间状态落在 7 个共享文件，发现是否合法由一张 JSON Schema 定义，再由零依赖 Node 脚本机械校验。Semgrep 2026 年的开源评测把这类工具归入"LLM 技能增强"类别，与 Trail of Bits skills、Capital One vulnhunter、Google mantis 并列。它能压过同日榜单上的 alibaba/open-code-review（+3,290）等项目，靠的是同时占住多智能体编排与安全落地两个最热叙事，且安装成本近乎为零：一条 npx skills add，沿用宿主的模型与订阅。

四、架构原理

4.1 整体架构与数据流

架构可概括为"一个父智能体 + 三类受限子智能体 + 一份共享状态 + 两层校验"。父智能体（parent）是唯一的共享状态写者；子智能体分 research（只读侦察）与 general（猎人、验证者、覆盖批评者，可做有界本地执行）；报告渲染不需要模型，是纯脚本。

        ┌──────────── parent（唯一共享状态写者）────────────┐
        │ 预算闸门 → run-metadata.json → coverage-ledger   │
        └──┬─────────────┬─────────────┬─────────────┬────┘
 Phase1 侦察     Phase2 狩猎     Phase3 验证    Phase4 结构化   Phase5-6 复核/报告
 ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌────────────────┐
 │ 1a 产品栈 │   │ hunter-1 │   │verifier-1│   │ findings │   │ 新鲜 agent 逐条 │
 │ 1b 权限   │──▶│ hunter-2 │──▶│verifier-2│──▶│  .json   │──▶│ 复核来源断言；  │
 │ 1c 入口   │   │  ...     │   │  ...     │   │ 覆盖率校验│   │ 实质替换再复核  │
 │ 1d 可执行 │   └────┬─────┘   └──────────┘   └──────────┘   └────────┬───────┘
 └────┬─────┘        │ coverage-critic（找空单元）                      │
      ▼              └────────────────────────────────────────────────┬─┘
 architecture.md ──逐字注入每份猎人提示词──▶                        ▼
                        agents/<id>/artifacts/  ← 仅父侧代码提升   REPORT.md 等三份人读产物

三条数据流值得单列：架构事实流——architecture.md 被逐字注入每份猎人提示词，替代"每个 agent 重读一遍仓库"；候选流——猎人只返回一条结构化 JSON，父智能体按稳定指纹与根因去重后候选才进入 findings.json；证据流——子智能体产物先落在自己的 scratch/，进程退出后只有父侧受信代码能按白名单把文件"提升"到父方拥有的 artifacts/。

4.2 分层模块拆解

**协议层（SKILL.md）**定义模式与档位：guidance 模式（安全问答、单点审查）不授权完整工作流、不建目录、不写产物；full audit 模式（明确要求审计或渗透测试、要报告产物）才跑六阶段。档位分 quick（粗化覆盖单元、一波猎人、一次覆盖批评、候选验证与终验合并）、standard（默认）、deep（按子系统与生命周期模式切分单元，批评波跑到干净通过，候选验证与终验必须是两个不同 agent）。

编排层负责预算闸门、单元分配、写权、指纹合并与覆盖率声明，有一条硬纪律——先预留、再采购：启动任何侦察 agent 前必须为 4 次基线侦察、1 至 2 次批评、至少 1 次验证留出预算；预算撑不住下限时，一个 agent 都不许启动。

执行层是三类角色的契约。猎人提示词为九段固定结构：角色前言、architecture.md 全文、分配的覆盖 ID 与路径、逐字复制的攻击类文本、排除项及理由、狩猎方法、验证规则、需避免重复的同伴单元、唯一 scratch 路径与结构化返回契约。验证者的第一条指令则是："你没有写这个候选，请从源码与有界本地证据出发尝试推翻它"，且不得收到其他验证者的结论。

状态层是 7 个共享文件：run-metadata.json、architecture.md、coverage-ledger.json、findings.json、REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md。台账是核心：覆盖单元按"攻击面 × 边界 × 攻击类"切分，每个单元带状态、负责人、看过的路径、检查方法、结果与证据文件。

校验层是两个零依赖 Node 脚本：validate-findings.cjs 是针对 report-schema.json 关键字子集的自研 JSON Schema 解释器，叠加发现记录特有检查；validate-coverage-ledger.cjs 校验台账结构与本地证据。两者都内置输入 5 MB、嵌套 64 层、数组 1000 项、错误上限 100 等限制，并用严格 UTF-8 解码与危险码点转义处理诊断文本。

领域知识层是 10 个 playbook：内存安全与二进制、AI 与 LLM、Web 协议与认证、客户端与浏览器、供应链与发布、云与部署、RPC 与消息协议、资源耗尽与可用性、数据隔离与生命周期、桌面移动与本地 IPC。

4.3 核心机制与算法原理

覆盖驱动狩猎：猎人被分配台账单元而非自由找 bug。单元优先级有明确排序——先未认证或最低信任入口，再到保护高价值资源（凭据、跨租户数据、代码执行、发布权限）的边界，然后是上一轮缺口与变更源码，最后才是同源复跑；并列时按 coverage_id 字典序打散，保证同一仓库两次运行可复现。

对抗式验证：验证者职责是证伪，且与找到候选的 agent 严格分离；确认需同时满足"独立建立完整路径"与"有界观测结果"。三个结论的字段差异是设计精髓：confirmed 必须含完整来源追踪、边界条件、可执行证据与最小修复；needs_validation 只允许写精确未决事实、无严重级、可执行的补充验证计划；rejected 必须写明证伪理由。用作者的话说：needs_validation 不是停放投机想法的地方。

写隔离与产物提升：父方在沙箱运行前保留 scratch/、artifacts/ 的目录描述符（不传给 agent），并声明可提升路径白名单与字节上限；沙箱与进程退出后按 11 步逐个提升——拒绝绝对路径、.. 与符号链接组件，从保留描述符做不跟随链接的逐级遍历，叶子非阻塞打开并校验为普通文件、硬链接数为 1、且在限额内，复制后复查身份与大小未变，目标端独占创建；禁止递归复制、通配、解压，禁止提升符号链接、FIFO、socket、设备与硬链接。子智能体 ID 还必须匹配 ^[a-z0-9][a-z0-9_-]{0,63}$ 且不能是 Windows 设备名，以消灭大小写折叠碰撞与保留名冲突两类经典逃逸。

跨轮次累加：多轮针对同一仓库的运行是增量的。新一轮读取所有兼容的既有台账与结果，逐条比对当前源码；只有相关源码与条件未变、证据仍满足当前契约时，既有 confirmed 才被携带进本轮候选集，且仍要走本轮终验；源码已变的既有确认会被改造成"重验证单元"，且不得被写进猎人排除清单。

4.4 性能优化手段与设计取舍

第一，上下文优先于并行度：Cloudflare 的经验值是每个 agent 的上下文占用保持在窗口的 25% 以下，填满即幻觉，因此把"读整个仓库"换成"读分配单元加架构摘要"。第二，持久化优先于并行度：各阶段写同一数据库，任何阶段可恢复、重试或复用；博客提醒瞬时 API 错误有时以 200 OK 响应流文本返回，必须显式分类，否则空跑会被记成成功。第三，按仓预算而非按 run 预算：成本几乎都在狩猎阶段，于是补猎成为成本与覆盖之间的杠杆，每多一轮约为首轮成本的一半，并对每仓设任务上限、配 50 至 200 的 worker 池。第四，删掉不该有的东西：他们曾全链路接入 Semgrep，结果一个月里猎人零次调用。

代价同样明确：quick 档牺牲召回与冗余度；standard 与 deep 的墙钟时间以小时计（博客称复杂仓库单轮数小时，最差超过 14 小时）；流程刻意"过度上报"以不漏报，噪声必须靠验证级联压下去。

4.5 与其他架构路线的差异

按 Semgrep 的分类，同类工具分三条互斥路线：LLM 主导的 exploitgen（以崩溃为唯一判据）、SAST 与 LLM 混合（静态分析先行筛点）、以及本仓库所在的技能增强型。本质差异是谁当判据：exploitgen 用可复现崩溃，混合派用静态命中，技能派用对抗验证加字段级证据契约。由此产生三个可观测差异：技能派语言无关、不必自建沙箱（继承宿主）、成本只是宿主订阅上的 token；但它拿不到流水线派的确定性连接点，缺少可运行 PoC 时只能落到 needs_validation。

五、应用场景

场景一：发版前的全量仓库审计

痛点：三万行的服务仓库，评审靠人工抽检，覆盖率无法声明、结果无法复现。 做法：以"明确要求完整审计"的措辞触发 full audit，输出目录默认在仓库之外，产出三份人读产物与两份机读产物。 最小示例：

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
cd /path/to/target-repo   # 提示词：security audit this codebase, output to ~/audits/payments-svc
node skills/security-audit/validate-findings.cjs ~/audits/payments-svc/run-1/findings.json
node skills/security-audit/validate-coverage-ledger.cjs ~/audits/payments-svc/run-1/coverage-ledger.json

收益：Cloudflare 博客给出的等价基准是——约三万行仓库单遍产出约 100 条候选、耗时 3 至 4 小时，约 3 小时内压到约 80 条高保真问题，自动修补平均 5 分钟一条，"发现、验证、去重、开出 PR"总长约 14 小时。需要强调：这是 Cloudflare 自有 harness 在其内部仓库上的数据，不是本 skill 的单仓库实测。 边界：不要当"每次提交都跑"的门禁，大扫描是周期性清账；PR 级改动应走只审指定路径或 diff 的 scoped run。

场景二：LLM、RAG、Agent、MCP 应用自身的注入与越权审计

痛点：真正的风险不是模型说了不该说的话，而是不可信内容经由模型触达了不该触达的能力：跨租户检索串数据、记忆被投毒影响他人会话、工具参数被外部内容改写、MCP 响应被当成可信指令。 做法：AI-AND-LLM.md 把数据流固化为一句话——不可信内容进入模型或记忆，再影响能力、权限或汇点——并要求猎人在该链路上找确定性控制的缺失。两条纪律值得直接抄进自家规范：提示注入本身不是发现（必须落到越权、泄露或触达原本不可达的汇点）；护栏提示不是安全边界（只承认确定性检查、资源级授权、隔离、绑定与受限凭据）。它还拆开"授权"与"动作绑定"：攻击者可控内容在受害者合法权限下引发动作、而受害者并未明确请求该精确动作，即动作绑定失败。 最小示例（宿主提示词）：对本仓库的 RAG 检索与工具派发链路做 full audit，范围限定 internal/retrieval、internal/memory、internal/tools，重点检查检索 query 内的租户与 ACL 过滤、记忆写入的权限与作用域、MCP 响应被当作可信输入的位置，输出到 ~/audits/rag-service。 收益：把 AI 安全拆成可勾选且带来源追踪的检查链；能本地复现的写 confirmed，依赖线上模型或部署行为的写 needs_validation。 边界：它不调用线上端点、生产身份与付费 API，也不做可用性压测；决定性事实若只存在于部署环境，结论只能停在 needs_validation。

场景三：原生与二进制组件的内存安全审计

痛点：C/C++、Rust-unsafe、解析器、JIT、固件靠读代码难判未定义行为，传统 SAST 误报高且缺证据。 做法：走 MEMORY-SAFETY-AND-BINARY.md，猎人可以编译片段、构造畸形输入，但只能在满足全部控制条件的 OS 强制沙箱内执行：无外网、空环境变量白名单、目标与工具链只读、仅可写自己的 scratch/、显式资源与墙钟上限（Linux 上以 unshare 为基础）。一个易踩的坑：宿主本身跑在 Docker 内时，沙箱需要 seccomp=unconfined 与 apparmor=unconfined，否则会静默启动失败。 收益：固定收益是证据可复现——崩溃、精确输入、命令与限额一并入库；云厂商经验也支持把这类目标排在前面。 边界：缺本地工具链时无法执行，只能落 needs_validation；把沙箱放宽到能联网、能写宿主目录是明确的错误用法。

场景四：供应链与发布链路审计

痛点：被利用的入口常是依赖解析、CI 配置、签名与更新机制、插件加载，而非业务代码。 做法：SUPPLY-CHAIN-AND-RELEASE.md 覆盖依赖、CI、发布签名、更新通道、插件与扩展；与 CLOUD-AND-DEPLOYMENT.md 搭配，对发版权限这类高价值资源，台账优先级会把它排在前面。 收益：与 SCA 互补——SCA 管已知漏洞比对，它管信任链能否被绕过。这里有一条来自社区盲测的硬边界：issue #20 中，第三方团队以带种子靶标做 n=3 盲比，技能臂中位精确率 90%、两个近似诱饵零命中、每条结论都带来源追踪，但对"依赖中真实披露、晚于模型训练截止的 CVE"三轮全部漏掉（0%）——因为它在沙箱中确认所需事实在外部后正确地选择不猜，属设计边界而非缺陷。 边界：不要指望它做 CVE 比对与版本升级建议，应与 SCA、SBOM 流程并置。

场景五：季度增量审计与合规留痕

痛点：难的不是跑一次，而是半年后再跑能对上上一轮；人工维护台账几乎必然失真。 做法：把输出目录长期归档；下一轮把既有台账与结果路径交给父智能体，它会逐条比对源码、携带未变的既往确认、把变了源码的既往确认改造成重验证单元，并按指纹避免重复计数。档位按风险选：常规季度 standard、高风险或大仓 deep、回归验证 quick（须声明为部分覆盖）。 收益：产出天然是可审计证据链——覆盖率声明、未决清单、每条结论的来源与证据路径。 边界：quick 与 scoped run 必须自我声明为部分覆盖，绝不能把"这次没发现"读成"这里安全"。

六、快速上手

前置条件：支持工具调用与并行子智能体的宿主模型；Node.js（跑校验器）；一个 OS 级强制沙箱（无外网、空环境变量白名单、目标与工具链只读、仅可写分配目录、显式资源限额）。三者缺一，工作流会把关键线索保留为 needs_validation 而不是执行目标代码。安装与触发见上文示例；只问安全问题时走 guidance 模式，不建目录、不写产物。跑完先机械校验，再读 REPORT.md、FINDINGS-DETAIL.md 与 NEEDS-VALIDATION.md。

七、横向对比

维度	security-audit-skill	Trail of Bits skills	evilsocket/audit	defending-code-harness	VVAH / deepsec
形态	宿主内技能	技能集（约 40 插件）	独立 8 阶段 agent	独立流水线	独立流水线
自带模型调用	否，用宿主模型	否	否，走 Claude 订阅	是	是
执行 / PoC	沙箱内有界执行，不产 exploit	多数只读	编译并运行 PoC	以 ASAN 崩溃为判据	多数不做动态执行
输出	报告 + 自定义 JSON Schema	SARIF 2.1.0 等	结构化报告	SARIF + 补丁	SARIF / JSON
沙箱	继承宿主，README 强制要求	继承宿主	继承宿主	gVisor + 出口白名单	自带（bubblewrap 等）
语言覆盖	语言无关 + 10 个 playbook	偏原生、密码学、合约	语言无关	C/C++	10 至 42 种语言
许可	MIT	CC-BY-SA 4.0	MIT	Apache-2.0	Apache-2.0
成本模型	宿主订阅上的 token	同左	订阅（可 OAuth）	基建 + token	基建 + token

值得注意的是 evilsocket/audit：它自称是对 Cloudflare Project Glasswing 所述流水线的从零复现，8 个阶段各写成一份提示词加一张 JSON Schema，默认模型分层（侦察与验证用 Opus 4.7，狩猎与去重用 Sonnet 4.6）并强制走订阅计费。相比之下，security-audit-skill 提供的是可被任意宿主继承的方法论。同期 Strix、PentAGI 等自主渗透引擎的评测（arXiv 2605.10834，重复 3 次并做累积评估）显示：PentAGI 严重级最高但假阳性最多、成本最高，Strix 假阳性更少但发现更少；且假阳性会随重复运行累积——这从反面解释了为什么验证与去重必须独立成阶段。

八、局限、风险与社区观察

维护节奏与治理：截至 2026-09-18 累计 14 次提交、最近推送 2026-09-14；开放 issue 30、开放 PR 19，其中 09-16 至 09-17 两天涌入约 13 个社区 PR，但几乎全部未合并。无 Release、无 Tag，锁到某个 commit 是唯一可复现手段。

平台兼容性：issue #11 报告在某宿主（Antigravity 配 Gemini 3.1 pro）下"杀掉并行子智能体"，直接破坏猎人波次这一核心机制；PR #31 在修缺少 O_NOFOLLOW、O_NONBLOCK 的平台上 CLI 测试挂起的问题。它的强项同时就是它最强的平台假设。

校验器不等于正确性：issue #21 指出 validate-coverage-ledger.cjs 只校验证据路径的词法形态与归属前缀，不校验被引用产物是否存在，台账因此可能声称有本地证据而实际没有；PR #25、#26、#34 正在补这个洞。Cloudflare 也强调机械校验只保证 schema 服从性，不保证结论正确性。

召回率不可知，是设计上的诚实：Cloudflare 明确不宣称假阴性率（不存在某仓库全部真实漏洞的标注集合），只能用重跑是否持续发现新问题作为代理指标；README 也直说单次运行约只覆盖多次累计的一半。

已确认的能力缺口：issue #20 的第三方盲测（n=3、单靶标、自研臂有利益披露）给出六类缺口：依赖 CVE 覆盖为 0%、领域正确性缺陷未进入覆盖地图、可利用性门控、成本、弱模型档位表现等。

许可与生态：MIT 对商用友好，社区建议改 MIT-0 未被采纳。输出是自定义 JSON Schema 而非 SARIF，社区转换器尚未合并，接进 AppSec 平台需自建适配层。最后一条使用风险是 agent 为了让 PoC 生效而改源码、再报告自己刚制造的漏洞——对策是硬约束：上报前声明威胁模型，确认项必须附针对未修改代码运行的 PoC 与提议补丁，由不产生自身发现的确定性代码把关，补丁与定级始终必须人工签核。

九、小结与行动建议

它的价值不在发现了多少漏洞，而在于示范了如何把一次不可复现的模型直觉，拆成可计量、可续跑、可对抗验证、可机器校验的流程；覆盖台账、对抗验证与字段级证据契约三项设计与具体模型无关。建议：

1. 先做低成本试点：挑一个非生产、约三万行、有本地工具链的仓库跑一次 standard，用两个校验器验证产物契约，把 NEEDS-VALIDATION.md 当作沙箱能力清单。
2. 把节奏设计成周期性清账而非门禁：季度 deep、月度 standard，PR 级只做 scoped run 或交给宿主 agent。
3. 与 SCA、SBOM 并置：接受依赖 CVE 与领域正确性不在覆盖范围，把它定位为代码级信任边界审计。
4. 沙箱先行、权限最小化：先验证无外网、空环境变量、只读目标、仅 scratch 可写与资源限额。
5. 抄三条纪律进自家规范：提示注入本身不是发现、护栏提示不是安全边界、授权与动作绑定是两套控制。
6. 盯上游，必要时自己 fork：19 个待合 PR 含攻击类扩展与校验器修复，且项目无版本锚点，建议锁 commit 并维护内部薄补丁层。

资料来源（抓取日期均为 2026-09-18）：GitHub Trending daily 与 weekly 榜单、GitHub REST API；仓库源码（README、SKILL.md、HUNTING.md、RECONNAISSANCE.md、VALIDATION-AND-REPORTING.md、ATTACK-CLASSES.md、AI-AND-LLM.md、report-schema.json、validate-findings.cjs）；Cloudflare 博客《Build your own vulnerability harness》与《Project Glasswing: what Mythos showed us》；Semgrep 博客《Comparing Open-Source AI Code Security Harnesses》；arXiv 2605.10834；evilsocket/audit 的 README；GitHub issue #10、#11、#20、#21。文中的 harness 级数字（20,799 原始候选、12,057 通过验证、13,841 汇总、5,442 去重、7,245 条可执行结论、验证拒绝率从 40% 降到 11%、高完整性占比从 35% 升到 58%、128 个仓库、25,472 次 wishlist 写入、50 至 200 的 worker 池）均出自 Cloudflare 官方博客对其自有生产 harness 的描述，不是本 skill 在单仓库上的实测结果；无法确认的信息已标注为个人经验或未合并状态。