Cloudflare 用 Daybreak 把漏洞发现接到主动防御

Cloudflare 在 10 月 21 日放出的这篇案例，讲的是它怎么把 OpenAI 的模型（通过 Daybreak 访问）和 Codex 用进安全与研发。标题是「把漏洞发现与防御连接起来」，一句话说清了它想解决的老问题：安全团队手里有的是数据，缺的是处理数据的人手和时间。这篇把它的做法和数字拆开看。

把漏洞发现接到防御

这件事的核心不是「AI 发现了更多漏洞」，而是把「发现漏洞」和「保护应用」接成了闭环。传统做法里，发现了漏洞只是起点，从漏洞到修好中间隔着一堆人工。Cloudflare 用通过 Daybreak 访问的 OpenAI 模型去调查客户授权的代码、识别潜在漏洞、核实支持每项发现的证据，然后叠加 Cloudflare 独有的一层东西：实时流量数据和安全信号，给发现结果排优先级——这条受影响的路由还活跃吗？有没有收到可疑流量？现有防护是不是已经在护着它？发现的问题有了上下文，就不再是一串孤立的告警。

具体怎么做

流程分几步。模型先调查代码、识别漏洞并核实证据；Cloudflare 把源代码里的漏洞和生产环境的实际情况关联起来做优先级排序；然后服务准备修复方案——包括代码补丁，以及在合适的场景下准备自定义 WAF 规则，在开发者审阅修复的同时先把暴露风险降下来。Cloudflare 对提案跑自动化检查，团队在分享给客户前做人工审阅，最终改不改、改哪些，决定权在客户手里。这是 Managed Defense 旗下的一项抢先体验服务。开发侧，Codex 在整个工程组织推广，用于提升开发者的产出和代码质量。

这里最值得注意的一步是「关联」。漏洞本身到处都有，静态扫描器每天能报一堆，但哪些值得先修、哪些已经在被攻击、哪些有防护兜着，是要靠实时流量信号才能回答的。Cloudflare 把源代码问题和生产环境的真实状况拼在一起，等于给每一条告警都标上了「这条现在危险吗」的答案——这才是从「发现」到「防御」中间真正缺失的一环。

关键数字

开发侧的数字也很能说明问题：一个因为人手不足被搁置的产品重建项目，原来估计要约 10 倍的开发资源，结果一支 4 人团队用 Codex 三天完成、上线并测试，token 只花了 1100 美元。

这改变了什么

两个信号。一是分工变了——Cloudflare 营收总裁 Mark Anderson 的原话是：Daybreak 和 Codex 提供的自动化之美，在于让机器干苦活、让人在最重要的工程和安全决策上发挥判断力。二是流程变了——他不是把 AI 当成一个独立元素，而是「带着机器的思维构建技术」，把 AI 整合进构建流程本身。对安全团队，这意味着那批「有价值但没人手去处理」的数据，第一次有了被消化的可能，机器做苦活、人做判断的分工第一次在漏洞治理里落了地。

待观察

两点要盯。一是这是抢先体验服务，漏洞发现到主动防御的完整链路还没大规模跑起来，真实效果要看客户使用后的数据，而不是这篇案例里的个例。二是「通过 Daybreak 访问的 OpenAI 模型」这个说法比较克制——Daybreak 是访问渠道，没有点名具体模型，所以别把它理解成「某一个模型」的功劳。对开发者，更实在的启示是：漏洞治理的瓶颈正在从「能不能发现」转向「发现之后能不能自动化地处置」，谁先把这层接上，谁的安全响应就快一个身位。另一个看点是这会不会推高「AI 参与防御决策」的信任问题——代码补丁可以人工审，但自动生成的 WAF 规则一旦误伤正常流量，代价是实打实的，这需要配套的可回滚机制和灰度策略来兜底。