OpenAI 如何将安全发现转化为经过验证的修复

OpenAI 网络安全产品工程团队的 Ian 和 Kyle 介绍 Codex Security：命令行流程用于发现和验证问题、生成补丁并核验修复，另有托管云服务。

Ian 认为，更强的模型给防守者提供了一个窗口期，可以在类似能力广泛落入攻击者手中之前发现弱点。他说 OpenAI 将安全列为全公司优先事项。

他说，在一次内部安全冲刺中，四分之一的产品工程师专门加强系统安全。团队建立了持续循环，用于扫描、验证、分配负责人并核验修复。

Ian 报告称，去重和验证后的误报率为 0.81%，Codex 生成修复的回滚率低于 1%。这项工作形成了插件、CLI、SDK 和云产品。

Kyle 将流程分成五部分：提供上下文、扫描、丰富发现信息、生成补丁，再将结果融入开发流程。他说开源 CLI 为内部工作提供了核心构件。

对于 OpenAI 的大型代码库，简单要求智能体找出全部漏洞并不足够。团队将扫描拆成较小范围，并提供组件功能、暴露面和现有防护的背景。

针对单次扫描的指令规定范围和需要调查的漏洞类型。反复使用的背景则可以放在扫描器和验证器共用的知识库里，包括源码之外的架构和防火墙信息。

OpenAI 还在各组件中提交 SECURITY.md 文件，让产品负责人记录威胁模型和安全准则。Kyle 演示了如何在深度扫描中同时提供提示词和知识库。

深度扫描并行运行多个智能体、合并发现，并反复扫描，直到不再发现新问题或达到配置上限。扫描大型代码库可能需要相当长时间。

数百个智能体扫描不同区域，产生了数万条发现。Kyle 说，去重是早期瓶颈：多份报告可能描述同一个漏洞，从而生成重复工单。

在内部冲刺中，36% 的发现是重复项。CLI 的去重流程利用智能体先将这些报告归组，再交给开发者调查。

随后团队按照安全评分标准对发现分类。Kyle 说，随着团队逐步了解哪些漏洞最重要，标准也经过多次调整，其中包括外部人员可能获得未授权访问的情况。

在一家快速成长的公司里，确定负责人出乎意料地困难。团队明确哪些小组负责哪些组件后，分配问题时工单在团队之间转手的情况减少了。

起初，开发者收到工单后，让 Codex 提出修复，再通过拉取请求将修改送入生产环境。随着上下文和信心改善，团队开始提前自动生成补丁。

Kyle 将自动化比作一个可调节的旋钮：团队可以随着信心增长逐步扩大其作用。CLI 的补丁流程可以接收启动开发环境和测试修改的说明。

额外的 verify-fix 步骤检查补丁是否真正解决了问题；Kyle 将它比作质疑拟议修复的对抗性智能体。生成的修改仍要经过组织正常的审查流程。

讲者说，CLI 的基础功能可以适应不同工作流程，不论其中要求代码审查、质量检查还是产品审查。团队可以把它们接入代码库和持续集成，而不必替换现有流程。

Ian 展示了第三方 PatchBench 对比，称在所示测试中，较新的模型以更低成本取得了更好的结果。他预计模型进步也会改进同一套安全流程。

他描述了一个先出现大量积压、清理后发现数量减少且检测更快的过程。他说，要保持这种状态，代码库变化时必须持续扫描。

Ian 说，CLI 和 SDK 可以组合进持续集成或 GitHub 工作流。Codex Security Cloud 则提供与 GitHub 代码库连接的托管持续循环，并使用面向安全任务的 Daybreak 模型。

在云端演示中，他安装插件、连接 GitHub，并设置每次新提交时扫描。结果页面展示发现的问题，还允许生成补丁并作为拉取请求供审查。