OpenAI 开源 Codex Security：如何扫描、验证和修复漏洞

引言

OpenAI 已悄然发布了 Codex Security 命令行界面和 TypeScript SDK 的源代码。

这个公开软件包 @openai/codex-security 旨在帮助安全和工程团队：

• 扫描代码库以发现漏洞。
• 验证合理的发现结果。
• 在代码合并前审查变更。
• 在多次扫描中跟踪发现结果。
• 标记并记住误报。
• 验证修复是否解决了原始问题。
• 导出结构化结果以实现自动化。
• 将安全审查集成到 CI/CD 工作流中。
• 通过 TypeScript SDK 构建自定义安全工具。

该代码库以 Apache License 2.0 协议发布。

这意味着 CLI 和 SDK 代码是开源的。但这并不意味着整个 Codex Security 服务、其底层模型、每一条受保护的发现结果，或无限的网络访问权限现在都可以免费离线使用。

运行扫描仍然需要 Codex Security 访问权限。OpenAI 还表示，某些全仓库扫描、受保护的发现结果以及高级网络安全请求可能需要通过 网络安全可信访问（Trusted Access for Cyber） 审批。

这一区别非常重要：

开源 CLI 和 SDK
≠
开放权重安全模型
≠
不受限制的云端扫描访问

Codex Security 最初是一个名为 Aardvark 的内部项目。后来它以研究预览版应用安全代理的形式进入 Codex，而新的公开软件包现在允许开发人员将扫描器带入本地终端、内部工具、批量代码库活动、提交前检查和 CI 管道中。

从 Aardvark 到 Codex Security

OpenAI 于 2025 年 10 月首次推出 Aardvark，它是一个由 GPT-5 驱动的智能安全研究员。

该原始系统的设计目标是更像人类应用安全研究员，而非传统的特征码扫描器。

它不仅仅是根据已知模式匹配代码，Aardvark 还能：

• 读取代码库。
• 构建系统工作原理的模型。
• 检查新的提交。
• 推理可利用性。
• 编写并运行测试。
• 使用安全工具。
• 解释漏洞。
• 提出针对性的补丁方案。

2026 年 3 月，OpenAI 将 Aardvark 更名为 Codex Security，并将其集成到 Codex 中。

该产品通过 Codex Web 以研究预览版形式向部分 ChatGPT 套餐用户开放，并支持已连接的 GitHub 代码库。

此后的开源发布添加了不同的部署层。

开发人员现在可以安装 CLI 或导入 TypeScript SDK，而托管式 Codex Security 云体验仍独立存在。

实际开源了什么

公开的 GitHub 代码库包含：

• Codex Security CLI。
• TypeScript SDK。
• Docker 和 Docker Compose 资源。
• 面向 CI 的命令和结构化输出支持。
• 扫描历史记录和发现结果管理功能。
• 文档和贡献文件。

该软件包通过 npm 发布为：

@openai/codex-security

该代码库的 Apache-2.0 许可证通常允许在许可条款范围内使用、修改和再分发。

未以开放模型形式包含的内容

该

本次发布不提供 GPT-5.6 Sol、Terra 或专用 Codex Security 模型的权重。

默认扫描当前使用：

gpt-5.6-sol
推理强度：xhigh

CLI 通过经过身份验证的访问来调用推理服务。

该仓库还记录了针对所选模型的提供方选项（如 OpenRouter 和 Fireworks），但 Codex Security 扫描工作流和受保护的网络能力可能仍需要 OpenAI 方面的授权。

开源并不解除访问控制

安装 npm 包并不等于获得运行每次扫描的许可。

OpenAI 的文档说明：

• 需要 Codex Security 访问权限。
• 某些仓库或请求可能需要“网络可信访问”。
• 登录或设置 API 密钥并不会自动授予“可信访问”权限。
• 安全发现可能包含敏感的源代码摘录和漏洞利用细节。
• 用户应只扫描自己拥有或有权评估的代码。

公开代码使工作流可检查和可扩展。它并不会移除围绕高级网络用途的安全和授权层。

为什么这次发布很重要

AI 编程代理生成和修改软件的速度，可能超过许多组织的审查速度。

这就造成了安全瓶颈。

一个产品可能只需几天或几小时就能从想法变成已部署的应用，而传统的应用安全审查可能仍依赖：

• 手动威胁建模。
• 静态分析配置。
• 渗透测试。
• 依赖审查。
• 人工分诊。
• 发布排期。
• 安全团队的可用性。

问题并不仅仅在于开发者缺少漏洞报告。

许多维护者收到的报告已经过多，包括：

• 重复发现。
• 低影响警告。
• 错误严重性评级。
• 不可达代码路径。
• 没有证据的发现。
• 泛泛的修复建议。
• 忽略项目架构的报告。

Codex Security 的设计围绕相反的目标：更少、更具上下文的发现，并附带证据，帮助审查者决定该修复什么。

Codex Security 如何工作

OpenAI 将该系统描述为一个多阶段的应用安全工作流。

1. 构建仓库上下文和威胁模型

Codex Security 首先研究仓库，以理解项目中与安全相关的结构。

它试图识别：

• 系统做什么。
• 哪些组件彼此信任。
• 用户可控输入在何处进入。
• 哪些边界分隔用户、租户、角色或服务。
• 哪些操作具有特权。
• 哪些资产是敏感的。
• 系统在何处暴露给攻击者。

结果是针对项目的威胁模型，而不是通用检查清单。

团队可以添加架构文档、安全策略、重点领域和已知攻击向量来改进这一上下文。

1. 在上下文中搜索漏洞

该代理在审查相关代码时，会使用威胁模型来判断现实影响。

这使它能够推理那些基于规则的扫描器难以孤立理解的问题。

示例可能包括：

• 跨租户边界的授权缺口。
• 间接提示

注入访问特权工具。

• 通过代理追踪暴露敏感数据。
• 认证绕过。
• 服务器端请求伪造。
• 原本普通组件之间的危险交互。

扫描器可以审查：

• 整个代码仓库。
• 一个或多个选定路径。
• 一个提交范围。
• 拉取请求变更。
• 已暂存和未暂存的工作树变更。
• 批量活动中多个代码仓库。

1. 验证合理发现

在可能的情况下，Codex Security 尝试在隔离环境中验证高信号问题。

验证可以帮助回答：

• 脆弱路径是否可达。
• 提出的利用条件是否现实。
• 概念验证是否有效。
• 问题是否被错误分类。
• 发现是否可能影响正在运行的系统。

此步骤旨在减少误报。

它不保证每个发现都已被复现，也不保证完整扫描证明代码仓库是安全的。

扫描的 coverage.json 文件记录覆盖状态是否为：

完整
部分
未知

审查者应在将扫描视为全面审查的证据之前，阅读排除项、延后区域和未决问题。

1. 提出针对性修复

对于已接受的发现，Codex Security 可以建议一个旨在适应当前系统的补丁。

目标不仅仅是让扫描器安静下来。

一个好的修复应该：

• 消除或缓解根本原因。
• 保持预期应用行为。
• 避免广泛无关的重构。
• 尽量减少回归。
• 在适当情况下包含证据或测试。
• 保持可被人为工程师审查。

Codex Security 扫描默认仅提供报告。建议的补丁仍应通过正常的代码审查、测试和部署控制流程。

1. 从审查反馈中学习

CLI 存储扫描历史并支持发现反馈。

审查者可以将发现标记为误报并记录原因。

后续扫描可以在再次检查当前代码时考虑该解释。

这有助于扫描器适应代码仓库特定事实，而不会永久抑制可能在未来变得易受攻击的代码路径。

OpenAI 报告的結果

OpenAI 已发布其预览部署中的多项采用和质量数据。

这些是公司报告的指标，并非独立基准测试结果。

2026 年 3 月研究预览

OpenAI 表示，在一个 30 天期间内，Codex Security：

OpenAI 还报告称，测试版改进：

• 在一个持续扫描的代码仓库中，不必要的警报减少了 84%。
• 严重性被夸大的发现减少了超过 90%。
• 各代码仓库中的误报减少了超过 50%。

2026 年 6 月 Daybreak 更新

OpenAI 随后表示，Codex Security 云版已具备：

已确定固定 | 超过 50 万 |

规模可观，但这些数字不应被解读为与 CodeQL、Semgrep、Snyk 或人工渗透测试之间的受控比较。

这些工具的运行方式不同，可能以不同方式衡量发现、修复和覆盖率。

Codex Security 接口

Codex Security 现可通过多个相关界面使用。

公共 CLI 和 SDK 使用与插件相同的一般扫描器工作流，但插件目录、CLI 包和云端研究预览之间的可用性和功能成熟度可能有所不同。

快速入门：安装并运行 Codex Security

以下命令遵循 OpenAI 当前官方 CLI 文档。

第 1 步：检查先决条件

CLI 需要：

Node.js 22 或更高版本
Python 3.10 或更高版本
Codex Security 访问权限

GitHub 仓库目前提供了更具体的受支持的 Node.js 版本范围，包括最新的 22.x、24.x 和 26.x 版本。

检查您的环境：

node --version
python3 --version

第 2 步：安装软件包

从 npm 安装 Codex Security：

npm install @openai/codex-security

检查已安装的版本：

npx @openai/codex-security --version

列出命令：

npx @openai/codex-security --help

第 3 步：进行身份验证

对于本地交互使用，请使用 ChatGPT 账户登录：

npx @openai/codex-security login

对于远程或无头机器：

npx @openai/codex-security login --device-auth

对于 CI 或其他无人值守工作流，请通过环境提供 API 密钥：

export OPENAI_API_KEY=""

请勿将 API 密钥放入源代码管理中。

请使用密钥管理器或 CI 平台的受保护密钥系统。

当已存储的 ChatGPT 登录和 API 密钥都可用时，请明确选择所需方法：

npx @openai/codex-security scan . --auth chatgpt

或：

npx @openai/codex-security scan . --auth api-key

身份验证不会自动授予 Cyber 的 Trusted Access。

第 4 步：选择私有输出目录

OpenAI 建议将结果存储在扫描仓库之外。

报告可能包含：

• 源代码摘录。
• 漏洞证据。
• 概念验证材料。
• 架构细节。
• 敏感路径。
• 修复指导。

准备目标和结果目录：

REPOSITORY=/path/to/repository
SCAN_DIR=/path/outside/repository/codex-security-results

如果默认持久状态目录不可写，请选择另一个私有目录：

export CODEX_SECURITY_STATE_DIR=/path/outside/repository/codex-security-state

第 5 步：运行干运行检查

验证

在开始模型工作之前，先确认本地路径和扫描配置：

npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--dry-run

试运行不会启动 Codex，也不会加载扫描凭据。

步骤 6：运行首次扫描

启动标准仓库扫描：

npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR"

在标准输出上请求机器可读的 JSON 格式：

npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--json

默认情况下，Codex Security 当前使用：

模型：gpt-5.6-sol
推理强度：xhigh

较低成本的配置可以使用其他受支持的模型和强度级别：

npx @openai/codex-security scan "$REPOSITORY" \
--model gpt-5.6-terra \
--effort high

支持的强度设置包括：

minimal（最低）
low（低）
medium（中）
high（高）
xhigh（极高）

较低的强度可能会减少时间和成本，但也可能降低审查的深度。

完整扫描的产出结果

标准结果目录可能包含：

codex-security-results/
├── scan-manifest.json
├── findings.json
├── coverage.json
├── report.md
├── artifacts/
└── exports/
└── results.sarif

report.md

主要的人类可读报告。

findings.json

结构化发现，包括严重性、置信度、受影响位置、证据和修复建议。

coverage.json

审查覆盖范围、排除项、延迟处理的工作、未决问题和完整性评估。

scan-manifest.json

目标、范围、生产者信息和密封工件引用。

artifacts/

漏洞报告、概念验证文件或相关证据（如有）。

SARIF 导出

SARIF 可被 GitHub Code Scanning 和其他兼容的安全工具使用。

只扫描重要的区域

大型单仓库并不一定每次都需全量扫描。

选择特定路径：

npx @openai/codex-security scan "$REPOSITORY" \
--path services/billing \
--path packages/auth

当一次发布影响特定服务或安全边界时，这种方式非常有用。

审查拉取请求或提交范围

扫描基础修订版本与 HEAD 之间已提交的更改：

npx @openai/codex-security scan "$REPOSITORY" \
--diff origin/main \
--head HEAD

仓库参数必须指向 Git 工作树根目录，且所需修订版本必须存在于本地。

审查未提交的更改

扫描相对于 HEAD 的已暂存和未暂存更改：

npx @openai/codex-security scan "$REPOSITORY" \
--working-tree \
--base HEAD

在创建拉取请求或提交涉及安全敏感更改之前，这种方式非常有用。

使用深度扫描模式

当普通扫描不够充分时，运行更全面的审查：

npx @openai/codex-security scan "$REPOSITORY" \
--mode deep

深度模式耗时更长，可能消耗更多模型资源。

OpenAI 当前文档说明，它支持仓库和路径目标，不支持 diff 或工作树目标。

添加上下文架构和安全信息

提供内部文档，帮助代理正确理解系统：

npx

@openai/codex-security scan "$REPOSITORY" \
--knowledge-base /path/to/architecture.md \
--knowledge-base /path/to/security-policies

有用的上下文可以包括：

• 信任边界。
• 身份验证架构。
• 租户隔离规则。
• 敏感数据分类。
• 预期网络路径。
• 安全不变量。
• 威胁模型。
• 已知例外。
• 补偿性控制。

不要不必要地包含机密信息。

这些文件属于安全敏感的扫描工作流的一部分，应遵循适当的保留和访问控制。

控制扫描成本

设置以美元计的估计模型成本上限：

npx @openai/codex-security scan "$REPOSITORY" \
--max-cost 5

已在进行中的请求可能在达到上限后仍然完成，因此最终金额可能超过阈值。

当成本限制的扫描停止时，Codex Security 会保留已有的结果。

部分结果不应被视为完整的仓库覆盖范围。

添加预提交安全检查

安装随附的 Git 钩子：

npx @openai/codex-security install-hook

该钩子在提交前扫描暂存和未暂存的更改。

OpenAI 表示它会阻止：

• 高严重性发现。
• 扫描错误。

它不会替换现有的预提交脚本。

团队应在组织范围内启用该钩子之前，审查它如何与本地性能、开发者访问权限、模型成本以及现有的 lint 或测试钩子交互。

扫描多个仓库

首先验证 GitHub CLI：

gh auth login

启动交互式仓库发现流程：

npx @openai/codex-security bulk-scan

当前的交互式流程排除已归档仓库和分叉，并在扫描前要求确认。

使用准备好的 CSV 清单进行可重复的扫描活动：

npx @openai/codex-security bulk-scan repositories.csv \
--output-dir /path/outside/repositories/security-scans \
--workers 4

再次运行相同的命令可以恢复扫描活动，而不会重新扫描已有完整结果工件的仓库。

在 Docker 中运行批量扫描

公共仓库包含 Docker 和 Compose 资源。

在账户访问包含所需镜像和环境的情况下，示例批量命令为：

docker compose run --rm codex-security \
bulk-scan /input/repositories.csv \
--output-dir /output \
--workers 4

OpenAI 建议：

• 使用 Linux Docker 主机。
• 支持非特权用户命名空间。
• 为结果和登录状态使用私有持久化目录。
• 通过环境或密钥管理器提供机密信息。
• 在支持的情况下可选启用 AppArmor 加固。

容器化减少了部分主机暴露，但并不会使授权的安全扫描变得零风险。

跨运行跟踪发现

列出仓库的先前扫描：

npx @openai/codex-security scans list "$REPOSITORY"

检查已保存的扫描：

npx @openai/codex-security scans show SCAN_ID

将已审查的发现标记为误报：

npx @openai/codex-security findings false-positive FINDING_OCCURRENCE_ID \
--reason "该路由已检查权限"

使用其原始设置重新运行已保存的扫描

配置：

npx @openai/codex-security scans rerun SCAN_ID

按根本原因匹配发现项：

npx @openai/codex-security scans match PREVIOUS_SCAN_ID CURRENT_SCAN_ID

比较扫描结果：

npx @openai/codex-security scans compare PREVIOUS_SCAN_ID CURRENT_SCAN_ID

比较可以将发现项分类为：

• 新增。
• 持续存在。
• 重新打开。
• 已解决。
• 未知。

当后续扫描未覆盖相关区域时，缺失的发现项将保持未知状态。

使用 TypeScript SDK

同一个 npm 包包含一个 ECMAScript 模块 TypeScript SDK。

它需要服务端 Node.js 22 或更高版本，扫描还需要 Python 3.10 或更高版本。

基本集成方式如下：

import { CodexSecurity } from "@openai/codex-security";

const security = new CodexSecurity();

try {
const result = await security.run("/path/to/repository", {
outputDir: "/path/outside/repository/results",
});

console.log(result.reportPath);
console.log(result.coverage.completeness);
console.log(result.findings.findings.length);
} finally {
await security.close();
}

该 SDK 通过以下功能支持长时间运行的工作流：

• 预检检查。
• 类型化发现项。
• 覆盖详情。
• 进度回调。
• 预估成本限制。
• 取消操作。
• 扫描生命周期管理。
• 访问工件路径。

可复用的应用程序应创建客户端、运行所需扫描，并关闭客户端以释放隔离的运行时环境。

将 Codex Security 添加到 CI

OpenAI 官方 CI 指南演示了使用 GitHub Actions 进行拉取请求扫描。

推荐的模式是：

1. 将 API 密钥存储为受保护的仓库或组织机密。
2. 在仓库检出目录之外安装 Codex Security。
3. 锁定包版本。
4. 检出完整的 Git 历史，但不保留检出凭据。
5. 计算合并基准。
6. 仅扫描拉取请求的差异。
7. 导出 SARIF。
8. 将 SARIF 上传到 GitHub Code Scanning。
9. 保留扫描工件。
10. 仅在审查扫描质量和运行时间后添加严重性策略。

官方示例锁定了发布时可用的特定包版本。团队应在查看发布说明后有意更新该版本，而不是使用仓库机密自动运行未经审查的安全工具。

核心扫描步骤的简洁表示如下：

- name: 扫描拉取请求更改
env:
OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
BASE_SHA: ${{ github.event.pull_request.base.sha }}
HEAD_SHA: ${{ github.event.pull_request.head.sha }}
SCAN_DIR: ${{ runner.temp }}/codex-security-results
run: |
set -euo pipefail
BASE_REVISION="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"

"$CODEX_SECURITY_BIN" scan . \
--diff "$BASE_REVISION" \
--head "$HEAD_SHA" \
--auth api-key \
--output-dir "$SCAN_DIR" \
--json

> "$RUNNER_TEMP/codex-security.json"

此摘录假定运行器已安装并验证了 CLI，已检出带有完整历史的拉取请求头，并定义了 CODEX_SECURITY_BIN。

对于生产工作流，请使用完整的官方 CI 指南，包括

固定的操作、SARIF 导出、权限、工件保留以及分支安全检查。

Codex Security 在安全体系中的位置

Codex Security 并非要取代所有现有的安全控制措施。

它可以补充以下工具：

• 静态应用安全测试。
• 软件成分分析。
• 密钥扫描。
• 基础设施即代码扫描。
• 容器扫描。
• 依赖项更新。
• 模糊测试。
• 动态应用测试。
• 人工代码审查。
• 渗透测试。
• 漏洞赏金计划。
• 生产环境监控。

其独特优势在于能够跨越仓库结构和系统意图进行上下文推理。

成熟的安全体系可以使用确定性扫描器处理高容量的已知模式，并使用智能体扫描器处理跨文件逻辑、可利用性分析、证据和修复建议。

Codex Security 无法保证的事项

它无法证明仓库是安全的

没有任何扫描器能够证明任意真实世界代码库中不存在所有漏洞。

部分覆盖或未知覆盖使这一局限性更加重要。

验证并非普遍适用

某些发现可以在隔离环境中进行测试。

其他发现则依赖于：

• 生产数据。
• 外部服务。
• 基础设施配置。
• 硬件。
• 凭据。
• 业务逻辑。
• 用户行为。

没有自动化证明的发现并不自动意味着误报，而经过验证的证明也无法揭示该漏洞的所有变体。

人工智能发现仍需人工审查

模型可能误解架构、高估影响、提出不完整的补丁或引入回归问题。

安全负责人应审查证据和修复方案。

开源包仍需调用模型

包源代码是公开的，但默认扫描并非完全不依赖推理访问的本地静态二进制文件。

模型使用可能带来成本、数据处理和授权方面的考量。

敏感输出需要保护

结果目录可能比普通构建输出更为敏感。

请勿将详细的发现、概念验证文件或易受攻击的源代码摘录上传到公共工件中。

网络访问权限受限用途

仅可对您拥有或获得明确授权评估的仓库和系统使用该工具。

OpenAI 的访问控制不能替代法律授权。

安全扫描器也需要威胁模型

Codex Security 最大的概念优势同时也是实际需求。

智能体需要准确的上下文。

仅凭仓库可能无法解释：

• 哪个服务可公开访问。
• 哪个身份提供方受信任。
• 是否存在网络边界。
• 哪些数据是敏感的。
• 上游执行了哪些授权检查。
• 哪个部署功能被禁用。
• 组织接受了哪些风险。

上下文不佳可能导致发现质量不佳。

团队应将可编辑的威胁模型和知识库视为一流的安全资产，而非可选的提示装饰。

常见问题

什么是 Codex Security？

Codex Security 是 OpenAI 的应用安全智能体，用于发现、验证、确定优先级并帮助修复漏洞。它源于内部项目 Aardvark，现已可用。

通过插件、CLI、TypeScript SDK 以及连接仓库的云端工作流实现。

Codex Security 是否完全开源？

CLI 和 TypeScript SDK 已在 GitHub 上以 Apache 2.0 许可证公开发布。底层 OpenAI 模型、托管云服务、受保护发现结果以及不受限制的网络安全访问并未作为开源或开放权重组件发布。

任何人都可以安装并运行 Codex Security 吗？

任何人都可以访问公共软件包，但运行扫描需要 Codex Security 访问权限。某些全仓库扫描或高级网络能力可能还需要“网络安全可信访问”（Trusted Access for Cyber）。

Codex Security 使用哪个模型？

当前 CLI 文档说明扫描默认使用 GPT-5.6 Sol，推理努力级别为 xhigh。用户可以选择其他受支持的模型和努力级别，公共仓库还记录了选定的第三方供应商配置。

Codex Security 可以扫描拉取请求吗？

可以。CLI 可以扫描基础修订版与头修订版之间已提交的更改，因此适用于拉取请求工作流。OpenAI 还提供了官方 GitHub Actions 指南，支持 SARIF 导出和工件保留。

Codex Security 会自动修复漏洞吗？

它可以提出有边界的修复建议，并帮助验证更改是否解决了一个发现结果。扫描默认仅生成报告，人类应在合并或部署前审查、测试并批准补丁。

Codex Security 可以在 Docker 中运行吗？

该仓库包含用于非交互式批量扫描的 Docker 和 Docker Compose 资源。OpenAI 建议使用私有持久存储、密钥管理、受支持的 Linux 隔离功能，以及可选的 AppArmor 加固。

Codex Security 的干净报告能证明我的应用程序是安全的吗？

不能。覆盖范围可能是完整的、部分的或未知的，没有任何自动化扫描器能保证复杂应用程序不存在漏洞。请将 Codex Security 作为更广泛的安全开发计划中的一个环节使用。

相关工具

• Codex Security：插件、CLI、SDK、云扫描器及支持工作流的官方概述。
• Codex Security GitHub 仓库：CLI、TypeScript SDK、Docker 资源和贡献工作流的 Apache-2.0 源代码。
• npm 上的 Codex Security：用于安装 CLI 和 SDK 的已发布软件包。
• Codex CLI：OpenAI 的开源本地编码代理和插件宿主。
• GitHub 代码扫描：GitHub 的 SARIF 兼容漏洞结果接口。
• CodeQL：GitHub 的语义代码分析引擎，用于基于查询的漏洞检测。
• Semgrep：基于规则的静态分析平台，可补充智能体安全审查。
• OWASP Juice Shop：一个故意包含漏洞的应用程序，用于授权安全培训和扫描器评估。

相关链接

• Codex Security 文档：官方

产品接口和工作流的起点。

• Codex Security CLI 快速入门：官方安装、身份验证、扫描、历史记录、预算、批量操作和 Docker 说明。
• Codex Security TypeScript SDK：官方 SDK 设置、扫描生命周期、类型化结果、进度和取消文档。
• 在 CI 中运行 Codex Security：OpenAI 完整的 GitHub Actions 和 SARIF 工作流。
• Codex Security 研究预览：OpenAI 2026 年 3 月的发布文章和预览指标。
• Aardvark 介绍：对后来成为 Codex Security 的智能安全研究员的原始描述。
• Daybreak 安全倡议：OpenAI 2026 年 6 月关于 Codex Security 规模、开源安全工作和防御性网络工具的更新。

摘要

OpenAI 已将 Codex Security CLI 和 TypeScript SDK 开源，为开发者提供了基于 Apache-2.0 的公开基础，用于仓库扫描、变更审查、扫描历史、修复验证、批量活动、SARIF 导出、CI 检查和自定义安全集成。

该智能体不同于基础的模式扫描器，它会构建仓库上下文和威胁模型，在该上下文中搜索漏洞，尽可能验证可疑问题，并针对人工审查提出有边界的修复建议。

该版本并非不受限制的本地安全模型。运行扫描仍需授权的推理访问权限，某些高级网络安全工作流可能需要“网络安全可信访问”。敏感发现和源代码片段也需要谨慎的存储和保留控制。

Codex Security 在分层应用安全计划中最为有用——而非证明仓库无漏洞的依据。

实际变化在于，只要团队在流程中严格落实授权、威胁建模、验证和人工审批，安全审查现在可以更接近 AI 辅助开发的速度。