用 GPT-6 Cyber 做安全测试，范围应当划到哪里？

维护者收到一份浏览器缺陷报告。在让代理复现之前，团队需要准备测试构建版本，明确可访问的系统清单，并准备记录用于修复的改动。发现一个疑似弱点，只是这项工作的起点。

OpenAI 在 11 月 5 日介绍了 GPT-6 Cyber，并称 API 和 Codex 的初始访问仅向部分获批的 Daybreak Red 客户开放。公司称，模型经过训练，可用于漏洞研究，并遵守授权测试的范围。随公告发布的结果，加上 Mozilla 对 Firefox 已发布修复的记录，让人能够同时讨论发现过程，以及把防护送到用户手里的发布流程。

2025 年 6 月 OpenAI 总部所在的旧金山建筑。背景照片由 Coolcaesar 拍摄，已裁剪并调整大小，CC BY 4.0。图片来源 · 许可证。

有用的测试要有工具可以强制执行的边界

经授权的安全测试。Telli.sh 原创示意图。

安全团队可以授权代理检查仓库、在本地服务上运行测试，并编写候选补丁。能访问测试仓库，并不意味着可以扫描相关服务或连接其他主机。向代理明确说明允许操作的目标，并在运行环境里实施这些限制。

把获批范围视为操作人员和工具之间的约定。即使模型误解请求，网络限制也能守住边界。限制工具权限，可以阻止它写入与任务无关的系统。日志可以让审核者看到它实际访问了哪些资源。

细节取决于环境。解析器缺陷可以用离线构建版本测试。面向网络的功能，可能需要自己明确托管并授权用于测试的服务。无论哪种情况，团队都应该能根据记录重建获批范围。“需要什么就测什么”之类的宽泛指令，会让人更难判断工作何时完成，也难以确定后来的人该检查什么。

两个基准回答的是两个问题

OpenAI 的 ExploitGym 数字来自一项针对指定漏洞的能力评估。公司报告 GPT-6 Cyber 得分 48.5%，GPT-5.6 Cyber 得分 32.1%。在这项测试中，两者相差 16.4 个百分点。另一项测试在隔离环境里衡量模型是否遵守任务范围。

这是两类结果。更善于复现漏洞的系统，可能帮助安全团队更快验证报告。是否守住范围，则是需要与能力一起检查的另一项性质。OpenAI 报告称模型在测试条件下有较高的范围遵守率，使用部署提示词时，在该项评估中全部遵守。实际运行计划仍需要明确的边界和审核流程。

注意每项基准从哪里开始。给定已知漏洞和实验目标，代理可以集中精力复现行为。维护者收到一份模糊报告时，则要确定问题是否适用、哪些版本受影响，以及补丁会改变什么。这些判断需要从真实代码库中找证据。

Firefox 的修复从发布到安装存在时间差

补丁分发。Telli.sh 原创示意图。

OpenAI 报告称，模型帮助发现了此前未知的 Firefox 高严重性问题，并链接到 Mozilla 的 Firefox 159 安全公告。公告独立确认了该版本已发布相关修复。受影响的组件、严重程度和版本信息可以查阅公告。OpenAI 所公布的数量和模型贡献，描述的是公司自己的研究活动。

Mozilla 在 10 月 29 日解释了补丁时间差，这关系到工作的后半段。如果大量用户还没安装修复，修复内容却已经可以被观察，其他人可能通过研究改动推断出原来的问题。把修复提交到仓库、通过更新渠道提供，以及看到用户实际安装，发生在不同的时间。安全团队需要协调这三个节点。

因此，团队需要决定分享哪些证据、什么时候分享。一份简洁的复现材料有助于维护者验证补丁。过早公开复现方式，也可能让尚未修补的版本更容易成为目标。依照项目的披露流程，让发布负责人有机会验证内容和时机。

让审核材料可以用于重复验证

1. 把系统、版本、数据和获准操作写下来。在网络和工具访问权限符合范围的环境中执行。
2. 给模型一个明确问题，例如报告中的回归能否在受影响的测试构建版本中复现。把生产凭证和无关服务留在工作区之外。
3. 要求提供受影响的组件、授权环境中的最小测试，以及能把报告所述行为和普通错误区分开的证据。
4. 用复现测试和原有行为验证候选补丁。让维护者审查改动及潜在的意外影响。
5. 记录已确认的事项、受影响的版本，以及修复如何到达用户。等待披露时，使用项目的私密报告渠道。
6. 分别追踪发布和安装。更新发布后，支持和运营团队可以帮助用户识别并迁移到修复版本。

好的材料也会记录负面结果。如果预期条件下无法复现，准确描述试验情况能帮助下一位审核者决定关闭报告，还是换一份样本继续试。它比一句无法重复核查的自信结论更有用。

用单独的回归测试复查补丁

维护者可以从内部测试人员的报告入手：浏览器或服务处理畸形测试样本时崩溃了。先确定能否在指定版本和文档所述配置下复现。限定范围的模型可以协助整理相关日志、缩小组件范围，并准备最小的审核材料。其他成员应该能在同一个隔离环境中复现。

验证补丁需要另一项测试。在存在漏洞的版本和候选版本中运行原始样本，再测试附近的正常行为。如果补丁绕开了合法用户所需的代码路径，也可能让崩溃消失。证据应当告诉审核者，异常输入是否处理正确，以及有效输入是否仍然给出预期结果。在比较模型多快给出解释之前，先记录这个状态。

负责上线的人还有一个决定。补丁进了源代码分支，与受影响的计算机已经装上补丁，是不同的里程碑。确认支持中的发布系列、受管理终端和下游软件包如何拿到改动。对于服务，核实哪些生产版本正在接收流量，以及旧实例多快完成退出。测试结果应当对应确切版本，不能代替部署证据。

能力与范围测试分别用各自的分母

OpenAI 报告称，GPT-6 Cyber 项目发现了 81 个此前未知、按 Mozilla 标准属高严重性的问题，并进行了 30 次严重程度复评。这是 OpenAI 对研究活动的说明。Mozilla 的 Firefox 159 公告记录了该版本里的修复及贡献者。两份资料回答的问题不同，但可以一起用，因为公告给出了可以核验的具体已发布版本。

OpenAI 的 ExploitGym Honeypot 则是另一项范围测试。报告给出的结果是，无额外提示条件下为 99.93%，使用部署提示词时为 100%。这些数字描述供应商评估中的表现，应当结合测试条件和失败案例阅读，不能当成可以省略客户端网络限制、目标允许清单或操作人员权限校验的依据。独立的 ExploitGym 能力测试则比较解决技术任务的比例。

内部评估可以实际检验这一区别。既测试范围内任务，也测试一个无害但在范围之外的样本。有用的助手应当能推进前者；即使模型建议对后者采取行动，环境也必须阻止。日志和网页中的文字都按数据审查，包括看起来像新指令的文字。保留执行记录，让操作人员能区分建议的动作、被拒绝的动作和实际运行的动作。

相关人员能够验证时，再关闭报告

维护者可能要给组件负责人一份简短的私密证据包，另给用户一份发布说明。两边都去掉不必要的目标数据。有用的内部材料包括测试版本、预定范围、安全复现所需的证据、候选修复以及验证结果。公开说明遵循项目的披露流程。

这套工作能否验收，要看经过验证的修复能否在不提前披露的情况下到达用户。分别记录复现、审核、发布所花的时间，以及安装情况。初步调查更快，能够更早得到确认结果时才有价值。模型改进可能让第一步成本更低，但发布和更新仍可能限制进度。

追踪修复版本从发布到实际安装

浏览器团队可能有桌面稳定版、延长支持版，以及通过下游包管理器分发的版本。补丁可能在不同时间到达各条渠道。发布负责人需要知道哪个构建版本最先包含修复、各渠道的用户何时可以取得，以及受管理客户端有没有安装。公开公告可以标明修复版本，部署清单能显示还有多少设备留在旧版。

有受管理客户端的企业可以对照库存和公告版本列表。同一组织里的培训或实验室机器可能平时离线，需要单独交接。给受支持的更新流程安排负责人，记录何时可以验证修复版本。没有回报的机器，在设备总览中应标为未知。

决定公开证据和时间时，把补丁时间差算进去。Mozilla 的说明揭示了修复可见与用户装上更新之间的风险窗口。发布负责人准备构建版本和缓解措施时，授权测试团队可以把复现材料留在获批的审核流程内。设定重新检查安装情况的时间，并报告数据实际能证明什么。

对于小型内部服务，可以用部署标签和流量日志替代浏览器更新遥测。在替换实例上做一次冒烟测试，只能说明新实例可用。旧实例在滚动发布退出期间仍可能处理请求。把已测试版本、服务中的版本和完成时间一同记下来，之后复盘才能确认风险什么时候真正变化。

衡量多久能交付经过验证的修复

网络安全模型可以加快验证，也可以发现团队原本可能漏掉的问题。维护者能看清范围、复现结果并负责任地发布修复时，这些改进才最有意义。量一量真实问题从有据可查的报告，走到经过验证的发布用了多久。这个指标把模型能力和安全工作的目的连在一起。

来源

• GPT-6 Cyber API 模型访问说明

• OpenAI 11 月 5 日的 GPT-6 Cyber 公告和系统卡链接

• Mozilla 关于 Firefox 159 已修复漏洞的安全公告

• Mozilla 10 月 29 日对补丁时间差的说明

---

如果想把工作背后的对话和决定留成可搜索的记录，可以创建 Telli.sh 账号。