Cloudflare 出品的编码智能体技能：用六个阶段把智能体变成安全审计员，经侦察、覆盖驱动狩猎、对抗式验证与独立复核，产出机器可读且经独立验证的发现记录，不把未解决线索当作已覆盖。
项目定位与要解决的问题
security-audit 是一个编码智能体技能（skill），本身不是独立扫描器，而是给具备工具调用与并行子智能体能力的编码 agent 加装一套安全审计工作流。项目方自述，它曾是 Cloudflare 漏洞发现 harness 的种子，该 harness 后来发展为多阶段、全舰队范围的系统，而本仓库是它演化之前的单仓库起点。安装通过 Skills CLI 完成，可全局或项目级安装；使用时在待审计代码库中启动智能体，发出 security audit this codebase 一类请求即自动触发。直接针对代码库的审计或渗透请求进入完整审计模式，安全提问与聚焦型漏洞工作默认走指导模式，除非明确要求产出报告产物。完整审计模式在未指定输出目录时默认写入 ~/security-audit-skill/<仓库名>/run-N，并且只有在你显式选择版本控制忽略的目录时，流程才会写入目标仓库内部。运行前提包括支持工具调用与并行子智能体的模型、用于零依赖校验器的 Node.js，以及一个由操作系统强制实施的沙箱。
核心能力
核心由两套机制咬合。其一是覆盖账本：第一阶段产出 architecture.md 与 coverage-ledger.json，把架构、信任边界、输入面、既有证据与确定性覆盖显式登记为可核查单元，此后的狩猎、缺口批评与报告都从账本派生，使覆盖成为可验证状态而非主观印象。其二是三分判定：confirmed 要求完整的来源追溯与有界的观测结果，needs_validation 要求记录一条精确的未解事实且不得标注严重性，rejected 用于记录被否证的候选，三者语义互不混淆。设计原则同样构成核心约束：只确认已确立的边界失败，源码层面有依据但被阻断的线索保留为 needs_validation；检查某条发现的智能体绝不能是发现它的智能体；严重性必须由影响推导，即可能性乘以影响，而不是以是否偏离检查清单为准；若 A 层已阻止攻击，B 层的缺失只记为加固建议而非漏洞。这些约束共同把“发现”定义为可复核的证据链，而非一句判断。
技术结构与实现思路
仓库由文档层与契约层两部分组成。文档层里，SKILL.md 承载安装、核心原则、平台术语、流程概览与审计反模式；RECONNAISSANCE.md 给出第一阶段的侦察提示与综合指令；HUNTING.md 负责第二阶段的编排、狩猎方法与验证规则；VALIDATION-AND-REPORTING.md 覆盖第三至第六阶段的候选验证、结构化输出、记录复核与报告。攻击类库按目标形态横向拆分为可组合模块，包括核心与通配及显而易见问题、内存安全与二进制及内核、AI 与 LLM 的提示注入与智能体工具及输出处理、Web 协议与认证的请求分帧与缓存及认证协议、客户端侧 DOM 注入与消息信任及 UI 重定向及原型污染、供应链与发布、云与部署、RPC 与消息协议、资源耗尽与可用性、数据隔离与生命周期、桌面移动与本地 IPC。契约层是 report-schema.json，配合两个零依赖 Node 校验器 validate-findings.cjs 与 validate-coverage-ledger.cjs 及各自的测试文件，把文档化流程变成可执行、可强制的结构，并带有产出方兼容的夹具检查。
实际工作流程
审计按六个阶段推进。侦察阶段梳理架构、信任边界、输入面、既有证据与确定性覆盖，写成 architecture.md 与 coverage-ledger.json；覆盖驱动的狩猎阶段从账本单元分配隔离的狩猎者、记录其检查项，并用覆盖批评者寻找缺口；候选验证阶段把每个唯一候选交给全新验证者，令其尝试否证；结构化输出阶段把 confirmed、needs_validation、rejected 三类记录写入 findings.json，并按 report-schema.json 校验；独立记录复核阶段由全新智能体核验最终的来源主张，发生实质性替换时再交给另一名独立验证者复核；目标无关报告阶段从已验证记录与覆盖账本派生出 REPORT.md、FINDINGS-DETAIL.md 与 NEEDS-VALIDATION.md。父智能体在账本创建后以及此后每次账本更新后运行 validate-coverage-ledger.cjs，在第 4 阶段以及第 5 阶段每次替换后运行 validate-findings.cjs。针对同一仓库的多次运行是累加的：借助既往账本与发现来定向补缺、重新验证已变更的源码、延续当前源码证据，而不把过期或未解决的工作算作已覆盖。
与同类方案的取舍
差异点集中在可验证性与证据纪律，而非扫描速度。发现被 JSON schema 约束，报告由已验证记录与覆盖账本派生，使结论与证据链绑定；验证者与发现者强制分离，每个候选都要经历一次否证尝试；严重性只在有影响依据时才给出，needs_validation 明确不带严重性；覆盖账本让重复运行可以累加，能针对缺口继续推进并重新验证已变更源码，而不是把旧结论当成本次覆盖。攻击类库按目标类型横向铺开，从内存安全、Web 协议、客户端，到 LLM、云、供应链与本地 IPC 都有对应狩猎类。运行环境要求同样体现保守取向：需要由操作系统强制、禁用外部网络、使用清洗过的允许列表环境、施加资源限制、只允许写入指定临时路径的沙箱；缺少这些控制时，流程宁可把线索保持为 needs_validation，也不执行目标代码。项目方自述，在其自身测试运行中，单次运行大约只能发现重复运行总计发现的半数漏洞；该数据来自项目方，README 未给出与其他工具的直接对比。
值得关注的设计
该技能的机制重点不在单次提问，而在流程编排。它把审计拆成侦察、覆盖驱动的狩猎、候选验证、结构化输出、独立记录复核、目标中立的报告六个阶段，并用 architecture.md 与 coverage-ledger.json 把架构映射和覆盖单元固化下来，后续阶段从账本分配孤立狩猎者并安排覆盖批评者找缺口。关键设计是发现者与验证者分离：每个候选交给全新代理尝试证伪，最终源码主张再由另一批代理复核，被实质性替换的记录还要再经一次独立验证。裁定被分成三种互不混淆的状态：confirmed 要求完整源码追踪与有界观察结果，needs_validation 只记录一个确切未解决事实且不给严重性，rejected 记录已被证伪的候选。校验器为零依赖脚本，在账本创建后和每次更新后运行，findings 在第四阶段及第五阶段每次替换后运行。多次运行对同一仓库是增量叠加的，会利用历史账本定位缺口、重验变更源码，并且不把过期或未解决的工作当作已覆盖。
适用领域和具体场景
使用方式是在待审计代码库中启动支持工具调用与并行子代理的编码代理，然后提出安全审计、找漏洞或渗透测试类请求，技能会按触发词自动激活。直接针对代码库的审计请求进入完整审计模式，安全问答和聚焦式漏洞工作进入指导模式，除非明确要求报告产物。完整模式下未指定输出目录时默认写到用户主目录下的 security-audit-skill/<仓库名>/run-N，只有在显式选择被版本控制忽略的目录时才在目标仓库内写文件。除仓库整体审计外，它的狩猎类别文件覆盖了相当宽的目标类型：原生目标的内存安全与二进制内核问题、面向大模型的提示注入与代理工具及输出处理、HTTP 请求分帧与缓存和认证协议、浏览器端 DOM 注入与消息信任及原型污染、供应链与发布签名和更新插件、云与部署中的 IAM 和基础设施即代码及容器无服务器、RPC 与序列化队列流式协议、资源耗尽与配额和运营开销、多租户数据隔离与缓存搜索备份迁移删除恢复，以及桌面移动端的深链、webview、导出组件与本地 IPC。因此它既可用于对单个服务做全量排查，也可针对某一技术栈缩小范围，多次运行还可用于持续跟踪同一仓库的变化。
哪些人会受益
首要使用者是应用安全工程师和安全研究者，他们需要把代理产出的线索变成可追溯、可复核的记录，而不是一段自然语言结论。其次是承担渗透测试或代码评审任务的开发者与红队成员，他们可以在自有或已授权代码库上触发审计，并按需导出 REPORT.md、FINDINGS-DETAIL.md 和 NEEDS-VALIDATION.md。第三类是研究 AI 驱动安全工具的人，因为该技能公开了侦察提示、狩猎方法、验证规则和防模式，还有可测试的校验器与 schema，便于作为实验基线。使用门槛也决定了受众边界：需要具备工具调用和并行子代理能力的模型，需要 Node.js 运行零依赖校验器，动态验证还必须处于操作系统强制沙箱内，该沙箱要禁外网、使用经过清理的白名单环境、施加资源限制并只允许写入分配的临时路径。缺少这些条件的团队仍可用它做静态排查，但会把线索保持在 needs_validation。
上手、部署与集成
安装通过 Skills CLI 完成，一条 npx skills add 命令加 –skill security-audit 即可加入项目，加 –global 则安装到用户级，agent 选择与非交互选项由 skills –help 提供。按项目方说明，这个技能是 Cloudflare 漏洞发现 harness 的起点，该 harness 后来发展为多阶段、面向整个机群的系统，相关思路写在其官方博客的 Build your own vulnerability harness 一文中，仓库则定位为它演化而来的单仓库版本。这种从内部工具开源出来的路径，配合 MIT 许可证和零依赖校验器，降低了试用与二次开发的门槛，感兴趣的团队也可通过 security-ai-research@cloudflare.com 交流。实际推进速度取决于环境是否具备并行子代理和符合要求的沙箱，缺少沙箱时只能得到以 needs_validation 为主的静态结果。技能对同一仓库的多次运行是叠加的，这为在已有审计历史上逐步扩展覆盖提供了运维上的便利，但需要团队自己管理运行目录与历史账本。
限制与风险
该技能明确不追求把所有可疑点都报成漏洞：只有已确立的边界失效才会被确认，有源码依据但被阻断的线索保留为 needs_validation 并附确切未解决事实，且不带严重性；纵深防御缺位若被前一层阻止，只作为加固建议而非漏洞；严重性必须由影响推得，即可能性乘影响，而不是与清单的偏离程度。动态验证受沙箱约束，若没有满足禁外网、白名单环境、资源限制和受限写入这些条件的操作系统级隔离，工作流不会执行目标代码，而是把线索留在 needs_validation，因此在不具备隔离设施的环境中，产出会明显偏向待验证状态。校验器只检查结构与产出兼容性，无法判断漏洞主张是否真实，机器可读不等于结论正确，仍需人工判断。关于覆盖，项目方自述在其测试运行中，单次运行大约只发现重复运行合计能找到的漏洞的一半，这说明单轮结果不应被当作完整覆盖，也提示多轮增量是该流程的组成部分而非可选优化。
综合观察
从仓库简介与说明看，这个项目的价值主要在于把安全审计中容易含糊的部分变成了流程约束：证据链、覆盖账本、发现者与验证者分离、三态裁定和由记录派生的报告，都是为了让结论可追溯、可被独立复核。这些设计针对的是代理审计常见的问题，即结论看似合理却缺少源码依据、覆盖范围无人记账、发现者自我确认。它同时诚实地标注了自身边界，例如把被阻断的线索留在待验证状态而不给严重性，不把加固缺失算作漏洞，以及要求沙箱才执行目标代码。其局限也由此而来：产出质量取决于代理是否严格遵守阶段纪律和沙箱条件，机器可读的校验只保证结构而非真实性。就定位而言，它更像一个可复用的单仓库审计起点和方法框架，而不是能替代人工判断的全自动方案；是否适合你的团队，主要看能否提供并行子代理与符合要求的隔离环境，以及是否愿意按多轮叠加的方式持续运行。
解读依据仓库 README 与简介，周期榜名次和数据按已采集的日期动态计算；项目文档和实际能力可能变化。