Cloudflare 开源的编码智能体技能，将编程智能体变成安全审计员，通过六个阶段编排相互隔离的子代理，产出经独立复核、带 JSON 模式校验的漏洞发现记录。
项目定位与要解决的问题
这是一个面向编码智能体的技能包，而不是独立运行的扫描服务：它通过 Skills CLI 以 npx skills add 安装，可选 –global 做用户级安装，并在请求出现安全审计、查找漏洞、代码渗透测试等触发语时自动激活。直接要求审计代码库或渗透测试会走完整审计模式；安全提问和聚焦式漏洞工作走指导模式，除非明确要求产出报告工件。完整模式下未指定输出目录时，默认写入 ~/security-audit-skill/仓库名/run-N，只有在显式选定被版本控制忽略的目录时才会写进目标仓库内部。项目自述其源自 Cloudflare 的漏洞发现 harness，是该 harness 演化前的单仓库起点。
核心能力
核心原则强调证据与克制：只确认已确立的边界失效，来源充分但被阻断的线索保留为 needs_validation 并写明精确的未决事实；严重性必须由影响支撑，按似然乘以影响评估，而不是偏离检查清单；如果 A 层已经阻止攻击，缺少 B 层只算加固建议而非漏洞；检查某条发现的代理永远不能是发现它的代理。判定被严格区分为三类：confirmed 具备完整来源追溯和有界的观测结果，needs_validation 只含精确未决事实且不带严重性，rejected 用于记录被证伪的候选。
技术结构与实现思路
仓库由主技能文件 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-schema.json，以及派生的 REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md。校验器 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。父代理在账本创建后及之后每次更新后运行覆盖校验器，在第四阶段及第五阶段每次替换后运行发现校验器。对同一仓库的多次运行是叠加的：利用既有账本和发现定位缺口、重新验证已变更源码、沿用当前源码证据，而不把陈旧或未决工作视为已覆盖。
与同类方案的取舍
它强调的是流程化编排而非单次模型输出：覆盖账本把每条检查显式登记，再由覆盖批评者专门寻找覆盖缺口；每个候选都由非发现者的新验证者尝试证伪，最终来源主张还要再过一轮独立复核；发现以 JSON 模式约束并被零依赖校验器强制校验；报告由已验证记录加覆盖账本派生，因此对目标技术栈保持中立。仓库还把多次运行当作叠加行为，用既有账本定位缺口并重新验证已变更源码。README 称在项目方自己的测试中，单次运行只找到重复运行总计的大约一半漏洞，这属于项目方自述，未提供独立基准或横向对比数据。此外它要求操作系统级强隔离沙箱，缺少这些控制时流程会保留 needs_validation 而不执行目标代码。
值得关注的设计
把安全审计拆成侦察、覆盖账本驱动的漏洞猎取、候选验证、结构化输出、独立记录核验、目标中立报告六个阶段，并用 coverage-ledger.json 与 findings.json 串起全过程。其做法是以覆盖账本作为任务分配与查漏的依据，强制发现者与验证者不是同一个代理，材料被替换后还要再经一名独立验证者复核；confirmed、needs_validation、rejected 三种判定各绑定明确定义，并由 report-schema.json 与零依赖 Node 校验器约束，使结论可机读、可复算。
适用领域和具体场景
可对单个代码仓库执行完整安全审计或渗透式审查，也可只做聚焦的漏洞咨询。随附的攻击类别文件覆盖内存安全与二进制内核、LLM 提示注入与代理工具调用、HTTP 请求框架与认证协议、客户端 DOM 注入与原型污染、供应链与发布签名、云与部署的 IAM 及容器、RPC 与消息队列、资源耗尽与配额、租户数据隔离与生命周期、桌面移动与本地 IPC 等。对同一仓库的多次运行是叠加的，可借旧账本定位缺口、复核已变更源码并保留当前源码证据。
哪些人会受益
面向使用编码代理的安全工程师、渗透测试与红队人员、云平台与基础设施团队、LLM 应用与客户端开发者，以及需要可追溯发现记录的评审或合规场景。使用者需要支持工具调用与并行子代理的模型、用于运行校验器的 Node.js，以及断网、环境白名单、资源受限且只允许写入指定临时路径的 OS 级沙箱；若缺少这些控制，工作流不会执行目标代码，只能把线索保留为需要验证。
上手、部署与集成
通过 Skills CLI 以 npx skills add 安装，也可加 –global 做用户级安装；在编码代理中提出安全审计、查找漏洞等请求会自动触发，完整审计模式未指定输出目录时默认写入 ~/security-audit-skill/<仓库名>/run-<N>，只有显式选择被版本控制忽略的目录才会写入目标仓库内部。项目方说明该技能源自其漏洞发现 harness，而后者已发展为多阶段、跨机群的系统；项目采用 MIT 许可，便于内部集成与二次开发。
限制与风险
技能本身不提供沙箱，缺少强制隔离、断网与资源限制时不会执行目标代码。它只确认已被证实的边界失效，有源码依据但被阻断的线索保留为需要验证且不给严重性；纵深防御缺口被当作加固建议而非漏洞，严重性必须由可能性乘影响得出。效果取决于代理的并行子代理能力、覆盖账本的完整性以及目标源码是否可得。README 中单次运行约发现重复运行总数一半的说法出自项目方自述的测试运行，未经独立复核。
综合观察
该项目把漏洞发现从规则扫描转向可追溯、可复核的流程工程：用覆盖账本保证广度，用发现者与验证者分离抑制误报，用结构化记录与校验器保证机器可读和一致，并以目标中立方式生成报告。它适合具备沙箱与并行子代理条件的团队在单仓库起步，再扩展为更大规模的审计流水线。成熟度上具备 JSON Schema、零依赖校验器、配套测试与 MIT 许可，但覆盖提升等效果数据仍属项目方自述，尚需第三方验证。
解读依据仓库 README 与简介，周期榜名次和数据按已采集的日期动态计算；项目文档和实际能力可能变化。