Codex Security：导出并跟踪安全 findings

适用场景

这篇手册适合已经运行 Codex Security 扫描，并希望把 findings 纳入长期跟踪的团队。扫描结果如果只停留在聊天或本地报告里，很容易丢失。

OpenAI 官方 Export and track security findings 页面介绍了导出和跟踪流程。具体集成方式以当前官方页面为准。

步骤 1：先清理 findings

导出前先做初步整理。

建议分类：

• 高危且证据明确。
• 中低危但需要排期。
• 需要业务确认。
• 可能误报。
• 需要 deep scan 或复现。

不要把未整理的所有结果直接丢给开发团队。

步骤 2：选择跟踪系统

常见去向：

• GitHub issue。
• Linear。
• Jira。
• 安全 backlog。
• 内部漏洞管理系统。
• PR review 评论。

选择标准：

• 能分派负责人。
• 能设置优先级。
• 能记录状态。
• 能关联 PR。
• 能保留验证证据。

步骤 3：每条 finding 保留必要字段

建议字段：

• 标题。
• 严重程度。
• 影响范围。
• 文件位置。
• 证据和调用链。
• 建议修复方向。
• 验证方式。
• 状态。
• 负责人。

缺少证据的 finding 应标记为“需要验证”，而不是直接安排修复。

步骤 4：建立状态流转

可以使用这些状态：

• new：刚导入。
• triage：正在判断真实性和优先级。
• accepted：确认需要修。
• in_progress：正在修复。
• fixed：已修复待验证。
• verified：已验证。
• not_actionable：误报或暂不处理。

状态流转要有证据，不要只靠口头确认。

步骤 5：定期复查 backlog

安全 backlog 会过期。

定期检查：

• 高危项是否超期。
• 已修复项是否验证。
• 误报是否有证据。
• 旧 finding 是否因代码变化失效。
• 是否需要重新扫描。

导出只是开始，跟踪才是安全管理。

常见错误

不要把 findings 导出后就不管。

不要缺少负责人和截止时间。

不要让安全问题混在普通需求里失去优先级。

不要关闭没有验证证据的问题。

小结

导出 findings 的目标是让安全问题可追踪、可分派、可验证。先整理结果，再进入合适的 backlog，保留证据和状态，最后定期复查。