AI 找漏洞、人签字：拆解 Cloudflare 用 OpenAI Daybreak 做的处置流水线

2026 年 10 月 21 日，OpenAI 发布了一篇关于 Cloudflare 的案例文章，讲的是把模型放进安全流程里的具体做法。按这篇文章的描述，Cloudflare 通过 Daybreak 访问 OpenAI 的模型，把这些模型与自家全球网络的实时流量数据和安全信号结合起来，用在托管防御（Managed Defense）下的漏洞发现与修复（Vulnerability Discovery and Remediation）早期访问服务里：模型去读代码、评估潜在漏洞，Cloudflare 再叠加实时流量、安全信号与验证结果，对发现做优先级排序，并准备候选的缓解措施与补丁，供客户审阅。同一份材料还给了几个数字：Q1 2026 平均每天拦截 2340 亿次网络威胁；开发资源减少 10 倍；3 天用 Codex 重建一个产品；重建的 token 花费是 1100 美元。这篇文章不复述新闻，而是拆两件事：这些数字到底证明了什么，以及一个五个人团队能从中抄走什么。

模型负责提方案，签字的人仍然是工程师

一、这份材料到底说了什么

先把事实摆清楚。Cloudflare 代理着全球大约 20% 的网络流量，这是它的独特性所在：它不只有代码，还有请求。所以它的漏洞处置服务不是单纯「模型读代码找 bug」，而是模型输出候选发现，网络侧的实时流量与安全信号负责判断「这个代码路径到底被不被真实请求碰到」，然后由验证环节把噪声过滤掉，最后产出的不是一段文字报告，而是「候选缓解措施与补丁」，明确标注交给客户审阅。另一条线是 Codex 在 Cloudflare 工程组织内的使用，用途是提高产出与代码质量。文章引用了 Cloudflare 营收总裁 Mark Anderson 的一句话，大意是：Daybreak 和 Codex 带来的自动化之美，在于可以把苦活交给机器，让人把判断力用在对重要的工程与安全决策上。这句话其实是整篇材料最该被记住的部分——不是机器替代人，而是机器把人的判断力挤到了更少、更关键的节点上。

# 1) Normalize every scanner into one schema before any model sees it.
#    Mixed formats are why triage queues rot.
import json, hashlib

def normalize(finding: dict) -> dict:
    return {
        "id": hashlib.sha1(
            (finding["rule"] + finding["path"] + str(finding["line"])).encode()
        ).hexdigest()[:12],
        "rule": finding["rule"],
        "path": finding["path"],
        "line": finding["line"],
        "severity": finding.get("severity", "unknown"),
        "reachable_from": finding.get("entrypoint"),   # the field that changes priority
        "raw": finding,
    }

rows = [normalize(f) for f in json.load(open("findings.json"))]
rows.sort(key=lambda r: (r["severity"] != "high", r["reachable_from"] is None))
print(len(rows), "findings,", len({r["id"] for r in rows}), "unique")

二、那几个数字能说明什么，不能说明什么

2340 亿次、10 倍、3 天、1100 美元，四个数字放在一起很有冲击力，但它们的性质不同，必须分开看。2340 亿次是网络侧的规模数字，衡量的是存量防护能力，跟模型没关系。10 倍开发资源减少、3 天重建一个产品、1100 美元 token 花费，这三个是同一个案例的三个侧面，属于单一案例的轶事，不是基准：它没有告诉你重建前的基线是什么、这个产品的复杂度是多少、1100 美元之外的人力成本是多少、重写之后维护成本有没有上升。最容易被误用的就是 1100 美元这个数字——token 花费不等于总成本，它不含工程师读代码、写验收测试、处理回归的时间。正确的用法是把它当成一个下界：如果连 1100 美元的 token 就能跑完三个月的重建，那这件事在成本结构上确实变了；但要不要做，取决于你的验收成本，而不是生成成本。

# 2) A finding without a reproduction is a hypothesis, not a bug.
#    Gate one: must be able to make the test fail on purpose.
import subprocess, sys

def reproduces(poc_path: str) -> bool:
    r = subprocess.run([sys.executable, "-m", "pytest", poc_path, "-q"],
                       capture_output=True, text=True)
    # A valid PoC FAILS on the current code. If it passes, you have
    # either the wrong target or a finding you cannot trust.
    return r.returncode != 0

def keep_only_reproducible(poc_dir: str, findings: list) -> list:
    kept = []
    for f in findings:
        poc = poc_dir + "/" + f["id"] + "_test.py"
        if reproduces(poc):
            kept.append(f)
        else:
            print("dropped (no reproduction):", f["id"], f["rule"])
    return kept

三、把「AI 提方案、人签字」做成四道闸

这套东西能被小团队复用的部分，不是模型，是闸门。第一道是归一化：把不同扫描器的输出塞进同一个 schema，尤其是那个决定优先级的字段——这个发现能不能从某个真实入口触达。没有这个字段，你的队列就是按严重度排序的噪声。第二道是复现：一个没有复现脚本的发现只是假设，不是 bug。判断标准很硬：复现脚本在当前代码上必须失败，否则说明你找错了目标，或者这个发现根本不可信。第三道是补丁提案走分支、不走主干：模型提的补丁机械地 apply 到一个分支上，人工审的是 diff 和推理，不是它的措辞；同时检查改动范围是否越界，动了依赖锁文件或 vendor 目录的一律打回。第四道是验证：补丁之后复现脚本必须通过，全套测试必须通过，两条都满足才算修好。这四道闸加起来，就是把「模型可能出错」这件事，从风险变成了流程里的一个已知环节。

# 3) Patch proposals land as branches, never as direct commits.
#    Gate two: a human reviews the diff and the reasoning, not the prose.
git checkout -b "fix/" + FINDING_ID
git apply proposed.patch            # the model's proposal, mechanically applied

git diff --stat
git diff -- . ":(exclude)*.lock" ":(exclude)vendor/*"    # the part a reviewer reads

# Reject the proposal if it touches anything outside the finding's scope:
git diff --name-only | grep -vE "^(src/|lib/)" && exit 1

# Commit with provenance so the review trail survives audit:
git commit -am "fix: " + RULE + " in " + PATH + " (proposed by model, reviewed by " + REVIEWER + ")"
gh pr create --fill --reviewer "$REVIEWER" --label "ai-assisted,needs-human-signoff"

四、代码：四道闸各一段

第一段是归一化：用规则、路径和行号做哈希作为发现 ID，把「是否可从入口触达」单独拎出来做排序键，最后打印总数与去重后的数量——去重率本身就是一个健康指标，如果扫描器之间重复率极高，说明你在为同一件事付两次审查成本。第二段是复现闸：跑 PoC，返回码非零才算通过。第三段是补丁闸：开分支、机械 apply、限制可改动路径、用带溯源信息的提交信息记录「模型提出、人工复审」。第四段是验证闸：跑全量测试，再单独跑一次 PoC，并断言它现在通过了——注意方向，修复前必须失败、修复后必须通过，两个方向都要，缺一个就不算证明。这四段代码都不长，但它们把流程从「相信模型」变成了「相信证据」。

# 4) Gate three: verify the fix, and prove you did not break the neighborhood.
set -e
pytest tests/ -q                          # full suite, not just the PoC
pytest $POC --deselect none -q 2>/dev/null || true
python - <<'PY'
import subprocess, sys
r = subprocess.run(["pytest", "tests/security/" + POC_ID, "-q"])
# After the patch, the PoC MUST pass (the bug is gone). Before the patch,
# it must fail. Both directions are required, or the "fix" is unproven.
print("poc_status:", "fixed" if r.returncode == 0 else "STILL BROKEN")
sys.exit(0 if r.returncode == 0 else 1)
PY

# Gate four: measure, because the next budget conversation needs numbers.
echo "time_to_fix_minutes=" $SECONDS

五、用这类服务前该问的五个问题

如果有一天你要用类似的商业服务（而不只是自己搭），有五个问题必须问清楚，答案决定你能不能把它放进生产环境。第一，代码会离开你的边界吗？如果会，传到哪、用什么密钥加密、密钥谁持有——如果只有厂商持有，你就无法独立核实内容与删除。第二，模型看到的是全量源码还是片段？这决定了泄露面。第三，发现怎么排序？如果它只给严重度不给「可达性」，你的团队仍然要重做一遍分诊。第四，谁能改动代码？提案和提交之间的权限边界必须清晰，模型不能直接推。第五，审计链长什么样？每一次模型参与、每一次人工签字、每一次回滚，都要能回答「谁在什么时候基于什么证据批准了它」。这五个问题没有标准答案，但一个都答不出来的服务，不适合放进你的补丁流水线。

# 5) Track cost per finding, not cost per month. Vague spend hides waste.
import json
from statistics import median

rows = json.load(open("remediation_log.json"))   # one row per finding
per_finding = [r["tokens_in"] + r["tokens_out"] for r in rows]
human_min = [r["review_minutes"] + r["verify_minutes"] for r in rows]

print("findings:", len(rows))
print("median model tokens per finding:", median(per_finding))
print("median human minutes per finding:", median(human_min))
print("accepted rate:", round(sum(r["merged"] for r in rows) / len(rows), 2))

# The number that decides whether this stays: accepted rate. If models
# propose ten patches and two merge, you did not save 10x, you added review.

六、小团队的现实版本

你可能没有 20% 的网络流量可以拿来当信号，但你仍然能拿到 80% 的收益，靠的是把三件事机械化。第一，把复现做成强制：任何人（包括模型）提的修复，必须先有一个能失败的测试。这一条能过滤掉大部分无效工作，成本只是一点纪律。第二，把范围检查做成 CI 规则：补丁不许碰依赖锁文件、不许碰 vendor、不许改测试断言——第三条尤其重要，因为「改测试让测试通过」是模型最容易的作弊路径。第三，把成本记账做成习惯：按发现记录模型 token 与人工分钟，定期看两个数——每个发现的模型开销，以及接受率。接受率低于三成的时候，说明你省下的不是时间，是把工作量从写代码挪到了审代码，这时候该调整的是提示与闸门，而不是加大模型用量。