看到 Cloudflare 的 security-audit-skill，我最想弄清楚的是：把它接入日常安全工作，能多发现什么，又会增加多少复核工作？
对 DevSecOps 来说，AI 找出一段"看起来危险"的代码并不稀奇。真正费时间的是后面的判断：谁能触发它？现有鉴权是否已经阻断？影响了哪个租户？代码里的配置在生产是否生效？报告能否交给研发处理？
这个项目值得研究，因为它把这些问题写进了一套审计流程：先规划覆盖范围，再分工寻找漏洞，由新的 Agent 尝试推翻候选结论，最后生成有证据约束的结构化记录。
我的判断是：它适合作为源码安全审计的试点起点，尤其适合检查业务边界和跨组件调用关系。要接入生产流水线，还需要补齐执行隔离、成本控制和人工处置。
本文依据 2026 年 10 月 22 日读取的仓库快照，commit 为 c1c8a8c14710。这是源码与文档调研，没有用真实业务仓库验证检出率，也没有进行线上探测。
1. 先看清楚：仓库交付了什么
仓库的主要内容是 Markdown 审计指令、领域检查材料、JSON schema，以及两个 Node.js 校验器和对应测试。
其中，SKILL.md 规定工作模式、权限边界和总流程；RECONNAISSANCE.md 与 HUNTING.md 负责侦察、覆盖规划和漏洞寻找；VALIDATION-AND-REPORTING.md 负责候选复核与报告。领域材料进一步覆盖云部署、供应链、AI 应用、客户端、消息协议、内存安全等方向。
这里的 Skill，可以理解为供编程 Agent 读取的一套工作规程。实际的读文件、调用工具、启动子 Agent 和执行测试，仍由宿主 Agent 平台完成。
所以，安装这个仓库，并不等于获得一台已经部署好的安全扫描服务。完整审计需要支持工具调用与并行子 Agent 的模型和平台，需要 Node.js 运行校验器。只读检查源码可以先行；执行目标项目的构建、测试或其他代码时，必须具备符合规约的操作系统沙箱。
它也区分工作模式：回答安全问题、分析某条发现时，默认只使用相关指引；明确要求完整审计或报告产物，才启动全部六阶段流程。加载 Skill 本身不会自动授权完整审计。
这个区分也关系到如何理解 Cloudflare 的官方介绍。官方博客解释了这套 Skill 如何发展成覆盖多个仓库的漏洞发现系统，包括持久化编排、跨仓库分析和后续处置。开源仓库是单仓库起点，不能把企业内部系统的全部能力和运行数据直接算在它头上。 博客讲述的早期流程，与当前仓库也有差别；本文以当前源码中的六阶段流程为准。
2. 它怎样让一条发现走到报告里
当前完整审计分为六个阶段。
首先进行侦察：识别系统架构、外部输入、信任边界、源码可见的控制和缺失的部署信息，形成 architecture.md 与 coverage-ledger.json。
接着，主 Agent 按覆盖台账分配任务。Hunter 从明确的入口和边界出发寻找问题；覆盖审查 Agent 检查有没有漏掉入口、生命周期路径或攻击类别，必要时推动下一轮。
第三步，把每个去重后的候选交给没有参与发现的新 Agent。它需要重新读源码，尝试证明原结论不成立，并在安全条件允许时独立复现关键行为。
之后，主 Agent 生成 findings.json，运行校验器；再由新的 Agent 核对最终记录中的源码主张。最后才从记录和台账生成报告。
注意下图中间橙色的"尝试推翻"分支。它承担候选验证；底部的"记录复核"检查最终写入的数据。两处检查关注的对象不同，图中省略了侦察和覆盖规划。
默认 standard 模式保留两次独立复核。quick 模式会让候选验证 Agent 同时完成最终记录检查，但依然要求它没有参与原始发现。deep 模式进一步细分覆盖单元，并增加复查。
这里的"独立"主要指任务和上下文上的分离。项目没有要求每次必须使用不同模型。相同模型的多个 Agent 仍可能共享推理盲点，增加复核次数也不能构成正确性的保证。
3. 对 DevSecOps 最有用的三个设计
用覆盖台账回答"究竟查了哪里"
常见 AI 审计报告喜欢写"已检查鉴权、输入校验和配置"。但这句话无法说明：检查的是哪条路由、哪个租户边界、哪一种部署方式。
这个项目按"入口 × 信任边界 × 子系统 × 攻击类别"组织覆盖单元；必要时加入生命周期维度。每个单元保留稳定身份、查看过的路径、检查记录、负责 Agent、候选指纹和未解决问题。
例如，一个导出接口可以形成这样的审计任务：从导出请求入口，检查普通用户到租户数据的授权边界，沿报表子系统追踪访问控制。
它和"把整个仓库交给模型看看"相比，最大的差别是：任务可以追踪，遗漏可以补查，下一轮可以知道上次停在哪里。
台账也有自己的边界。covered 表示在这个单元上留下了符合规约的检查证据，不能读作"已证明不存在漏洞"。如果侦察阶段遗漏了某个入口，后面的台账仍可能不完整。
项目要求读取兼容的历史台账和 findings，并对照当前源码决定是否复查。历史 needs_validation、受阻、延期以及源码变化的单元，都不能直接当作已经覆盖。这个设计适合持续审计，但也意味着维护台账本身需要成本。
把"证据不完整"保留为独立结果
findings.json 区分三种结论：
confirmed：有完整源码路径，并有受控本地执行证据和明确的观测结果。needs_validation：已有源码支撑，但某个明确事实仍未解决。rejected：候选被源码、已有控制或验证结果推翻。
只有 confirmed 才有严重程度。needs_validation 需要写明阻塞事实和验证计划，不能靠猜测补出 High 或 Critical。
这个约束对云安全尤其实际。仓库里出现 Ingress 或 IAM 配置，并不自动证明线上入口可达、某个身份正在使用这份策略，或某个 overlay 没有改变最终配置。项目的云部署材料明确要求区分源码配置与实际挂载、网络和运行时事实。
还有一个容易忽略的区别：尚未经过独立验证的候选，不应为了凑齐报告而直接塞进 needs_validation。 如果预算不足以完成候选验证，当前规约要求在台账中保留未解决候选，并把整次运行标记为 incomplete。
让机器检查记录，让 Agent 检查证据
两个校验器分别检查 findings 和覆盖台账。除了字段格式，代码还检查状态相关约束，例如不同 verdict 可以出现哪些字段，以及覆盖记录的拥有者和证据是否符合规则。
但校验器不会理解业务授权，也不会证明某一行源码真的导致跨租户访问。
因此，应该分开看三件事：JSON 通过校验，表示记录满足机器检查的契约；独立 Agent 复核，表示又检查了一次证据和推理；人工确认，负责判断业务语义、部署条件和修复优先级。三者各有作用。
4. 用一个导出接口，理解它会怎样审计
下面是解释方法的虚构例子，不是仓库发现的漏洞，也不是实测结果。
假设一个多租户服务允许用户创建导出任务。API 校验用户身份后，把 tenant_id 和 report_id 写入队列；后台 Worker 根据这两个字段读取数据并生成文件。
单看 API 有鉴权，可能会认为接口安全。真正要追踪的是：请求里的对象标识属于谁？消息里的租户标识从哪里来？Worker 查询是否同时约束租户和对象？
沿下图蓝色路径往下看，橙色虚线表示业务必须守住的租户边界。检查重点落在最后一次读取数据前的授权约束，而不只在入口有没有登录。
如果 API 已经把报表绑定到当前租户，消息由服务端构造且不能被低权限调用者替换，那么"Worker 没有重复某项检查"未必构成漏洞。候选验证 Agent 应主动寻找这些阻断条件。
如果源码显示调用者可以控制对象选择，并且隔离的双租户测试证明，租户 A 的身份读到了租户 B 的虚拟记录，才有支持确认的结果。测试应止于最小越权效果。
如果关键前提是"某个外部主体是否有权向生产队列写消息"，而源码和本地环境都无法确定，那么应明确列出这个前提，交给负责人核对权限事实。
这正是我认为它适合 DevSecOps 的地方：把入口、消息、后台身份和数据访问连起来，再判断哪一道控制真正生效。
5. 哪些任务值得先试，哪些任务继续用现有工具
我会优先选择三个方向。
第一，多租户与后台任务。 查找 HTTP、队列、Worker、缓存和导出之间丢失的授权上下文。它需要理解跨函数、跨组件的关系，很适合评估 Agent 的源码推理价值。
第二，CI/CD 与发布链。 仓库的供应链材料要求沿触发事件、checkout 的源码版本、工作流身份、缓存和产物追踪信任变化。重点是低信任输入是否能影响高权限执行或发布结果。出现宽权限本身，还不足以证明一条可达攻击路径。
第三，云配置与应用权限的衔接。 比如调用者控制资源标识，应用再用工作负载身份执行操作；或者某条部署路径与其他路径采用不同的安全策略。源码能确定的先确定，实际云账号和运行时状态交给负责人补证。
这些是基于材料覆盖范围给出的试点建议，不代表已经证明它在这些方向优于其他工具。
现有工具仍有明确价值。依赖漏洞清单、已知危险 API、泄露凭据和 IaC 规则，继续交给相应的 SCA、SAST、Secret Scanning 和 IaC 扫描。Agent 可以帮助追踪上下文和复核可达性，不能因此省掉确定性检查。
我也不建议一开始就在每个 PR 上运行完整审计。侦察、寻找、覆盖补查和独立验证都会消耗调用次数。先做定期专项审计；低延迟 PR 检查则保留现有规则，并尝试范围明确的增量分析。范围分析必须包含变更所影响的调用者和控制，不能只看 diff 的几行代码。
6. 一次可控试点怎样开始
项目 README 给出的安装方式是：
bash
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit这是官方使用示例，本文没有执行安装。企业试点应先审阅并固定版本，在支持所需能力的隔离环境中运行。安装命令本身也不提供执行沙箱。
选一个团队熟悉、可离线检查的仓库，固定 commit，给它一个具体问题，比"审计所有东西"更容易评价。可以使用下面的请求模板，把占位符换成实际路径：
text
对 <repo> 的导出任务做一次源码安全审计，输出完整审计产物。
使用 quick profile，范围包含 API、队列生产者、Worker 和授权函数。
目标是检查跨租户读取。把相关配置纳入范围，明确列出范围外路径。
输出到仓库外的 <audit-output>，不要修改目标源码。
预算最多 12 次子 Agent 调用，请先检查能否满足必需阶段。
只使用本地源码、已有依赖和虚拟数据。
目标代码仅在满足 Skill 全部执行控制的 OS 沙箱中运行。
缺少执行控制时保留具体阻塞，不访问线上或共享服务。12 次是试点预算示例，不是官方推荐，也不保证足够。当前规约在启动侦察前就要求预留侦察、覆盖审查和验证资源；如果预算不能满足最低要求，应缩小范围或调整预算。
准备环境时，要把两条通道分清楚：Agent 调用模型需要经过批准的数据通道；被审计项目的构建、测试和其他目标控制进程则应禁止外网，使用清理后按白名单注入的环境、只读源码和工具链、独立 scratch 目录，以及资源和时间限制。
这些控制需要宿主环境实际实现。提示词写了"只读""禁止联网"，不能代替操作系统的强制限制。 仓库主要提供规约和检查材料，没有附带一套满足所有要求的通用沙箱执行服务。模型调用涉及的源码外发、保留策略和访问权限，也要符合组织已有要求。
拿到结果后，优先查看：
run-metadata.json：源码版本、范围、预算和运行是否完整。coverage-ledger.json：查过哪些路径，哪些被阻塞、延期或排除。findings.json：每条结论的路径、条件、证据与判定。REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md：分别供总览、修复和补证使用。
试点阶段先让安全工程师逐条复核，再决定是否创建工单。我会记录人工确认的新增问题、误报与重复、每条候选的复核时间、整次运行的时间和成本，以及实际补齐了多少覆盖缺口。候选数量增加，只有在带来可处理的问题时才有价值。
7. 我会把它放在哪里
security-audit-skill 最值得借鉴的，是它对审计结论的约束：明确入口与边界，保存可复查的证据，把未知事实留在未知状态，并允许一次运行坦白地结束为不完整。
对 DevSecOps，我会先把它放在高价值业务边界的专项审计中，与现有扫描结果并行比较。跨租户导出、特权工作流、工作负载身份，都是可以提出明确问题、也能设计小规模验证的起点。
等团队确认它能稳定贡献新问题，并且复核和修复负担可控，再逐步增加覆盖范围。是否值得长期运行，应由这些试点记录决定。