Cloudflare security-audit-skill: 用于编码代理的开源多阶段安全审计框架

TL;DR

Cloudflare 发布了一个开源的 "security-audit-skill"，为编码代理配备了一个六阶段、可独立验证的安全审计流水线，能够生成机器可读的调查结果和不可篡改的报告。该框架专为代码库的可重复、增量审计而设计，可通过 Skills CLI 进行安装。

该技能的功能 – 六个具体阶段

该技能通过确定性审计编排隔离的子代理，并以签署的报告结束。

侦察 (Reconnaissance) – 生成 architecture.md 和 coverage-ledger.json，描述信任边界、输入表面和先前的证据。
覆盖范围导向的搜寻 (Coverage-led hunting) – 从账本中分配搜寻者，记录每次检查，并使用评估者来发现未覆盖的漏洞。
候选验证 (Candidate validation) – 将每个唯一的候选漏洞发送给一个新的验证者，该验证者会尝试反驳它。
结构化输出 (Structured output) – 编写 findings.json，包含三个判定结果（confirmed、needs_validation、rejected），并根据 report-schema.json 验证该文件。
独立记录验证 (Independent record verification) – 新的代理重新验证最终的来源声明；任何实质性的替换都会触发另一次独立检查。
目标中立报告 (Target-neutral reporting) – 根据已验证的记录和覆盖范围账本导出 REPORT.md、FINDINGS-DETAIL.md 和 NEEDS-VALIDATION.md。

每个阶段都会运行一个零依赖验证器（validate-coverage-ledger.cjs 或 validate-findings.cjs），以确保在继续之前符合架构规范。

工作流程如何保证调查结果的可信度

明确的判定结果 – confirmed 包含完整的源代码追踪和有界限的观察结果；needs_validation 记录一个确切的未解决事实，且不包含严重性；rejected 标记一个被反驳的候选漏洞。
对抗性验证 – 发现漏洞的代理永远不会验证它，从而消除了自我确认偏差。
增量运行 – 后续审计会重用之前的账本和调查结果，仅针对未覆盖的缺口，并重新验证已更改的代码，而不会将过时的工作视为已覆盖。
独立验证 – 在第 4 阶段之后，一个新的代理会重新检查每一项声明；替换会触发另一轮验证，确保没有任何单个代理可以单方面宣布存在漏洞。

安装与使用（几分钟内完成）

# 通过 Skills CLI 全局（或按项目）安装该技能
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global   # 可选，用于用户级安装

在包含目标代码库的任何目录中运行审计：

security audit this codebase
# 或
find security vulnerabilities in ./src
# 或
do a security review, output to ~/audits/my-project

该技能会自动检测触发短语（例如 "security audit"、"find vulnerabilities"）并启动完整的六阶段工作流程。在全量审计模式下，除非指定了明确的目录，否则输出默认为 ~/security-audit-skill/<repo-name>/run-<N>。

安全执行所需的环境

编码代理 – 必须支持工具使用和并行子代理。
Node.js – 零依赖验证器所需。
操作系统强制沙箱 – 隔离构建、测试、浏览器、模糊测试器等，禁用外部网络，强制执行资源限制，并限制对指定临时路径的写入。如果没有沙箱，该技能会将线索标记为 needs_validation 而不是执行目标代码。

塑造审计的设计原则

仅确认已建立的边界故障 – 未解决的事实保留在 needs_validation 中。
严重性需要影响 – 可能性乘以现实世界的影响，而不是清单偏差。
纵深防御缺口属于加固说明 – 缺失的层级不会自动归类为漏洞。
重复运行可提高覆盖率 – Cloudflare 的内部测试表明，单次运行大约能发现多次运行总漏洞数的一半。

Hacker News 上的社区反应

"无耻的自我推销：如果有人觉得这需要太多的 token，我们分享了我们如何构建自己的内部审计技能的配方，以便它可以轻松地复制并针对不同环境进行调整" – gbrindisi

"我在一个中等规模的代码库中扔了 100 万个 token，结果什么也没得到。" – drchaim

"给使用 LLM 的安全专业人员的提示：明确将任务定义为安全研究的审计技能有时会触发顶级 OpenAI 和 Anthropic 模型的拒绝，因为它们会防范滥用。对我有效的方法是：针对漏洞类别（以及一般漏洞）使用单独的技能，而不使用安全框架，再加上另一个结合它们发现结果来识别安全漏洞的技能。" – wslh

"将 14 个完整的模式转储到提示词中简直是懒惰的设计。你浪费了 token，无缘无故地增加了延迟" – qsbuilder

这些评论突出了实际关注点：token 成本、模型拒绝处理，以及丰富的模式定义与提示词效率之间的权衡。

何时使用（以及何时不使用）该技能

理想情况 – 需要可重复、可审计的调查结果的大型代码库，并且可以配置沙箱执行环境。
不太理想的情况 – token 成本超过收益的小型项目，或者 LLM 提供商阻止安全相关提示词的环境。

如何获取帮助或贡献

有关 AI 驱动的安全工具的问题、反馈或合作，请发送电子邮件至 security-ai-research@cloudflare.com。该存储库采用 MIT 许可，允许不受限制的修改和重新分发。