Cloudflare Security Audit Skill 快速入门：证据驱动的仓库安全审查

这是什么？适合谁？

Cloudflare Security Audit Skill 是供编码 Agent 读取的审计技能。 它不是 Cloudflare 托管扫描服务，不会因为安装了技能就自动获得云端沙箱或漏洞验证能力。 适合已有工具调用、并行子 Agent 和安全隔离环境的应用安全工程师与代码维护者。

技能从单仓库安全审查出发，让不同角色负责侦察、漏洞寻找、反证和最终记录核对。 README 说明它是 Cloudflare 漏洞发现 harness 的起点，不等于那套完整的多阶段集群系统。 没有并行子 Agent 的聊天界面，不能完整复现这一流程。

核心价值在于保留“查过哪里、依据是什么、还缺什么事实”，而非让模型输出一份听起来专业的报告。 即使没有发现漏洞，也应该记录覆盖边界，而不能把“没找到”说成“已证明安全”。

前置条件与授权

• 使用支持工具调用和 parallel sub-agents 的编码 Agent。
• 安装 Node.js，用于 findings 与 coverage ledger 的零依赖校验器。
• 审计对象必须是自己拥有或已获明确授权的代码库。
• 明确允许读取的目录、禁止事项、测试预算和报告保存位置。
• 目标代码的构建、测试、进程、浏览器、模拟器、模糊测试和 fixture 都必须放入 OS 强制沙箱。
• 沙箱必须禁止外部网络、只提供白名单环境变量、限制资源并只允许写入指定临时路径。

这些约束不是一条提示词能够替代的。 没有满足隔离条件时，不执行目标代码，把需要运行才能判断的线索留在 needs_validation。 不能因为 README 包含 pen-test 触发词，就对未授权网站发送请求。 安装技能与审计目标代码是两个不同动作：安装可能需要联网，目标执行沙箱则应按官方要求断外网。

安装与启用

在你希望保存项目级技能配置的位置运行：

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

需要用户级安装时，官方提供：

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

不确定如何选择宿主时，先查看当前 CLI 的帮助：

npx skills --help

安装后在宿主的技能列表里确认 security-audit 可见，并检查文件来源确为官方仓库。 技能展示名与本站条目名不同是正常情况：实际安装的 skill 名称是 security-audit。 不要假定所有编码助手都支持同样的自动触发、并行数量与权限控制。

第一个任务：有限范围、先读源码

1. 选择一个获授权的测试仓库

使用没有生产密钥和客户数据的代码副本。 先记录 commit 和要审查的 src 范围，明确排除依赖目录及不在授权内的组件。 把报告写到仓库外的绝对路径，减少混入项目文件或被目标构建影响的风险。

2. 在编码 Agent 中发出任务

以下提示按官方触发方式增加了保守范围限制，路径要换成你自己的授权副本：

security audit this codebase
仅审查当前获授权仓库的 src 目录，先做源码阅读与信任边界梳理。
报告输出到 ~/audits/my-project，不修改目标仓库。
先说明输出路径、覆盖单元和并行分工，再继续。
不要对外网目标发请求，也不要访问生产服务。
只有 OS 强制沙箱满足断外网、环境变量白名单、资源限制和临时目录写入限制时，
才允许运行目标构建、测试或 fixture；否则把线索保留为 needs_validation。
每个候选交给没有发现它的独立验证者尝试反证。

~ 是否展开由宿主决定，运行前确认最终绝对目录。 若不能确认沙箱控制真实生效，停止目标执行，而不是让 Agent 自称已经安全隔离。

3. 看侦察产物，而不是等一句结论

Phase 1 应生成 architecture.md 和 coverage-ledger.json。 前者描述架构、信任边界与输入面，后者记录确定性的覆盖单元及其状态。 检查单元是否能对应到源码与入口，避免只有“鉴权”“数据库”等无法追踪的大标签。 父 Agent 在建立 ledger 后及每次更新后运行 validate-coverage-ledger.cjs。

4. 检查最终记录与报告

完整模式经过六阶段，产生结构化的 findings.json。 按 README，结果区分 confirmed、needs_validation 与 rejected。 父 Agent 在 Phase 4 以及 Phase 5 每次替换后运行 validate-findings.cjs。 不要只凭文件名存在就判断 schema 已通过，应该查看宿主给出的实际校验退出结果。

成功判据：覆盖记录可关联源码，候选有独立反证过程，结构化记录通过相应校验器。 报告还应有 REPORT.md、FINDINGS-DETAIL.md 和 NEEDS-VALIDATION.md，并与最终记录一致。 “没有 confirmed”不是任务失败；没有证据却强行升级为 confirmed 才是严重问题。

初级用法：理解三种结论

confirmed 要有完整源码追踪和边界明确的观察结果。 needs_validation 要说清尚未解决的准确事实，不附严重性等级。 rejected 用来记录已被反证的候选，避免之后重复把同一误判当发现。

完整代码审计请求进入 full audit mode。 一般安全问题或聚焦的漏洞讨论默认使用 guidance mode，除非请求报告产物。 因此同一个 skill 被激活，并不保证每次都会生成全部报告文件。

未指定输出目录时，完整模式默认使用 ~/security-audit-skill/<repo-name>/run-<N>。 只有明确选中受版本控制忽略的目录时，流程才会写入目标仓库内部。 第一次使用推荐仓外输出，并人工确认宿主有相应文件权限。

高级玩法

1. Coverage-led hunting 按单元分配

先依据 ledger 把输入面、边界和组件划为可检查单元，再给隔离的 hunter 分工。 覆盖批评者应找未审到的路径，不是把别人的“看过”复制成自己的覆盖证据。 一个单元受阻时写出阻断原因，不让未完成工作消失在汇总报告中。

2. 独立反证与记录核对分开做

Phase 3 的新验证者尝试推翻候选漏洞。 Phase 5 再用新 Agent 核对最终源码断言，实质性替换还需要另一位独立验证者。 这是两层不同检查，不应让同一会话换个角色名就声称已完成独立性。 对检查结果有分歧时保留未解决事实，不按多数票制造确定结论。

3. 多次运行补覆盖，不机械累加

README 说明重复运行是 additive：结合旧 ledger 和 findings 定位空白。 先对照当前源码重验既有证据，再决定能否沿用，不能把旧 commit 的覆盖当现版本已经检查。 记录本轮新覆盖、重新验证与仍受阻部分，避免只统计累计发现数。 项目方提到重复运行能找出更多漏洞，本站未复现其召回效果。

4. 按目标选择专门攻击面文档

LLM 系统可从 AI-AND-LLM.md 梳理提示注入和工具边界。 Web 鉴权与协议目标参考 WEB-PROTOCOL-AND-AUTH.md，客户端看 CLIENT-SIDE.md。 原生代码则关注 MEMORY-SAFETY-AND-BINARY.md，不要拿 Web 清单覆盖所有内存安全问题。 这是组织调查的路径，不意味着每个模块都对你的目标适用或已经获得执行权限。

小技巧

1. 开始前先让 Agent 回显最终输出目录与授权范围，及早发现路径误解。
2. 每个候选保留源码位置、触发前提与反证结果，方便维护者复核。
3. 给并行任务设资源预算，避免多个测试进程耗尽主机资源。
4. 把 rejected 留在记录中，它是防止重复误报的依据，不是要隐藏的失败。
5. 报告派生自最终 records 和 ledger，不让文字报告另造未经验证的新结论。
6. 提交报告前检查密钥、内部主机名与可识别用户数据，必要时制作脱敏版。

常见踩坑

以下风险按官方要求推导，本站未安装或执行该技能。

1. 装完后期待 Cloudflare 自动扫描

现象：等待云端任务链接或扫描额度。 原因：这是编码 Agent 的 skill，不是托管扫描器账号。 解决：在合适宿主中加载，提供授权仓库与明确任务，单独准备隔离环境。

2. 用普通终端替代沙箱

现象：Agent 想在开发机直接运行目标测试。 原因：把“我会小心”误当作 OS 强制隔离。 解决：不满足断网、白名单环境、资源和写入限制就不运行，将线索标为待验证。

3. 报告没有全部产物

现象：得到建议但找不到 findings 或覆盖文件。 原因：安全提问可能进入 guidance mode，或输出目录与预想不同。 解决：明确请求 full audit 与报告产物，确认绝对目录，并读取宿主执行结果。

4. 一个 Agent 包办发现与验证

现象：同一会话自证某候选可靠。 原因：没有遵循新验证者尝试反证的分工。 解决：使用独立子 Agent，向其提供源码与必要证据，不只给原作者结论。

5. 给未验证线索标高危

现象：缺关键运行事实却写 confirmed 或附严重性。 原因：混淆源码可疑点与已成立的边界失效。 解决：保留 needs_validation 和准确未决事实；严重性必须建立在影响证据上。

常见问题 FAQ

Q1：没有并行子 Agent 能用吗？

A：可以阅读规则作为参考，但不满足官方完整审计流程的前置条件，不能声称已经完成该流程。

Q2：没有合适沙箱是否必须放弃所有阅读？

A：不必。可做授权源码分析；需要执行目标代码的部分保持待验证，不能绕过隔离要求。

Q3：Node.js 是用来启动扫描服务的吗？

A：README 指定它用于零依赖 findings 和 coverage-ledger 校验器，不表示存在一个 Node 托管扫描服务。

Q4：MIT 许可是否意味着全部使用零费用？

A：技能本身开源，但宿主、模型、并行任务与隔离资源可能收费，需分别预算。

Q5：空报告能证明没有安全问题吗？

A：不能。应查看覆盖面、受阻路径和证据范围；审查没有发现不等于目标不存在漏洞。

权限、平台与免责声明

不要把访问本机代码的权限扩展为对线上目标的测试授权。 Windows、macOS、Linux 的沙箱能力与宿主集成不同，不能只凭安装成功推定执行隔离满足要求。 安全源码与报告可能进入宿主模型，先核实其数据政策，并使用最小权限凭据。 报告应由有授权的维护者复核，不是完整渗透测试、合规认证或法律意见。 本文基于官方文档和公开资料整理，AI辅助生成，MagicNetWorld 尚未完成独立实测。

参考链接

核验日期：2026-11-03。安装、产物与安全约束以官方仓库当前说明为准。

• 官方仓库与 README
• 核心 Skill
• 验证与报告阶段
• 报告 schema
• Cloudflare 的 harness 背景