自动漏洞修补流水线怎么证明自己有效：把发现、验证与补丁生成拆开

单看“找到 948 个本地提权漏洞”，不足以证明一条自动修补流水线有效。有效性要落在可判定的证据链上：同一个输入能稳定触发提权，打上补丁后同一路径不再成立，且没有引入新的失败。据 OpenAI 2026 年 11 月 4 日发布的一篇文章的摘要，其自主流水线在 Linux 内核中发现、验证并为 948 个本地提权（local privilege escalation，LPE）漏洞生成了补丁（来源）。本次材料只有摘要，验证手段、统计口径与补丁去向均待核实；下文关于“验证与生成分工”的讨论属于工程推断，不是对该流水线内部实现的转述。

摘要的支持范围#

摘要给出的信息可以归为四点：存在一条自主流水线；它覆盖发现、验证、补丁生成三个环节；对象是 Linux 内核的本地提权漏洞；数量为 948。它没有说明误报率、用了什么验证手段、统计时间窗、涉及哪些内核版本、补丁是否被上游接受、是否有人工复核。这些不是“发布方没讲”，而是本次材料未提供，需要回到原文核实。

三个环节回答的是不同问题#

生成环节的目标是产出看起来合理的改动，验证环节需要的是否证能力：在受控环境里重复地把同一候选推翻或确认。两者由同一组件兼任时，最容易出现的偏差是用“改完之后问题不再出现”替代“问题本来确实存在”。因此验证器的输出应当是机器可读的判定，而不是一段说明性文字。

一条最小证据链#

1. 固定环境：记录内核版本、编译配置与架构，三者缺一，跨批次数字就无法比较。
2. 复现：以非特权用户执行触发路径，观察是否获得 root 权限。
3. 对照：在打了补丁的同一环境重跑同一路径，期望提权失败。
4. 回归：同一内核跑既有测试集，确认没有新增失败。

# 未执行的示例：仅示意验证器的输入/输出契约
# 适用环境待核实：需与目标内核版本、架构、config 一致
# 占位路径仅作演示，不对应任何真实文件

./repro.sh --kernel ./vmlinuz.target --config ./config.target
# 期望：非特权用户运行后获得 root，退出码 0
# 实际结果：未测试

./repro.sh --kernel ./vmlinuz.patched --config ./config.target
# 期望：同上，但提权失败，退出码非 0
# 实际结果：未测试

这条链条的每一步都能被第三方重做，才算“证明有效”；任何一步退化成口头描述，结论就只剩建议的强度。

边界条件#

• 数量不等于质量。948 的统计口径待核实，包括时间窗、版本范围、是否按根因去重、严重性分布。同一根因的多个入口会把数字抬高，却不代表覆盖面同比扩大。
• 生成补丁不等于修复落地。内核补丁还要经过评审、代码风格与稳定分支回合，这些在流水线之外。
• 验证成本高。内核级候选需要可启动环境，每条都要在隔离的虚拟机或沙箱里跑，避免验证器本身成为风险面；崩溃是常态，不是异常。
• 候选来源可替换。验证器对人工审计、模糊测试、静态扫描的候选同样适用，这也是它比生成器更值得先投入的原因。

对自建流水线的取舍#

如果目标是对使用者说“修好了”，先把验证器做扎实：它决定哪些候选值得生成补丁，也决定对外能说什么。只有生成器而没有验证器时，产出的是待审阅的修改建议；加上验证器，才变成有证据支撑的结论。发现环节可以宽召回，验证环节必须严格否证，生成环节则在验证器划定的边界内改动。