Cloudflare 安全审计 Skill 将 AI 代码审查转变为对抗式工作流

Cloudflare 发布了一套包含六个阶段的 AI 代码审计工作流，但 Cloudflare 安全审计 Skill 并非只是让模型寻找漏洞的另一条提示词。它会分配不同代理来梳理代码、搜寻漏洞、质疑发现，并验证最终保留下来的证据。

这一区别至关重要，因为 AI 生成的安全报告往往包含看似合理、却没有有效攻击路径的论断。Cloudflare 的设计将每个拟议漏洞都视为需要由另一名代理尝试证伪的指控。它还会记录审计覆盖的范围，使遗漏的分析更加可见。

这一开源发布打包了 Cloudflare 在构建规模更大的内部漏洞工具链时形成的理念。公开 Skill 面向单个代码仓库和单次审计运行。相比之下，Cloudflare 的内部系统会跨仓库存储结果、追踪依赖关系，并管理数千项发现。

这也构成了该发布的核心张力。可复用的 Skill 降低了开展结构化 AI 代码审查的门槛，但它本身无法复现 Cloudflare 的内部基础设施。开发者获得的是更强的起点，而非安全工程师的自主替代品。

Cloudflare 安全审计 Skill 实际改变了什么

Cloudflare 正将 AI 安全审查从一场对话转变为具有明确覆盖范围和验证关卡、能够产出证据的流程。

公开的 审计 Skill 仓库 描述了一套为支持工具和隔离子代理的编码代理构建的工作流。它采用 MIT License 授权，可通过 Skills 命令行界面安装。

Cloudflare 安全审计 Skill 将审计划分为六个阶段。侦察阶段会梳理软件架构、信任边界、输入界面和可用证据。流程会将这份映射记录在架构文档及机器可读的覆盖范围台账中。

接下来是以覆盖范围为导向的搜寻。父代理会将明确的区域和攻击类别分配给隔离的搜寻代理。每个搜寻代理都会记录其检查内容，而非仅返回一份疑似问题清单。

这份台账十分重要，因为简短报告很容易制造虚假的安全感。某个代理可能检查了身份验证代码、没有发现问题，继而暗示整个应用看起来都很安全。覆盖范围记录则能显示，解析、部署配置、依赖处理或租户隔离是否获得了足够关注。

候选项验证会将每条不同线索交给新的验证代理。验证代理会通过检查其假设、源代码路径、受影响主体和安全结果，尝试否定拟议漏洞。搜寻代理不能批准自己的工作。

最终保留下来的发现随后进入结构化输出。该 Skill 将记录分为已确认发现、需要验证的问题和已驳回候选项。模式定义了必填字段，随附的 JavaScript 验证器则会对文件进行机械检查。

最后阶段会独立验证源代码论断，并生成不依赖特定目标的报告。对某项发现作出的实质性修改将触发新一轮验证。该设计旨在防止报告撰写者在总结时悄然强化一项证据薄弱的论断。

结果与普通 AI 代码安全审计在一个关键方面不同：交付物包含已检查界面、被驳回的想法、尚未解决的事实，以及经独立核验的发现。看起来干净的报告不再是唯一产物。

Cloudflare 还定义了严格的执行边界。构建、测试、模糊测试、浏览器和由目标控制的测试夹具，都需要在没有外部网络访问权限的操作系统沙箱内运行。若没有这些控制措施，工作流必须将线索保留为未经验证的状态，而非执行不受信任的代码。

这一限制使该发布不如一条命令式审计提示词方便，但也反映了真实的安全问题：待审查代码可能包含攻击审计环境本身的指令或构建行为。

Cloudflare 为何先构建 Skill，再打造全仓库工具链

公开 Skill 的价值在于它凝练了 Cloudflare 的审计方法，同时也揭示了单次代理会话为何会触及运营层面的上限。

Cloudflare 表示，该项目起步于一个面向单个仓库、约 450 行的安全 Skill。工程师不断改进其提示词，直至它能发现有价值的漏洞，随后将其中的场景和验证规则带入更大的系统。

该公司在其 漏洞工具链工程文章中详细介绍了这一演进过程。第一版使用三名研究代理进行侦察，为不同攻击类别配置独立搜寻代理，采用对抗式验证器、结构化发现和独立的源代码验证。

Cloudflare 在早期运行中识别出三项限制：长时间会话会耗尽模型上下文，中断执行会丢失进度，而单仓库审查会遗漏与使用该服务的其他服务之间的关系。

这些失败并不只是模型质量问题，而是状态管理问题。

模型可以推理当前上下文中的代码，但大型审计会产生许多并行假设。每个假设都包含文件、信任边界、前提、实验、反驳意见和状态变化。将这段历史压缩进对话摘要，可能会丢弃决定性细节。

Cloudflare 的应对方式是将状态外部化。其后续工具链将语言模型视为可替换的工作者，并将持久化审计信息保存在其上下文窗口之外。数据库会为每项任务存储运行、仓库和阶段信息。

这一区别解释了 Cloudflare 为何发布起点，而非将其包装成完整的内部系统。Skill 可以在编码环境中编码严谨的流程，但不能自动提供全局资产清单、持久化队列、依赖图或生产遥测数据。

Cloudflare 报告称，从第一个 Skill 发展到覆盖 128 个仓库的系统，大约用了六周。该内部系统可跨 Rust、Go、C、Lua、TypeScript、Python 和配置格式运行，无需按语言分别编排。

其更大的工作流将发现与验证分离。漏洞发现工具链负责映射和搜寻潜在弱点；另一套漏洞验证系统则负责去重、检查生产环境相关性，并管理修复工作。

Cloudflare 表示，它为这两个阶段使用不同的模型。这一选择降低了对单一模型重复推理模式的依赖，也让该公司能够更换供应商，而无需围绕特定模型重新设计安全流程。

这种模型中立的立场，对那些将基准测试表现包装为 AI 安全产品主要衡量标准的供应商构成了压力。Cloudflare 的观点是，编排、证据和独立驳回机制，决定了模型输出能否成为有价值的工程工作。

该公司并未声称这一 Skill 能重现其生产流水线。其自身指导意见称，团队应从侦察、搜寻和验证开始。只有在审计量带来实际问题后，跨仓库追踪和专用去重才会变得有用。

这样的顺序为小型团队提供了务实的切入点。他们可以先验证提示词和证据规则是否适用于自身代码，再围绕它们构建昂贵的基础设施。

这也避免公开发布变成误导性的产品演示。该仓库提供的是孕育 Cloudflare 系统的方法，而非如今已在其全体基础设施中运行的完整系统。

真正的对手是一次性 AI 代码审查

Cloudflare 漏洞工具链质疑这样一种假设：单个能力强大的模型能够审查一个仓库、识别真实缺陷，并可靠地评估自身结论。

一次性审查通常遵循熟悉的模式：开发者让编码代理访问代码仓库，并要求它寻找安全漏洞。代理读取选定文件、识别可疑模式，然后写出一份精致的报告。

这一过程可以产出有价值的线索，但也可能掩盖三种不同的失败。

首先，模型自行决定检查什么，却不保留其跳过内容的持久记录。其次，同一推理过程既生成又评估每项论断。第三，有说服力的语言会让不完整的证据显得像最终结论。

Cloudflare 的工作流分别针对每种失败展开应对。覆盖范围台账记录预定审计界面；独立搜寻代理检查有边界的单元；新的验证代理尝试证伪候选项，而非改善其表达方式。

这种对抗式拆分比单纯增加更多代理更重要。共享相同假设的十个代理，可能会生成同一误报的十种版本。Cloudflare 分配不同角色，并赋予验证代理驳回搜寻代理理论的权力。

该 Skill 还要求存在具体的边界失效。已确认问题必须涉及受影响主体、资源或安全结果。未遵循最佳实践并不会自动构成漏洞。

这一差异可过滤例如仅向已受信任管理员开放的无限制行为等发现。它也会驳回那些只描述缺少某项防御、却没有展示攻击者如何跨越实际边界的报告。

Cloudflare 的内部流程采用了更严格的证明要求。一项已确认发现必须包含针对原始代码库可复现的测试。该测试不得依赖由搜寻代理引入的源代码修改。

这一规则解决了一种尤其危险的失败模式。代理可能在实验过程中修改代码，然后针对修改后的版本演示利用方式。如果没有源代码状态控制，最终报告可能会将由代理制造的缺陷归因于应用程序。

机械验证又增加了一层保障。常规代码检查会确认被引用的文件、路径、补丁和测试是否存在，或能否被正确解析。语言模型不会自行决定其输出是否满足这些基本的结构要求。

Cloudflare 表示，单次 Skill 运行大约只发现了重复运行最终发现漏洞的一半。这是公司自行报告的观察结果，而非独立测量的召回率。

尽管如此，这一结果仍支持该发布的核心设计选择：即便每项报告的发现都有效，一次完成的运行也不能证明覆盖范围完整。

因此，严谨的 AI 代码安全审计需要两种不同的置信度陈述：一种涉及每项发现的有效性，另一种涉及审计搜寻发现的彻底程度。

Cloudflare 安全审计 Skill 将这两个问题都显式呈现出来。其已确认、未解决和已驳回的结论描述证据置信度；覆盖范围台账则描述搜寻过程。

传统静态分析在这一模型中仍然重要。确定性扫描器擅长已知模式、数据流规则和可重复检查。代理则可探索特定于应用程序的信任假设，或在陌生逻辑中组合多个弱点。

Cloudflare 的内部经验还对预设工具偏好提出警示。该公司表示，其搜寻代理在一个月的运行中没有调用集成的 Semgrep 路径。它们更倾向于阅读和执行代码，同时频繁请求缺失的环境或测试夹具。

这一观察并不意味着静态分析没有价值。它表明，安装一个工具并不能保证智能体会有效地使用它。团队必须在自身工作流中衡量工具的实际行为。

因此，竞争并非 AI 与传统扫描器之间的对决，而是无结构的模型输出与结合确定性检查、专项探索和对抗性验证的审计流程之间的较量。

结构化发现可减少噪声，但无法证明安全

此次发布最有价值之处在于拒绝将看似合理的模型输出视为已确认的证据，但这种严谨性无法衡量尚未发现的漏洞。

Cloudflare 表示，其内部发现工具生成了 20,799 个原始候选项。约有 12,057 个通过初步验证，随后进入更大的验证池。

在另一套工具的发现结果并入该系统后，中央池中共有 13,841 条记录。去重移除了 5,442 条，另有 1,154 条因属于错误仓库或低风险案例而被转移处理。Cloudflare 表示，最终为工程团队保留了 7,245 项可执行发现。

这些数字之所以有用，是因为它们展示了从生成到修复之间经历了多少筛选。它们不应被解读为检测准确率的独立基准。

Cloudflare 自行选择其仓库、模型、提示词、攻击类别和定义。已发布的数据描述的是其运营流程，并不能证明公开 skill 在无关代码库上的表现。

该公司明确避免宣称假阴性率。真实仓库不存在包含每个漏洞的完整标注集，因此无法直接计算召回率。反复运行仍持续发现 bug，说明覆盖并不完整，但不能说明剩余缺口有多大。

这种不确定性应当处于任何评估的核心位置。一份经过验证的报告可以证明若干发现真实存在，却不能证明被审计的代码是安全的。

公开 skill 试图通过三种结论传达这一差异。

已确认的发现包含完整的源代码追踪和有边界的观测结果。待验证记录会保留一个精确但尚未解决的问题，而不会赋予缺乏依据的严重等级。已拒绝记录则说明某个候选项为何不成立。

保留被拒绝的候选项具有实际价值。未来运行时，可以区分真正的新路径与先前已被证伪的思路。审查者还可以检查拒绝结论是否依赖于后来发生变化的事实。

不过，结构化输出也可能制造自身的确定性幻觉。一条有效的 JSON 记录未必意味着有效的安全结论。模式验证可以确认必填字段和可接受的值，却无法证明某项利用能跨越真实边界。

Cloudflare 通过重新验证源代码来应对这一限制。验证器会独立审查代码主张，实质性替换内容还会接受额外检查。然而，质量仍取决于模型行为、可用上下文以及威胁模型的正确性。

沙箱化带来了另一项落地挑战。该 skill 要求围绕由目标控制的构建和实验实施操作系统级控制。许多日常编码智能体环境并未提供具备明确资源和网络限制的隔离机制。

忽视这一要求的团队，可能会运行恶意依赖项、构建脚本或测试夹具。遵守该要求的团队，则必须将一些有希望的线索保留为未解决状态，直到获得安全环境。

提示注入带来相关风险。源文件、文档、问题文本和生成的制品中都可能包含针对智能体的指令。Cloudflare 后续的商业工作流表示，会将代码、日志和元数据视为证据，而非指令。

本地使用时也必须建立同样的边界。安全智能体绝不应将仓库内容视为有权暴露凭据、扩大网络访问范围或修改无关系统的授权依据。

NIST 的安全软件框架提供了一个有用的参考点。该框架将安全开发视为一组组织实践，涵盖准备、保护、生产和漏洞响应。

AI 审计 skill 仅覆盖这一生命周期的一部分。它可以帮助调查源代码并记录候选弱点，但无法确立安全设计、访问治理、依赖项来源、部署控制或事件准备能力。

出于同样的原因，人工审查仍然不可或缺。工程师理解预期行为、生产架构、业务影响和补偿性控制措施，而这些信息可能不会出现在仓库中。

因此，此次发布应当改变审查的形态，而不是移除审查者。安全团队可以减少筛选缺乏依据主张的时间，将更多精力投入测试证据、确定暴露优先级和批准修复。

Cloudflare 正在将代码发现与生产环境上下文关联起来

Cloudflare 的更大策略，是将源代码发现与流量和防御遥测结合起来；而独立的 skill 无法单独做到这一点。

源代码扫描器可以识别不安全的处理程序，却不知道该处理程序是否在生产环境运行。它可能不知道哪条路由可到达该代码、客户端使用频率如何，或现有控制措施是否阻止相关请求。

Cloudflare 的仅限受邀使用的 Vulnerability Discovery and Remediation 服务试图弥合这一差距。该公司于 2026 年 9 月 3 日宣布推出这项服务，作为 Cloudflare Managed Defense 的一部分。

根据其上下文感知修复公告，该服务将经授权的代码分析与 Web Assets、Web Application Firewall 数据及 Workers 可观测性连接起来。

该服务使用 OpenAI Daybreak 模型，包括 GPT-5.6 Cyber，用于侦察、搜寻和验证。Cloudflare 表示，提示词会通过 AI Gateway 传递至 OpenAI 的服务器。模型推理并不在 Cloudflare 的边缘网络上运行。

这一实现说明了为何开源 skill 和商业服务承担不同角色。该 skill 组织仓库级调查；该服务则增加了关于已部署路由、请求量、安全事件和既有控制措施的信息。

生产环境上下文可以改变优先级，而不会改变技术有效性。开发环境中一条无法访问路径上的真实漏洞，应与高频使用的公开端点上的同一缺陷得到不同对待。

Cloudflare 表示，当证据同时支持时，其流程可以提出代码补丁和范围严格限定的 WAF 规则。在工程师审查永久性代码修改期间，边缘规则可以降低暴露风险。

该服务不会让模型自行部署提案。工具调用会被记录，并依据访问策略进行评估。外部检查会测试补丁和规则，而客户决定是否实施变更。

这种方法使 Cloudflare 漏洞工具不再只是发现引擎。它成为暴露面管理系统的一部分，将源代码证据、运行时上下文、缓解措施和修复工作关联起来。

这一策略也解释了该公司为何强调目标中立的报告。同一审计方法可以检查不同语言和应用类型，而生产环境专属系统则提供优先级判断所需的上下文。

使用公开 skill 的大多数团队将缺乏同等的网络可见性。它们仍可通过将部署清单、路由图、归属记录和脱敏日志作为受控证据提供，来改进决策。

它们应保持来源清晰。源代码发现、部署断言和流量观察属于不同主张。将它们合并在同一段落中，不应抹去每项事实的来源。

这正是严谨知识管理的重要性所在。工程团队需要一份可检索记录，将架构决策、审计证据、被拒绝的假设和后续修复关联起来。一套持续维护的技术知识库可以让这些记录在一次智能体会话结束后仍可使用。

公开 skill 已通过持久化制品朝这一方向迈进。架构说明、覆盖记录、机器可读的发现结果和人工报告，为未来审查者提供了比聊天记录更持久的依据。

不过，仓库仍然是一幅不完整的图景。基础设施策略、密钥管理、授权配置、服务依赖关系和用户行为，都可能决定源代码层面的弱点是否会变得可被利用。

最可能从中受益的团队，会将该 skill 视为更广泛安全计划中的一个证据生成器。最可能遇到困难的团队，则会期待一次仓库扫描回答仓库本身并不包含的生产风险问题。

三个信号将显示此次发布是否重要

下一项考验在于，开发者能否在没有 Cloudflare 私有基础设施、数据和安全人员的情况下，复现 Cloudflare 的严谨方法。

第一个信号是公开审计制品的质量。有效的采用将产出包含精确可信边界、可复现证据、有意义的被拒绝候选项和诚实未解问题的报告。

安装数量上升可以表明兴趣，却不能证明有效性。更好的衡量标准是，独立团队是否发布了经维护者审查后仍成立的已确认发现。

此次发布的当前设计支持这种评估。其覆盖率和发现结果模式可创建可比较的制品，而验证器可在人工审查开始前捕捉格式错误的记录。

第二个信号是仓库在真实使用后如何演进。Cloudflare 的内部工具通过重复运行、缺失环境、浅层覆盖和被拒绝发现不断学习。公开 skill 将面对更广泛的语言、构建系统和智能体平台。

应关注攻击类别指南、沙箱要求、覆盖率建模和假阳性处理方式的变化。这些更新将揭示 Cloudflare 流程的哪些部分能够顺利迁移，哪些部分依赖内部系统。

已确认与待验证发现之间的区别尤其值得关注。如果外部用户经常将未解决线索提升为自信报告，工作流的保障措施就只会停留在纸面上。

第三个信号是其他安全平台是否采用类似的独立验证机制。AI 代码工具已经围绕速度、问题数量和修复协助展开竞争。Cloudflare 正将注意力转向证据谱系、拒绝率和覆盖率核算。

即使开发者从未安装这个特定软件包，这种变化也会扩大 Cloudflare 安全审计 skill 的整体影响。一个追问“谁验证了该发现”的市场，比奖励最大告警数量的市场更健康。

Cloudflare 的内部结果说明了这为何重要。数千个原始候选项在验证、去重和上下文判断过程中消失。生成更多候选项并不是稀缺能力；将其转化为可信赖的工作才是。

各组织内部也存在实用信号。安全负责人应跟踪有多少发现通过独立审查、重复运行中覆盖率增长了多少，以及有多少补丁通过回归测试。

他们还应记录审计成本和耗时。Cloudflare 表示，其内部完整扫描可能耗时数小时，其中最长一次运行超过 14 小时。公开 skill 可能消耗大量模型时间，因为搜寻器和验证器会检查不同区域。

这类成本对于敏感代码库或定期深度审查或许合理，但未必适合每一个拉取请求。对于需要快速反馈的场景，较小范围的检查、确定性规则和聚焦的威胁审查仍更为合适。

关键决策并非是否要用一个 agent skill 替代现有扫描器，而是要判断：由证据驱动的 agent 审计能在哪些方面补充现有控制措施遗漏的信息。

开发者可以从一个范围明确的代码库和清晰定义的信任边界开始。他们应在阅读最终报告前先检查覆盖台账，随后依据未经改动的源代码，对每一项已确认问题提出质疑和验证。

对于尚未解决的记录，应予以保留，而不是强行得出结论。测试应只在适当的沙箱内运行，修复决策则应始终由人工掌控。

如果这一流程能够产生可复现、并被维护者接受的发现，那么 Cloudflare 便发布了一种有意义的安全方法。若用户只是将其简化为又一个宽泛的提示词，那么它的六个阶段只会增加复杂性，而不会带来信任。

因此，Cloudflare 的安全审计 skill 向 AI 安全厂商和工程团队提出了一个具体挑战：不要再以模型能够描述多少弱点来衡量成功。应衡量哪些主张经得起对抗性审查，哪些领域实际上得到检查，以及哪些事实仍然未知。