Codex Security：OpenAI 开源了扫描器，把大脑留在 API 后面

2026 年 7 月 28 日，Hacker News 首页冒出一个没有任何官宣的仓库链接。五天后 OpenAI 才发了条推认领，开场白写的是”我们悄悄发布了开源版 Codex Security CLI，但 HN 比我们先找到了它”。这条帖子最后停在 598 分、230 条评论。一个安全工具靠”被发现”出道，这个开局本身就挺有意思。

我真正想聊的不是这段八卦。是这个项目身上最别扭的一点：Apache-2.0 协议，代码全在 GitHub 上，15 个安全技能的提示词一字不落地公开，可你装完跑一次扫描，钱照样进 OpenAI 的账户。开源的是编排层，不是能力层。这打法不新鲜，Codex CLI 也是这么干的。麻烦在于很多人把“开源”直接翻译成“免费、可自建、随便改”，然后对着账单和一堆 refusals 骂街。这两件事从第一天起就不是一回事。

更值得掰开看的是另一层：OpenAI 把过去大半年做安全扫描的工程经验，包括威胁建模、候选发现、沙箱验证、误报追踪、补丁风险评估这一整套流程，全部摆到了台面上。这部分价值跟你最终能不能跑得起来，其实是两码事。

所以这篇文章只想回答一个具体问题：这套东西现在是能进 CI 的工具，还是一个很贵、很有前途、但还没断奶的半成品。

打动我的几个地方

先看它在做什么。一次标准扫描分四步推进：读仓库结构生成可编辑的威胁模型，按这个模型找候选漏洞，把候选丢进隔离沙箱里试着复现，最后给出分流结论。听起来平平无奇，关键在于这四步拆得足够干净。把流程和它底下的模块摆在一起看，层次是这个样子：

图里最该盯的是中间那层。plugins/codex-security/skills 目录下放着 15 个技能目录，从威胁建模、攻击路径分析、候选发现、发现分流，到补丁风险评估、修复验证，全是用 Markdown 写出来的提示词加配套脚本。这些提示词是这次开源里最实在的部分，HN 帖子里有人说这相当于把几十亿 token 的优化成果放进了公共仓库，我觉得这个判断不算夸张。哪怕你一行都不跑，把这 15 个文件读一遍，你对“AI 到底该怎么做安全审计”的理解也会上一个台阶。

第二个打动我的点，是它把扫描当成一个有状态的长周期操作，而不是一条一次性命令。scans compare 能把两次扫描的发现分成新增、持续存在、重新打开、已解决四类；findings false-positive 记下误报理由之后，后续扫描只要理由还成立，就自动压掉同类匹配。

这一层才是它跟”把代码丢给大模型找茬”的真正分水岭。传统 SAST 的死穴从来不是找不出问题，是反复找出你上一次已经判过死刑的问题。scans match 按根因而非按行号做匹配，方向选对了。

第三点是它默认就按多 Agent 跑。内置配置里 features.multi_agent_v2 被强制开启且不允许覆盖，线程上限 9（一个父会话加最多 8 个委派 worker），默认模型 gpt-5.6-sol，推理强度 xhigh。深扫模式另有独立的 discovery worker，配 --stop-after-no-new 这种收敛开关，到点没新东西就停。

架构写得漂亮不等于手感好。不过纸上谈兵到此为止，实际装上跑一遍是什么体验？

跑起来看看

安装三行命令，门槛卡在 Node 版本上，要 22.13.0 及以上（24、26 也行），扫描和导出另需 Python 3.10+。Windows、macOS、Linux 都支持，这点比不少安全工具厚道。

npm install @openai/codex-security
codex-security login
codex-security scan /path/to/directory

CLI 底层跑在 Codex 运行时上，SDK 侧的调用长这样。注意 outputDir 必须在 Git 工作树之外，因为报告里可能包含源码片段、漏洞细节和复现步骤：

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

const security = new CodexSecurity();
const result = await security.run("/path/to/repository", {
  mode: "deep",
  workers: 2,
  maxTimeHours: 1.5,
  maxCostUsd: 5,
});
console.log(result.reportPath);
await security.close();

一次扫描在内部是这样推进的，从威胁建模一路走到分流结论，四个阶段环环相扣：

第四阶段的分流结论有四种：reportable、suppressed、not_applicable、deferred。deferred 的意思是证据不足，不是没问题。看报告时把这个词当成“安全”，你会吃大亏。进 CI 的姿势文档写得很明确，扫 diff、输出 JSON、按严重级别给退出码：

SCAN_ROOT="$(mktemp -d)"
npx @openai/codex-security scan . \
  --diff origin/main \
  --output-dir "$SCAN_ROOT/results" \
  --json \
  --fail-on-severity high > "$SCAN_ROOT/findings.json"

退出码语义值得背下来：0 是完成或策略通过，1 是策略违规，2 是输入无效、覆盖不全或运行时出错。把 1 和 2 混为一谈，你的流水线会在扫描失败时静默放行，这是最危险的一种配置。上面这几条还只是入门，完整的命令面还铺了这么几类能力：

• bulk-scan：按 CSV 批量扫组织内仓库
• validate：把单条发现丢进沙箱单独验证
• patch：生成候选补丁，可选附带开 draft PR
• verify-fix：回头确认修复是不是真堵上了
• export：导出 CSV、JSON 或 SARIF
• publish scan：推到 Cloud、Linear 或自建 findings 服务
• install-hook：挂 git 钩子，提交前拦高危

终端里的实际操作大致是这个画风，从安装到扫描，再到结果比对和导出：

跑完之后你手上有 report.md、findings.json 和可导出的 SARIF，退出码决定流水线走不走。功能看着铺得挺满，但“能跑”和“该在哪跑”完全是两件事，往下看我给的边界。

什么时候用，什么时候别用

判断的前提是先认清一件事：这是白盒静态审计，不是渗透测试。它读源码、推理数据流和业务逻辑，不去打一个跑起来的系统。跟 Strix 那种动态攻击型工具不是同类工具，互补大于竞争。

不适用的一侧同样清楚。有硬性数据不出网要求的团队，这条路基本堵死，--provider amazon-bedrock 是唯一的体面退路，而 Azure OpenAI 支持到发稿时还在 PR 阶段没合进去。

再说个坑。默认配置是 gpt-5.6-sol 加 xhigh 推理强度，这是最贵的档位。HN 上有人在小仓库上跑了一次，将近一小时，烧掉 Pro 套餐周额度的一半，最后因为扫描期间仓库 HEAD 变了而中断。另一位 API 用户报告失败的一次扫描烧掉 100 多美元。--max-cost 也不是硬闸，文档写得很诚实：估算用的是标准 API token 价格，在途请求会跑完，所以实际可以超。把它当保险丝，别当上限。

还有个更隐蔽的问题。内置运行时配置里 approval_policy = "on-request"、approvals_reviewer = "auto_review"，codex_security_scan profile 允许跨本地文件系统读取。也就是说扫描进程理论上能读到同账号下的其他凭据。要收紧就显式设 approval_policy = "never"，别指望默认值保护你。文档层面已经铺到这个程度了，维护侧跟不跟得上？

维护靠不靠谱

发布节奏快得有点吓人。8 月 16 日到 8 月 29 日两周内发了 10 个版本，最近的一次提交距今不到 24 小时。这种速度说明团队在拿真实反馈硬推，也说明你今天锁定的行为，下周可能就变了。

贡献者结构是个更实在的风险点。前 30 名贡献者里，排第一的 mldangelo-oai 一个人 203 次提交，第二 ianw-oai 87 次，再往后是 42、28、19。外部贡献多数是单次提交。这是个典型的公司项目，不是社区项目。

好在核心维护者在 HN 上的响应不像大公司做派。开场最高票的评论是 shooker435 的一句”Just getting auth issues so far…”，Michael D’Angelo（OpenAI，同时是 Promptfoo 联创）当天就在下面认了，说修复已合并进 0.1.1（PR #22），还给了临时绕过方法。这种响应速度在万星项目里不多见。

另一个高频抱怨是护栏拒绝。minraws 在帖子里说”I seem to have gotten a bunch of ‘you are trying to stuff we don’t allow’ errors”，D’Angelo 的回答很坦白：CLI 不做仓库归属校验，公开项目都支持，审你自己的 Linux 内核补丁正是他们想支持的防御性工作，拒绝来自模型护栏，“which can be overly cautious”。

绕开它的唯一办法是申请 Trusted Access for Cyber。一个安全扫描器的本职工作就是解释漏洞，却跑在一个被训练成不要解释漏洞的模型上，然后用一张访问白名单打补丁。这个设计很荒诞，但它不是 Codex 独有的问题。工程细节做得扎实，护栏和成本这两道坎却都卡在模型侧，我怎么看这个项目？

我的真实看法

先给结论：值得跟，但跟法要对。你该把它当成一个可以读、可以抄、可以小规模试的安全工程范本，而不是一个能替你背 CI 门禁的生产依赖。

我一开始的预设是”这不过是个套在模型上的 CI 壳”。HN 上 petesergeant 也是这么说的，不过他补了一句”there’s a little bit more meat here”，指向的就是那 15 个技能目录。翻完之后我得承认自己看走眼了：真正值钱的是状态层，不是提示词。这些设计单个看都不稀奇，难得的是它们被拼成了一套闭环：

• scans match 按根因匹配，不按行号匹配
• findings false-positive 把误报理由继承到后续扫描
• scans compare 做新增、持续、重开、已解决四分类
• 深扫用 --stop-after-no-new 主动收敛
• --max-cost 做成本熔断
• verify-fix 回头确认修复是不是真的生效

这一整套东西做的都是同一件事：让“扫描”从一次性动作变成可累积的资产。

HN 上 knighthacker 的判断我完全同意：扫描器本身是最不值钱的部分，外围这套跨运行去重、误报追踪、预算控制、CI 卡点的 harness 才是产品。而 OpenAI 招人的岗位名写的是”full-stack software engineer, cybersecurity products”，方向对得上。

要泼的冷水在成本这一侧。社区里 iancarroll 抱怨”CLI 输出在扫描过程中没什么信息量，希望能显示 token 用量和进度”，D’Angelo 回”Agreed! This is near the top of our priority list”。到 0.1.24 为止，进度和成本可见性依然是短板。一次扫描烧掉几百块还只拿到部分结果，这种体验进不了 CI。

竞品维度上，最接近的参照是 Anthropic 在 2026 年 7 月 22 日发布的 Claude Security 插件，比 Codex Security 上 HN 还早六天。两家下了相反的注：OpenAI 做组织级批量扫描、开源了提示词、把服务继续关在门后；Anthropic 做提交前的开发者闭环、不开源、但跑在你已经付费的 Claude 推理上。长期看我更看好提交时这个时机，因为修问题最便宜的时刻永远是它还没落地的那一刻。

还有一件事得说清楚。中文媒体在传一组对比数字，说某第三方测试里 Codex Security 真阳性率 74%，Snyk 28%，Semgrep 20%。我没找到这组数据的原始出处，目前的公开数字（30 天扫 120 万次提交、792 个 critical、10,561 个 high、14 个 CVE）全部是 OpenAI 自己在研究预览期发的。别拿这组对比做选型依据。

资源地址

先读技能，再决定要不要跑

如果你只有半小时，别装 CLI。直接去读 plugins/codex-security/skills 那 15 个目录。 threat-model、finding-discovery、validation、triage-finding、assess-patch-risk 这几个文件，基本就是一份公开的 AI 安全审计方法论。这部分是纯赚的，零成本，也不需要申请任何访问权限。

如果你打算真跑，我的建议是三条：先拿一个小仓库、把 --max-cost 设成你能承受的绝对损失额、在 CI 里锁死版本号。0.1.24 这个版本号意味着 1.0.0 之前小版本可以改公开 API，不锁版本等于给自己埋雷。

至于要不要替掉 Semgrep 或者 Snyk，答案是别。规则引擎和 LLM 推理抓的是不同类别的问题，前者稳定可回归，后者能抓跨文件逻辑漏洞但不可复现。把它们叠起来，别做二选一。这个项目的定位应该是你现有扫描栈上面那层补盲，而不是替代品。