作者：林岚｜OC 开发者生态编辑

据 OpenAI 的 codex-security 仓库 介绍，公司发布了用于安全扫描工作流的 TypeScript SDK 和命令行工具。开发者可以启动扫描、查找和验证问题、审阅结果，并导出 SARIF、CSV 或 JSON，接入现有代码审查与 CI 流程。

一句话结论：Codex Security 真正要竞争的不是“能生成多少漏洞描述”，而是能否把发现、复现、去重和修复证据做成开发团队愿意持续运行的审计链。

传统静态扫描依赖规则和数据流分析，优点是行为相对稳定，缺点是误报多、跨文件业务逻辑难理解。大模型安全工具试图补上语义判断：阅读代码意图、寻找可利用路径、编写验证步骤，再解释为什么这不是普通代码异味。

codex-security 提供 scan、find、validate 和 review 等工作流，支持 macOS、Linux 与 Windows，要求 Node.js 22 及 Python 3.10 以上；它可以使用 ChatGPT 账户或 API 密钥，并通过 Docker 隔离部分执行。历史记录和 dry-run 则让团队先看计划，再决定是否真正运行。

先别急着激动。Agent 能写出一段看起来合理的攻击说明，不代表漏洞可达、可控或值得优先修复。安全团队最缺的往往不是更多告警，而是证明：攻击者能从哪里进入、需要什么权限、结果能否稳定复现、修复后测试是否转绿。

这也是导出 SARIF 比聊天界面更重要的原因。只有进入代码托管平台、工单系统和基线管理，结果才能被分派、抑制、追踪和复查。反过来，若工具每次扫描都换一种说法，无法稳定关联同一个问题，自动化只会制造新的告警债务。

关键事实

• 来源：OpenAI 官方 GitHub 仓库与开发文档
• 涉及公司：OpenAI
• 核心技术：AI 代码审计、漏洞验证、Docker 隔离、SARIF
• 环境要求：Node.js 22+、Python 3.10+，支持主流桌面系统

OC 判断

Codex Security 的价值取决于验证环节，而不是模型能读多少代码。企业上线前应固定模型版本、记录扫描范围、隔离验证命令，并拿已知漏洞与已知误报做回归集。没有这套评估，AI 安全扫描只会把“规则太多”升级成“自然语言太多”。

为什么重要

• 对开发者：安全检查可能更早进入本地和 PR 流程，但仍要阅读可复现证据。
• 对安全团队：开放 SDK 便于接入现有 AppSec 系统，也增加了评估和权限管理责任。
• 对企业：扫描代码、构建镜像和账户凭证的边界需要在部署前明确。

参考来源

• OpenAI codex-security
• Codex Security documentation