---
title: "排查安全常见问题"
description: "用 FAQ 方式理解 Codex Security 的定位、扫描流程、隔离边界、验证结果和人工审查责任。"
verifiedAt: "2026-05-07"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

Codex Security 可以帮助团队发现、验证和修复安全风险，但它不是人工安全审查或现有 SAST 的替代品。它更适合做规模化分诊、证据收集和补丁建议。

> [!WARNING]
> 安全 finding 不能只看“模型说有问题”。必须看证据、复现、影响范围、可利用性、补丁风险和人工审查结论。

<Cards>
  <Card title="Codex Security" href="https://developers.openai.com/codex/security">
    查看 Codex Security 的官方入口和当前功能说明。
  </Card>
  <Card title="Security setup" href="https://developers.openai.com/codex/security/setup">
    了解如何为仓库配置 Codex Security。
  </Card>
  <Card title="Threat model" href="https://developers.openai.com/codex/security/threat-model">
    学习如何改进仓库的 threat model。
  </Card>
</Cards>

## 它解决什么问题

Codex Security 主要解决三类问题：

- 在大量代码和提交中发现潜在漏洞。
- 对疑似漏洞进行验证，减少误报。
- 给出结构化 finding 和建议补丁，帮助团队进入 review。

它适合安全团队和工程团队协作使用。模型可以缩短分诊路径，但最终判断仍要由人负责。

## 基本工作流

```mermaid
flowchart LR
    Repo["连接仓库"] --> Model["建立 threat model"]
    Model --> Scan["扫描代码和提交"]
    Scan --> Verify["尝试自动验证"]
    Verify --> Finding["生成 finding"]
    Finding --> Review["人工审查"]
    Review --> Patch["接受、修改或拒绝补丁"]
```

关键点：

- 分析运行在隔离环境中。
- findings 会包含严重程度、位置、根因和证据。
- 可验证的问题会尝试复现。
- 建议补丁需要人工审查后再进入仓库。

## 常见问题

### 它能替代 SAST 吗

不能。Codex Security 是补充层。

传统 SAST 擅长规则化、覆盖面广、可重复检查。Codex Security 擅长语义分析、上下文理解、验证尝试和修复建议。两者应该组合使用。

### 它会自动改仓库吗

不会把补丁直接应用到你的仓库。建议补丁只是待审查产物。维护者应在 PR、diff 或 suggested change 中审查后再决定是否合入。

### 扫描前必须能构建项目吗

不一定。它可以基于代码和提交上下文产出 findings。需要验证时，系统可能尝试构建或运行相关命令。

如果项目构建依赖复杂环境，应优先配置 cloud environment 和 setup steps。

### 自动验证失败怎么办

验证失败不等于问题不存在。它说明系统没有在当前环境中成功复现。

处理方式：

- 查看验证日志。
- 检查环境是否缺依赖。
- 补充更准确的复现步骤。
- 由工程师手动确认可利用性。

### Threat model 有什么用

Threat model 给扫描提供安全上下文，例如入口点、信任边界、认证假设和高风险组件。

仓库架构变化后，threat model 也要更新。过期 threat model 会影响 finding 质量。

### 它能替代人工安全审查吗

不能。它能提高覆盖和分诊效率，但安全责任仍在人。

人工审查需要确认：

- finding 是否真实。
- 影响范围和严重程度。
- 是否可利用。
- 建议补丁是否正确。
- 是否引入回归或兼容问题。

## 结果怎么读

读 finding 时按这个顺序：

1. 严重程度和影响面。
2. 文件位置和调用路径。
3. 根因解释。
4. 验证状态。
5. 复现日志和 artifact。
6. 建议补丁。
7. 人工审查结论。

不要只看标题和 severity。安全问题的价值在证据链。

## 接入前检查

配置 Codex Security 前，确认：

- 仓库权限是否最小化。
- 扫描范围是否明确。
- cloud environment 是否能构建或验证关键路径。
- secrets 是否只在必要阶段可用。
- 谁负责 review findings。
- 谁负责合并或拒绝补丁。
- 如何记录误报、漏报和规则改进。

## 什么时候升级给安全团队

这些情况应升级：

- 涉及认证、授权、支付、密钥或用户数据。
- finding 已验证且影响生产路径。
- 建议补丁会改变安全边界。
- 需要判断可利用性。
- 需要合规、法务或客户通知。

Codex Security 的作用是让安全工作更早、更有证据，而不是让团队跳过审查。

## 排障优先级

遇到 Codex Security 结果不符合预期时，按这个顺序排查：

1. **Access**：workspace 是否有 Codex Security 权限，repository 是否在 Codex Cloud 可见。
2. **Environment**：scan 使用的 environment 是否能安装依赖、运行关键验证命令。
3. **Initial backfill**：初始扫描是否真的完成，大仓库是否仍在等待。
4. **Threat model**：project overview 是否写清入口、信任边界、敏感数据和优先模块。
5. **Finding evidence**：finding 是否有复现、调用路径、日志或验证输出。
6. **Patch quality**：建议补丁是否最小、可审查、可测试。

不要一开始就把问题归因给模型。Codex Security 的输入包含仓库、environment、history window、threat model 和验证环境，任何一层不准，输出都会受影响。

## 官方资料

- [Codex Security](https://developers.openai.com/codex/security)
- [Codex Security setup](https://developers.openai.com/codex/security/setup)
- [Codex Security FAQ](https://developers.openai.com/codex/security/faq)
- [Improving the threat model](https://developers.openai.com/codex/security/threat-model)
