Cloudflare 把漏洞发现和修补接成一条链

安全团队手里从来不缺告警，缺的是「今天先修哪三个」的答案。

一、发生了什么

10 月 21 日，OpenAI 官网挂出一篇 Cloudflare 的客户案例。内容是 Cloudflare 推出了一项早期访问服务，名字直译过来叫「漏洞发现与修复」，挂在它的托管防御产品线下，模型能力通过 Daybreak 接入。

流程分几段：先让模型读客户授权的代码，找出可疑点并给出证据；再叠加 Cloudflare 自己的实时流量和安全信号，判断受影响的路由是否真的在跑、有没有可疑请求打过来、现有防护是否已经挡住；然后排出优先级，生成建议补丁，必要时附一条临时 WAF 规则；最后跑自动化检查，由人复核，交客户自己决定改不改。

文章里的数字都是 Cloudflare 一侧给的：其网络在 2026 年第一季度平均每天拦截约 2340 亿次威胁，承载全球约两成网络流量；工程侧用 Codex 重建一款产品只花了 4 名开发者、3 天、1100 美元 token，公司三分之一的员工是软件开发者，且据营收总裁 Mark Anderson 说这些人 100% 在用 Codex。

这些是厂商口径，没有第三方评测，也没给测算方法。

二、跟你有什么关系

安全负责人。 这类服务的价值不在「多扫出几个洞」，在于它能拿到流量侧信号。同一份代码扫描结果，配上「这条路由昨天有 40 万次异常请求」，优先级排序的质量完全不同。

写业务代码的人。 补丁由机器起草、人来审，这个分工是对的。但审的人如果看不懂 diff，等于把风险从「没人修」换成「乱修」。

采购和预算。 早期访问意味着功能和定价都还会变。别按现在的口径做三年预算。

三、怎么评估这类服务

1. 问清楚发现之后谁举证。 每个漏洞要能给出证据：哪一行、什么输入、走哪条路径。只给结论的扫描器，误报会吃掉团队全部时间。
2. 要 diff，不要报告。 评估时让对方给三个真实仓库的补丁样例，看改动是否最小、是否符合你们的代码风格。这一步比看 demo 有用。
3. 问排序依据的权重。 是代码严重度、还是流量暴露面、还是资产标签？权重不透明，排序就没法复核。
4. 临时缓解要问有效期。 WAF 规则是止血带，不是缝合。要问它什么时候撤、撤之前必须完成什么、谁来盯。
5. 先影子跑一条业务线。 拿到发现清单但不改代码，和团队自己扫出来的结果比对。重合度高说明它没带来新信息，重合度低要抽样验证真假。

四、三个别信的说法

「AI 能自动修漏洞。」 文中的流程是生成建议、自动检查、人工复核、客户决定。四道关口都在人这边。把它理解成「自动修复」会在第一次误改后付出代价。

「4 个人 3 天省了 10 倍人力，所以安全也能这么算。」 那是重建一款内部产品的数字，而且是单方估算。安全工作的瓶颈常在评审、发布窗口和跨团队协调，不在敲代码的速度。

「堵上 WAF 就等于修好了。」 临时规则降低暴露面，根因还在代码里。反过来也成立：只改代码不撤规则，会留下一条没人维护的长期例外。

五、一句话结论

漏洞发现正在变成便宜的部分，真正值钱的是「哪条路由正在被打」这个信号和一条能过审的补丁。

信息来源

• Cloudflare links vulnerability discovery to defense with OpenAI - OpenAI，2026 年 10 月 21 日（厂商客户案例）

功能与价格以官方公告为准。本文写于 2026 年 10 月 22 日。