Cloudflare 开源的安全审计代理技能，用六阶段流程把审计拆成侦察、覆盖驱动狩猎、候选对抗验证、结构化输出、独立复核与目标中立报告，产出可机器校验的发现记录。
项目定位与要解决的问题
security-audit 是 Cloudflare 发布的一个编码代理技能，而非独立的扫描器或安全服务。它本身不包含检测引擎，而是把宿主编码代理改造成安全审计员，由代理依照技能文档定义的阶段、角色与产物去完成侦察、狩猎和验证。按仓库说明，它是 Cloudflare 内部漏洞发现 harness 的种子，那套 harness 后来发展为多阶段、面向整个集群的系统，本仓库是它演化之前的单仓起点。安装通过 Skills CLI 完成，支持用户级与项目级；使用时把编码代理指向待审代码库，提出安全审计、查找漏洞、渗透测试代码等请求即可触发。技能声明自己与目标无关，既面向原生二进制与内核，也面向 LLM 应用、HTTP 协议与认证、客户端、供应链与发布、云与部署、RPC 与消息、资源耗尽、数据隔离与生命周期、桌面移动与本地 IPC 等方向，并区分完整审计模式与指导模式。
核心能力
技能的核心是把发现做成可分类、可复核的记录，而不是叙述性结论。它区分三种裁定：confirmed 要求完整的来源追踪与有边界的观察结果；needs_validation 必须携带一个精确、尚未解决的事实，并且不附带严重级别；rejected 用来记录被证伪的候选。设计原则规定，只有已经确立的边界失效才能确认，被来源约束但实际被阻断的线索要保留为 needs_validation 并写清未解事实；验证必须对抗式进行，检查某个发现的代理永远不能是发现它的代理；严重性必须来自影响，即可能性乘影响，而不是与检查清单的偏离；纵深防御的缺失不算漏洞，若 A 层已阻断攻击，B 层的缺席只是加固建议。这些裁定语义与原则共同把模糊的怀疑、未解疑问和已证伪假设分流到不同位置，避免把不确定性包装成漏洞，也让每一条确认都有可追溯的证据链。
技术结构与实现思路
仓库由流程文档、攻击面分类文档、schema 与校验器组成。SKILL.md 承载安装、核心原则、平台术语、流程总览与审计反模式；RECONNAISSANCE.md 与 HUNTING.md 分别对应第一阶段侦察提示与合成、第二阶段编排与狩猎方法；VALIDATION-AND-REPORTING.md 覆盖第三到第六阶段。攻击类提示按目标类型拆分为多个文件：通用的 ATTACK-CLASSES.md，以及内存安全与二进制、AI 与 LLM、Web 协议与认证、客户端、供应链与发布、云与部署、协议 RPC 与消息、资源耗尽与可用性、数据隔离与生命周期、桌面移动与本地 IPC。产物方面，第一阶段生成 architecture.md 与 coverage-ledger.json，第四阶段生成 findings.json，最终派生出 REPORT.md、FINDINGS-DETAIL.md 与 NEEDS-VALIDATION.md。report-schema.json 定义三种裁定的结构，validate-findings.cjs 与 validate-coverage-ledger.cjs 是零依赖校验器，各自配有测试文件。
实际工作流程
流程按六个阶段推进。第一阶段侦察，绘制架构、信任边界、输入面、既有证据与确定性覆盖，落到 architecture.md 与 coverage-ledger.json。第二阶段按账本单元分派彼此隔离的狩猎者，记录其检查项，再由覆盖评论者寻找缺口。第三阶段把每个唯一候选交给全新的验证者，其任务是尝试证伪。第四阶段输出结构化结果，将 confirmed、needs_validation、rejected 写入 findings.json，并对照 report-schema.json 校验。第五阶段由全新代理独立复核最终来源声明，被实质性替换的记录还要再经一名独立验证者。第六阶段从已核实记录与覆盖账本派生目标中立的报告文件。父代理在账本创建后及其后每次更新后运行覆盖账本校验器，在第四阶段以及第五阶段每次替换后运行 findings 校验器。同一仓库的多次运行是叠加的：借助先前的账本与发现定位缺口、重新验证已变更来源、沿用当前来源证据，而不把过时或未解决的条目算作已覆盖。执行目标代码需要操作系统级沙箱，若缺少断网、净化后的白名单环境、资源限制与受限写入等控制，流程会把线索保持为 needs_validation 而不运行目标代码。
与同类方案的取舍
与规则驱动的静态扫描不同，这个技能的组织单位是代理角色与账本，而不是规则集合：覆盖由 coverage-ledger 显式记账，缺口交给覆盖评论者查找，候选取证由不能是发现者的验证者对抗式检验，最终结论还要经过第五阶段的独立来源复核，并在流程内反复通过 JSON schema 与零依赖校验器自检。结论被强制分为三类，只有 confirmed 允许附带严重级别，且级别必须由影响推导而非清单偏离，使未解决的疑问有明确落点而不会被包装成漏洞。多次运行被设计为叠加而非从零重来，可依据旧账本补齐缺口并复验已变更来源，未完成或过时的工作不会被算作覆盖。README 提到，在其测试运行中单次运行大约只能发现重复运行合计发现总量的一半，这一观察属于项目方自述，并非经第三方复核的基准数据。此外该技能源自 Cloudflare 自有的漏洞发现 harness，是其后续多阶段集群化系统的单仓起点。
值得关注的设计
把安全审计拆成有顺序约束的六阶段流水线：侦察阶段先产出架构记录与覆盖台账，狩猎者按台账单元派发，再由覆盖率评论者找缺口，使审计从灵感驱动转为覆盖驱动。对抗式验证是核心设计，检查发现的 agent 永远不是发现它的 agent，最终来源声明还要由全新 agent 复核，被实质替换的记录再交给另一个独立验证者。判定采用三态：已确认要求完整来源链与有界观测结果，待验证必须写出确切未决事实且不给严重性，已拒绝记录被证伪的候选；严重性要求影响（可能性与影响），防御纵深缺口不算漏洞。记录受 JSON schema 约束，两个零依赖校验器在固定阶段反复运行，并配有测试与生产者兼容夹具。同一仓库的多次运行是加性的，旧台账与发现用于定位缺口、重验变更源码，不把过期或未决工作算作已覆盖。项目方称该技能是 Cloudflare 漏洞挖掘体系的单仓库起点，属于自述。
适用领域和具体场景
典型用法是在目标代码库中启动编码 agent，直接说对这份代码做安全审计、在某个目录找漏洞，或指定输出到某个审计目录；技能在匹配触发词时自动激活，区分完整审计模式与指导模式，未指定输出目录时默认写入用户主目录下的运行序号目录，且只有显式选择被版本控制忽略的目录才会写入目标仓库。它按目标类型分发专门的狩猎类文件：通用与显眼攻击类、内存安全与二进制内核、AI 与 LLM（提示注入、agent 与工具、输出处理）、Web 协议与认证（请求分帧、缓存、认证协议）、客户端（DOM 注入、消息信任、界面重定向、原型污染）、供应链与发布、云与部署、RPC 与序列化及队列与流式协议、资源耗尽与可用性、数据隔离与生命周期、桌面移动与本地 IPC。流程产物便于工程化消费：findings.json 与 coverage-ledger.json 由校验器检查，报告文档由已验证记录导出，同一代码库可反复增量审计。
哪些人会受益
主要面向安全工程、应用安全与红队团队，尤其是希望把编码 agent 纳入常规审计流程、需要可复核证据链而非一次性对话结论的团队；也面向研究 LLM 驱动漏洞发现的 AI 安全研究者，以及关注供应链、云部署、容器与身份策略等细分面的平台与基础设施团队。使用门槛写得比较明确：需要一个支持工具调用与并行子 agent 的编码 agent 及相应模型，需要 Node.js 运行零依赖校验器，还需要操作系统级强制沙箱来跑目标方控制的构建、测试、进程、浏览器、模拟器、模糊测试与夹具，该沙箱必须禁用外部网络、使用净化的白名单环境、实施资源限制并仅允许写入分配的暂存路径。不具备这些条件的组织只能得到静态线索，流程会把相关问题保持在待验证状态。此外，构建 agent 技能与工作流的人也能拆用其中的阶段说明、schema 与校验器。
上手、部署与集成
接入路径较轻：通过 Skills CLI 以一条命令添加该技能并指定技能名，加全局参数可做用户级安装，帮助命令可查看 agent 选择与非交互选项。安装后无需改动被审计仓库，触发词命中即自动启用，默认输出落在用户目录，避免污染目标代码。产物是纯 JSON 与 Markdown 文件，校验器零依赖，便于接入既有流水线、归档或工单系统，不需要额外服务端组件。项目采用 MIT 许可证，并提供安全 AI 研究邮箱作为反馈渠道。项目方称内部体系正是从这个单仓库技能演化为多阶段、全舰队规模的系统，意味着存在从试点到平台化的路径，但这一演进关系属项目方自述，README 未给出部署规模、用户数量、版本发布节奏或维护者结构等可核实的采用指标，实际落地成本主要取决于沙箱建设与并行子 agent 的算力开销。
限制与风险
该技能本身不是独立扫描器，也不负责修复，它是给编码 agent 的流程规范与提示集合，效果高度依赖所用模型的能力与工具调用质量。操作系统级沙箱是硬前提：若不能禁用外网、净化环境、限制资源并隔离写入，流程就无法执行目标方代码，相关线索只能停留在待验证状态。README 未提供误报率、召回率、耗时、成本或与任何具体工具的对照数据；唯一量化说法是项目方称在其测试运行中，单次运行大约发现重复运行总量一半的漏洞，这属于项目方自述且未经独立验证。schema 与校验器只保证记录结构合规、可被机器消费，并不保证发现真实或覆盖完整。六阶段流程配合多轮独立复核，隐含较高的时间与算力开销，但文档未给出数量级。防御纵深缺口不算漏洞、严重性必须基于影响等原则，可能过滤掉有价值的加固建议，也给人工判断留下较大空间。此外未见版本发布、贡献者规模、依赖生态与长期维护承诺等公开信息可查。
综合观察
这把 LLM 辅助安全审计从聊天式问答推向具备流程纪律的工程实践：覆盖台账让审计范围可追溯，发现者与验证者分离降低自我确认偏差，三态判定配合来源链要求让结论可分级复核，机器可读记录加零依赖校验器让产物能被流水线消费，把沙箱列为前置门控并把无法执行的目标线索保留为待验证，也体现出对能力边界的诚实表述。整体设计清晰，阶段划分、文件职责与判定语义都写得具体，便于团队照搬或裁剪。需要保留的地方在于，文档中关于效果与演进的陈述基本来自项目方，缺少基准测试与独立评估，实际产出受模型、沙箱与目标规模影响很大，多轮复核带来的算力成本也未量化。因此更合理的定位是团队自建审计 agent 的骨架与规范模板，适合先小范围试点、验证产出质量后再考虑扩展为常规流水线，而不宜当作开箱即用的漏洞扫描产品。
解读依据仓库 README 与简介，周期榜名次和数据按已采集的日期动态计算；项目文档和实际能力可能变化。