Codex Security：修复并验证安全 findings

适用场景

这篇手册适合已经从 Codex Security 得到 findings，并准备让 Codex 辅助修复的用户。修复安全问题要比普通 bug 更谨慎，因为错误修复可能只隐藏症状，没有消除攻击路径。

OpenAI 官方 Fix and verify security findings 页面介绍了修复与验证流程。具体插件行为以当前官方页面为准。

步骤 1：先确认 finding

修复前先确认：

• 代码位置是否准确。
• 输入路径是否可达。
• 攻击前提是否现实。
• 影响范围是否明确。
• 是否需要业务上下文。

如果 finding 依赖产品策略，例如“某用户是否应有权限”，先找负责人确认。

步骤 2：让 Codex 提出修复计划

不要直接说“修一下”。先要求计划。

请针对 finding F-123 制定修复计划。
先不要修改文件。
说明漏洞路径、修复点、需要新增的测试和可能影响的行为。

确认计划后再修改。

步骤 3：限定修改范围

安全修复应尽量小。

可以写：

只修改认证校验相关文件和对应测试。
不要重构无关模块，不要改变公开 API 行为。

这能减少修复引入新的回归。

步骤 4：补验证用例

安全修复最好包含测试。

测试应覆盖：

• 漏洞触发路径。
• 修复后的拒绝行为。
• 正常用户不受影响。
• 边界条件。
• 相关回归场景。

如果无法自动化测试，也要记录人工验证步骤。

步骤 5：复查和关闭 finding

修复后检查：

• finding 是否不再成立。
• 测试是否覆盖攻击路径。
• 是否引入新权限问题。
• 日志是否泄露敏感信息。
• PR 描述是否包含验证方式。

确认后再更新 issue、backlog 或安全跟踪系统。

常见错误

不要只修报错位置，不修真实入口路径。

不要为了快速通过测试而放宽权限判断。

不要在修复 PR 中混入无关重构。

不要关闭没有验证的 finding。

小结

修复安全 findings 的正确顺序是：确认风险、制定计划、限定范围、修改代码、补测试、复查并记录验证。Codex 可以辅助修复，但最终关闭风险需要证据。