外部漏洞合作项目怎么划线：第三方测试范围、连接面与披露顺序
外部漏洞合作要划的三条线分别是授权边界（谁能测哪些资产、碰哪些数据、做什么被禁止）、连接面（系统与第三方服务之间的每条调用路径与凭据）和时间边界（内部定级、第三方通知、用户通知与公开披露的先后）。本次材料只有 OpenAI 与 Hacktron 合作摘要，只支持“合作找漏洞、测试第三方连接、强化防御”这一窄结论；具体范围、时限与奖励待核实。
如果你的团队准备引入外部研究者做漏洞测试，需要先划清三条线：谁能测什么（授权边界）、能碰到哪些外部依赖与凭据（连接面）、发现问题后按什么顺序说、对谁说（时间边界）。三条线都要落到可核查的文字上，而不是新闻稿里的一句“我们重视安全”。
材料能支持的只有一条窄结论#
据 OpenAI 于 2026 年 11 月 6 日发布的摘要，该公司与 Hacktron 合作寻找其系统中的漏洞、测试与第三方服务的连接，并用前沿 AI 强化防御（来源：Partnering with Hacktron to find vulnerabilities in OpenAI’s systems）。这是摘要层面的信息。测试范围清单、时间窗、奖励规则、披露时限等细节，本次材料未提供正文，本文不作推断。下文是由这条窄结论展开的一般工程做法，不是对该项目的描述。
第一道线：测试范围写成授权清单#
“欢迎测试我们的系统”不能作为授权。能作为授权的是清单：测哪些资产、在哪个环境、允许接触什么数据、哪些行为一律禁止。写不清的部分，默认视为不在范围内。
| 维度 | 必须写清 | 常见漏项 |
|---|---|---|
| 资产 | 域名、API 版本、移动端、CI、内部管理台 | 边缘子域、预览环境、旧版本接口 |
| 环境 | 生产只读、预发、专用沙箱账号 | 测试账号缺配额隔离 |
| 数据 | 是否允许接触真实用户数据、密钥、日志 | 截图与样本留存规则 |
| 禁止行为 | 拒绝服务、社会工程、物理入侵、对第三方服务压测 | 自动化扫描的速率上限 |
| 沟通 | 单一联系人、报告渠道、时间窗 | 紧急联系方式与响应时限 |
建议把这张表放进一份仓库内的范围声明，与测试方共同签字确认版本号，改动留痕。这样“测过界”才有可对照的基线。
第二道线：把连接面拆成可枚举的对象#
“测试与第三方服务的连接”这句话，在工程上应展开成一串具体路径：出站 HTTP 调用、webhook 回调、OAuth 授权范围、共享签名密钥、消息队列的跨账号投递。测试方每多碰一条路径，就多一个可能被写进报告、也可能被写进日志的凭据。
- 为测试方单独签发凭据，最小权限、可随时吊销、与生产凭据分开计量。
- 逐条列出出站依赖及其所有者，标注哪些允许被测试、哪些只能观察。
- 明确测试方是否可能触达第三方的生产环境；若可能，需在与该第三方的合同中先处理授权问题，而不是事后追认。
- 对回调方向做校验：签名、来源白名单、重放窗口，并与测试范围一并说明。
第 3 点是建议而非既有事实：第三方是否同意被间接测试，属于合同与合规层面的判断，需要逐家确认。
第三道线：先定顺序，再定时间#
披露顺序比披露时限更容易出事，因为第三方修复节奏不受你控制。可行的顺序是：内部定级与复现 → 修复或缓解 → 通知受影响的第三方服务 → 按适用要求通知用户与监管 → 公开复盘。每一步都要写清谁有权对外发声、默认静默期多长、意见分歧时由谁裁决。
顺序先行的理由很直接：若第三方尚未修复就先行公开，风险被转移给了没有参与定级的一方。至于具体静默期是 30 天、90 天还是按修复进度浮动，本次材料没有依据，属于待核实项，应结合漏洞类型与第三方合同自行确定。
一份可照抄的骨架#
下面是范围声明的片段，属于文本模板，未执行任何代码或扫描，仅示意结构。域名与邮箱均为占位。
# 外部测试授权 v1.0（示例，占位内容）
范围: api.example.com / 预发环境 sandbox.example.com
不在范围: 支付通道、第三方 CDN、员工邮箱与办公网络
账号: 由安全团队签发，scope=read-only，7 天到期
禁止: DoS、社工、物理入侵、对第三方服务发起扫描
报告: security@example.com，24 小时内确认收到
披露: 修复完成前不公开；涉及第三方的，先同步该第三方
裁决人: 安全负责人（占位）三条线指向同一件事#
把“我们欢迎外部测试”翻译成三句可核查的话：谁在什么范围内测、能碰到哪些连接与凭据、什么时候按什么顺序说。写不出这三句，合作项目就只是意向；写得出，才谈得上边界。
参考来源
以上为本文写作时的参考资料，引用观点以原文为准。
