Codex Security：审查代码变更中的安全风险

适用场景

这篇手册适合在 PR 合并前用 Codex Security 检查安全风险。它关注的是“这次变更引入了什么风险”，不同于全仓库扫描。

OpenAI 官方 Review code changes for security 页面介绍了该流程。具体入口以当前官方页面为准。

步骤 1：明确审查对象

先说明审查的是：

• 当前 PR。
• 本地未提交 diff。
• 某个 commit 范围。
• 某个安全敏感目录。

示例：

请只审查当前 PR 的代码变更。
重点关注认证、权限、输入校验、敏感信息泄露和依赖风险。
不要扫描全仓库历史问题。

这样能避免结果偏离当前 review。

步骤 2：说明项目安全边界

如果项目有特殊规则，应补充给 Codex。

例如：

• 管理员接口必须二次校验权限。
• Webhook 必须验证签名。
• 上传接口必须限制文件类型和大小。
• 日志不得包含 token。
• 数据库查询必须经过租户过滤。

安全审查越懂项目边界，结果越有价值。

步骤 3：要求 findings 优先

让 Codex 按 review 风格输出。

请按严重程度列出 findings。
每条包含：文件位置、问题、影响、攻击前提、建议修复和验证方式。
如果没有发现问题，请说明未覆盖的风险。

避免只得到泛泛的“建议加强安全”。

步骤 4：对高风险 findings 做二次确认

高风险 finding 不要草率修复。

需要确认：

• 是否真实可达。
• 是否影响生产路径。
• 是否需要迁移数据。
• 是否改变用户权限。
• 是否需要安全负责人 review。

确认后再安排修复。

步骤 5：把安全审查结果写进 PR

PR 描述或评论应记录：

• 审查范围。
• 发现的问题。
• 已修复项。
• 未修复但记录的风险。
• 验证命令。
• 人工 review 结论。

这样后续审计能追踪安全判断。

常见错误

不要让安全审查扩大到所有历史问题，否则会干扰当前 PR。

不要只看高危问题，权限边界的小改动也可能很关键。

不要把 Codex 的安全结论当成人工批准。

不要在 PR 评论中暴露密钥、内部漏洞细节或客户数据。

小结

PR 安全审查应聚焦当前 diff。明确范围、补充项目安全边界、要求可执行 findings，并把修复和验证结果记录回 PR，是更稳的安全流程。