Cloudflare与OpenAI在其Managed Defense服务中测试名为Vulnerability Discovery and Remediation的早期访问功能，利用OpenAI Daybreak/GPT-5.6 Cyber对代码和流量进行侦察、漏洞验证并生成修复与临时WAF规则建议，但最终的验证、审批与部署仍由客户与Cloudflare负责。该方案将源代码证据与实时生产流量和安全信号结合以优先排序风险，旨在缩短从发现到缓解的时间，同时保留人类控制链以防止模型直接改动生产环境。
Cloudflare正在把人工智能辅助的漏洞研究，从“扫描代码”推进到“判断哪些问题正在被真实攻击，并立即降低暴露面”。OpenAI于2026年10月21日发布的客户案例显示，Cloudflare已通过其Managed Defense服务测试一项名为Vulnerability Discovery and Remediation的早期访问功能：OpenAI的Daybreak模型负责侦察、漏洞搜寻和验证，Cloudflare则把代码发现与生产流量、WAF规则和安全事件联系起来，再向客户提交修复建议。
这项服务的核心变化，不是让模型自动替企业打补丁，而是尝试缩短从发现漏洞到采取防御措施之间的时间。Cloudflare在官方博客中说，服务会针对客户授权检查的代码库寻找潜在弱点，并判断相关代码是否处于生产环境、对应路由是否活跃、是否出现可疑流量，以及现有的安全控制是否已经在发挥作用。
Cloudflare于2026年9月3日宣布这项服务进入早期访问阶段。当时公司称，服务通过OpenAI Daybreak Defense Network使用包括GPT-5.6 Cyber在内的模型，将代码分析、补丁生成与Cloudflare全球网络的实时安全信号结合起来。服务目前仅向部分Cloudflare Enterprise客户提供邀请式访问。
从漏洞清单转向真实风险排序
传统漏洞扫描器可以一次性报告数千个问题，但通常无法回答最紧迫的运营问题：受影响的代码是否真的在线？是否正在接收请求？攻击者是否已经在探测？企业现有的WAF或其他防护措施能否挡住这条攻击路径？
Cloudflare的方案试图把这些问题纳入同一条分析链。按照公司博客的描述，系统首先从Web Assets、WAF和Workers Observability收集流量及安全数据，识别活跃路由和“热点路径”，再把这些路径与客户授权的源代码对应起来。侦察代理负责建立请求路径与代码部分之间的映射，后续的猎手代理针对特定代码区域寻找漏洞，并在需要时调取网络上下文。
网络信号可以帮助提高优先级，却不能单独证明漏洞存在。Cloudflare表示，每一个发现仍必须由源代码证据支持；完成发现后，验证阶段还会检查补丁和缓解措施，并根据源代码风险与生产暴露情况形成初步排序。
对于获得授权的区域，系统可以提出针对具体方法、路径和请求特征的WAF规则，以便在代码修复完成前降低风险。它也可以生成供开发者审查的源代码补丁。但这些建议不是自动执行的修复命令。Cloudflare明确表示，客户要审查每一项结果，并自行决定是否测试或部署改变。
模型运行在OpenAI服务器，控制链条留在服务流程中
这项安排也暴露出企业使用AI进行安全分析时最敏感的问题：源代码、日志和请求元数据如何被处理，模型究竟拥有多大的工具权限，以及模型提出的修改是否会直接影响生产系统。
Cloudflare称，调查流程运行在Cloudflare一侧，模型提示会经由Workers和Cloudflare AI Gateway发送到OpenAI服务器；GPT-5.6 Cyber用于侦察、搜寻和验证，模型返回的结果再交给Cloudflare的流程继续处理。换言之，推理并不发生在Cloudflare边缘节点，模型也不能直接应用它提出的补丁或WAF规则。
公司还表示，每项调查只处理客户授权的代码与证据，相关内容在发送给模型前会经过必要的筛选和客户配置的脱敏控制。工具调用要受到访问政策约束并留下日志，补丁和规则建议必须通过模型之外的检查。对于边缘防护规则，Cloudflare会验证语法，并使用代表预期请求的合成测试样本进行测试，而不是直接在客户真实流量上试验。
这些机制体现了一个重要边界：AI可以在复杂代码中寻找线索，也可以帮助生成修复方案，但安全系统不能把最终权限交给模型本身。即使一项建议通过自动化检查，Cloudflare团队还会进行审核，客户也要在部署前作出决定。
AI加速防御，也可能加速攻击
Cloudflare和OpenAI推动这类服务的背景，是漏洞数量与攻击速度同时增加。Cloudflare在9月的新闻稿中援引国家漏洞数据库数据称，截至2026年9月，NVD已经记录60,475个漏洞，高于2025年全年48,185个的总数。这个数字来自公司新闻稿，反映的是漏洞记录规模，并不意味着所有漏洞都在野外被利用，也不代表所有漏洞具有相同的实际风险。
OpenAI在其Daybreak网络防御计划中把这种趋势描述为一场持续的防御循环：清点资产、发现问题、验证证据、分配责任、修复漏洞，并证明修复确实生效。Cloudflare的服务正是把这一思路嵌入网络边缘和企业代码库之间。
但同一类能力也可能降低攻击者处理复杂漏洞的门槛。AI能够协助分析失败的测试、调整利用路径和理解大型代码库，这意味着“漏洞很复杂、短期内难以利用”可能不再是足够稳固的风险判断。防御方如果只是产生更多报告，却没有更快完成验证、隔离、补丁部署和恢复演练，模型能力未必会转化成实际安全收益。
AIFlux此前报道的OpenAI称AI协助发现两项关键PHP漏洞也显示了类似趋势：AI辅助发现漏洞只是响应链的一部分，维护者、云服务商、安全厂商和下游运营者仍需要在公开前完成验证、准备防护和协调修复。
“人类审批”能否跟上自动化发现速度
Cloudflare这项服务目前仍处于邀请式早期访问阶段，公开材料没有给出独立评估的漏洞发现数量、补丁成功率，或与传统扫描工具相比的误报率。因此，关于它能否在大规模生产环境中稳定提高安全效率，现阶段仍主要是公司和合作方的产品主张，而不是经过公开第三方验证的结论。
更现实的考验在于，自动化发现速度可能远快于企业审核和部署速度。每一项补丁都需要理解业务影响、测试兼容性、确认权限范围，并在必要时安排回滚；一条WAF规则也可能误伤正常请求。若企业无法及时确认结果，AI生成的更多候选修复反而可能增加安全团队的审查负担。
因此，Cloudflare与OpenAI这次合作的意义，不只是把模型放进漏洞扫描器，而是尝试建立一条从源代码证据、实时攻击信号到临时边缘防护和最终代码修复的闭环。它能否真正形成“防御者优势”，最终取决于几个尚未完全回答的问题：模型是否能在不同代码库中保持低误报，客户授权的数据边界是否足够清晰，补丁验证能否覆盖复杂生产环境，以及人类审核是否能在攻击者利用窗口关闭前完成部署。
目前可以确认的是，Cloudflare的服务不会让AI直接接管企业安全控制。它把模型放在调查和建议环节，把验证、审批和部署保留在人类与既有安全流程手中。对于需要处理大量漏洞的企业来说，这或许是更容易被接受的路径；但它也意味着，AI发现问题之后，真正决定系统是否安全的，仍然是组织能否把建议转化为经过验证、持续运行的修复。
来源：