Codex Security：什么时候运行 Deep Scan

适用场景

这篇手册适合已经跑过标准扫描，并需要进一步分析复杂安全问题的用户。Deep Scan 适合跨文件、跨层调用链或高风险模块，不适合作为所有小改动的默认步骤。

OpenAI 官方 Run a deep security scan 页面介绍了该能力。具体入口和使用限制应以当前官方文档为准。

步骤 1：判断是否需要 Deep Scan

适合 Deep Scan：

• 认证、权限、支付、上传、Webhook 等高风险模块。
• 标准扫描发现的 finding 证据不足。
• 涉及多个服务或多层调用链。
• 发布前对关键模块做安全把关。
• 怀疑存在业务逻辑漏洞。

不适合：

• 普通文档修改。
• 小范围样式调整。
• 只改测试或注释。
• 已经有明确修复方案的小问题。

步骤 2：准备上下文

Deep Scan 需要更清楚的上下文。

建议提供：

• 高风险目录。
• 关键入口函数。
• 认证和权限模型简述。
• 相关 PR 或 issue。
• 已有 finding 编号。
• 想验证的攻击路径。

示例：

请对 src/api/webhooks 和 src/lib/auth 运行深度安全分析。
重点关注签名校验、权限绕过和重放风险。
不要修改代码，只输出 findings、证据和建议验证方式。

步骤 3：保持只读，先拿证据

Deep Scan 阶段应优先只读。

输出应包含：

• 风险描述。
• 相关文件和函数。
• 可能的输入路径。
• 攻击前提。
• 影响范围。
• 需要验证的问题。

如果没有证据，只说“可能有风险”还不够，需要继续 triage。

步骤 4：把 findings 分成三类

可以这样处理结果：

• 明确可修：有代码位置、触发路径和影响。
• 需要验证：缺少运行环境或业务上下文。
• 暂不可行动：证据不足或依赖产品策略。

不要把三类问题混在一起批量修复。

步骤 5：修复前写验证计划

复杂安全问题修复前应先写验证计划。

验证计划包括：

• 复现方式。
• 修复点。
• 测试用例。
• 回归范围。
• 是否需要人工安全 review。

这样能避免只改表面问题，没有修掉真实攻击路径。

常见错误

不要把 Deep Scan 当成普通 lint。

不要在没有上下文时要求全仓库深扫。

不要直接修复所有 finding。先确认证据和影响。

不要把敏感生产数据提供给扫描任务。

小结

Deep Scan 适合复杂、高风险、证据需要加深的问题。正确流程是限定范围、补充上下文、只读分析、分类 findings，并在修复前写清验证计划。