needhelp
← 返回博客

GPT-6 Cyber 发布：读懂安全基准，把漏洞发现接进可验证的修复流程

作者 xingwangzhe
openaicybersecuritygpt-6security-research

OpenAI 于 2026 年 11 月 5 日发布 GPT-6 Cyber，首批通过 API 和 Codex 向部分 Daybreak Red 客户开放。安全研究能力上升之后，团队要面对的具体问题是：谁来验证发现，谁来审补丁，以及修复什么时候真正到达用户手里。

发布了什么，谁能用

系统卡将它描述为 GPT-6 Astra 的网络安全专门版本，面向授权漏洞发现、利用开发和 Web 渗透测试。访问有准入限制。读到发布新闻，不代表普通 API 账户已经能调用；本文也不会编造模型 ID 或把猜测的 SDK 调用写成教程。

48.5% 应该怎么读

ExploitGym 从 GPT-5.6 Cyber 的 32.1% 提升到 48.5%，增加的是 16.4 个百分点，相对增幅约 51.1%。这两个口径不能混用。围绕指定漏洞完成利用，与在陌生应用里发现未知缺陷，也属于不同任务。

官方无源码 Web 评测给出 40.3% 的漏洞召回率，Astra 为 32.0%。单看召回率，还不知道误报会给团队增加多少工作。采购或试用前，要追问目标分布、工具预算、重试次数、人工介入，以及每个最终被接受发现的成本；本站没有独立复现这些厂商评测。

Linux 和 Firefox：沿着证据往下看

Linux 研究报告把结果分为 2,308 个候选发现、1,724 个动态复现漏洞，以及 948 个可工作的本地提权利用。分阶段统计很有用：看起来可疑的代码、稳定触发的问题、确实跨越权限边界的证据，强度不同。本地提权需要先有本地执行条件，不能直接写成远程攻破机器。

该轮研究消耗 1,213,430 美元 API 额度，平均每个可工作的本地提权利用约 1,279 美元。这是一次研究运行的 API 成本口径，不能当作产品定价或完整人力成本。Firefox 安全公告则能继续查到组件、严重性、报告者和具体问题；公告日期为 10 月 27 日，早于模型发布，发现、披露、修复与发布也应分别记账。

让模型输出进入修复流程

下图是本文提出的工程流程，不是 OpenAI 官方架构。先固定仓库提交和环境，再让模型提出假设与候选补丁。把复现和回归交给独立执行器，才能避免同一个生成过程既写答案，又给自己的答案打分。

授权范围固定版本模型提出假设隔离环境复现候选补丁回归测试人工审查部署与验证

每个候选发现至少保留触发输入、相关日志、精确命令与补丁差异。同一个复现样例要在漏洞版本和修复版本各跑一次，再测试附近的正常行为。直接禁用某个功能也可能让崩溃消失，但用户的正常使用路径同时被破坏了。

一段可以直接运行的证据门禁

将下面代码保存为 evidence-gate.ts，运行 bun run evidence-gate.ts。它不访问网络，也不调用 GPT-6 Cyber，只检查本地证据记录：补丁前失败、补丁后成功、回归通过，并记录对应提交和环境。

type Finding = {
  id: string;
  commit: string;
  environment: string;
  before: number;
  after: number;
  regression: number;
  reviewer: string | null;
};


function readyForReview(f: Finding): boolean {
  return (
    /^[a-f0-9]{40}$/.test(f.commit) &&
    f.environment.trim().length > 0 &&
    f.before !== 0 &&
    f.after === 0 &&
    f.regression === 0
  );
}


const finding: Finding = {
  id: "LAB-001",
  commit: "a".repeat(40),
  environment: "isolated-vm / fixture-v1",
  before: 1,
  after: 0,
  regression: 0,
  reviewer: null,
};


if (!readyForReview(finding)) {
  throw new Error("Evidence incomplete");
}
console.log(
  JSON.stringify({
    id: finding.id,
    readyForReview: true,
    approved: finding.reviewer !== null,
  }),
);

示例输出包含 readyForReview: true 和 approved: false，可以进入审查不代表已经获批。退出码必须来自可信测试执行器，不能照抄模型文字。这段代码不能证明漏洞可利用、补丁正确或审查者身份；生产系统还需要身份认证、不可变证据和权限控制，示例中的虚构提交也必须换成实际测试版本。

任务边界要落实到执行层

官方范围遵守评测报告：不加部署提示词时为 99.93%，加入后为 100%。这是特定测试中观察到的行为，不是对未来所有工具调用的保证。系统卡给出 Critical 网络安全能力分类，隔离与可执行权限约束也就更需要认真设计。

目标授权、网络出口、凭证范围应由模型之外的系统控制。图中的隔离执行器要有执行预算和可丢弃状态。仓库文字与外部页面可能夹带攻击者指令，应作为待分析数据处理，不能因为读到一句话就自动扩大授权范围。

试点该看哪些结果

从自有仓库和测试环境开始，固定版本与预算，再对比现有人工审查流程。记录去重后被接受的发现、复现成功率、维护者审查时间、补丁接受率，以及修复实际部署所需时间。一百条重复告警可能比一个高质量发现消耗更多产能。

测试集要包含反例：无法到达的可疑代码、已经修复的旧问题、只遮住崩溃的补丁，以及指向未授权目标的报告。证据不足时，系统应该保留不确定性并停止推进。我的判断是，团队最该优化的是“可复现发现到上线修复”的时间，而不是生成报告的数量。

参考

本文使用 AI 辅助起草和翻译。官方事实、可运行示例与作者提出的工程建议已分别说明。

分享本页