代码安全审计（Cloudflare security-audit）

让 Agent 对一个代码库做结构化的安全审计：先摸清架构和信任边界，再分头找漏洞，每个疑点都交给另一个 Agent 去推翻，最后输出带源码证据的报告。底层用 Cloudflare 开源的 security-audit-skill（MIT 许可证）。它是 Cloudflare 内部漏洞发现系统的起点，原理见他们的文章 Build your own vulnerability harness。

这是防御性的审计：读源码，找出真正越过信任边界的问题，给出证据、安全的复现方法、优先级和最小修复。

触发

用户要对代码库做安全审计、找漏洞、渗透式审查，或者问某段代码的安全问题时使用。不需要完整审计的小问题（"这段代码有 SQL 注入吗"），它只做针对性分析，不会启动整套流程。

硬性规则

1. 只审自己的代码或有授权的代码。 审计对象必须是用户自己的项目，或者用户明确有权审查的项目。拿不准归属就先问。
2. 只读源码，不碰线上。 不探测已部署的服务、外部接口、共享基础设施和别人的数据，不对线上环境做可用性测试，不花付费 API 额度。决定性的事实在代码之外时，标成"待验证"，不要去线上试。
3. 没有沙箱就不运行目标代码。 需要构建、跑测试或运行目标里的程序时，必须在系统级沙箱里：禁外网、环境变量只留白名单、只能写指定的临时目录、限制 CPU 和内存。没有这样的沙箱，就把线索留在"待验证"，不执行。
4. 不把推测当漏洞。 没有完整的源码链路和可观察的结果，不算"已确认"。缺少某一层纵深防御，只算加固建议，不算漏洞。
5. 审计产物放仓库外。 默认输出到 ~/security-audit-skill/<仓库名>/run-<编号>。只有用户明确指定，并且确认该目录被版本控制忽略时，才放进仓库里。
6. 密钥不外泄。 报告和复现记录里不写真实的密钥、令牌和环境变量值，用假数据和假账号。
7. 漏洞细节谨慎对待。 报告只给项目负责人；发现的问题不要公开发布，也不要写成可直接利用的攻击代码。

安装

先检查：

ls ~/.claude/skills/security-audit 2>/dev/null && echo "已安装" || echo "未安装"

没装就用 Skills CLI 安装：

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

要装成用户级（所有项目都能用），加 --global。装之前先告诉用户这会把第三方技能装进他的电脑。

运行要求：支持工具调用和并行子 Agent 的编程 Agent；Node.js（用来跑校验脚本）；见上面第 3 条的沙箱。

两种模式

模式	什么时候	做什么
引导模式（默认）	安全问题、针对性审查、分析某个具体线索	只用相关部分，不建输出目录，不写文件
完整审计	用户明确要"审计这个代码库""全面安全审查"，或要报告文件	走完六个阶段，写出全部报告文件

拿不准是哪种，先问一句，再动手。

完整审计的六个阶段

1. 侦察：画出架构、信任边界和输入入口，建立覆盖清单。
2. 按覆盖清单找漏洞：给每个单元派独立的 Agent 去找，另有"挑错"的 Agent 找覆盖缺口。
3. 逐条验证：每个候选问题交给一个全新的 Agent，目标是推翻它。
4. 结构化输出：写出 findings.json，分三类：confirmed（已确认，有完整源码链路和可观察结果）、needs_validation（还差一个具体事实，不定严重程度）、rejected（已被推翻）。
5. 独立复核：新的 Agent 再核对一遍最终结论里的源码依据。
6. 出报告：生成 REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md。

审计深度分 quick（小项目或快速看一眼）、standard、deep 三档，也可以只审某几个目录或两个版本之间的改动。档位只改变广度，不降低证据标准。

常用请求

对这个代码库做安全审计，输出到 ~/audits/my-project

只审计 ./src/auth 目录，用 quick 档

这段代码有没有越权问题？只分析，不要建文件

多跑几遍

仓库的作者说，他们测试时单次运行大约只能找到多次运行总共发现漏洞的一半。同一个项目重复跑，会参考上一次的覆盖清单，补上没查到的地方，并对改过的代码重新验证。所以重要的项目建议多审几轮。

注意

• 会派出很多独立的子 Agent，耗时和 token 消耗会比较大，先用 quick 档试一遍。
• "已确认"的问题要自己再看一眼证据；"待验证"的不要当成漏洞。
• 它是辅助工具，不能替代专业的人工审计，上线前重要系统仍然要有人审。

输出格式

1. 先说审计范围、模式和档位，以及有没有跑完（没跑完要写原因）。
2. 按严重程度列出已确认的问题：位置、影响、证据、最小修复建议。
3. 单独列出待验证的线索，各缺哪个事实。
4. 说明覆盖了哪些部分、哪些没覆盖，不要暗示一次就查完了。
5. 给出报告文件的路径。