Codex Security 安全披露与威胁模型指南：漏洞报告范围、本地信任边界与扫描安全实践

• 应用安全
• 漏洞扫描
• AI 应用

Codex Security（@openai/codex-securityCLI 与 TypeScript SDK）是一款在本地运行、用于审查你信任且有权评估的代码仓库的安全工具。本文基于仓库根目录的 SECURITY.md 整理其官方安全策略，详细说明哪些安全问题在报告范围内、如何私下报告、产品的威胁模型与安全边界，并结合仓库源码（config.ts、api.ts、executor.ts）解释扫描运行时权限配置的底层实现。读完本文，你将掌握：如何正确提交一个可被受理的漏洞报告、哪些报告会被视为不在范围内，以及如何在本地安全地运行代码扫描。

一、安全策略的适用范围

该安全策略适用于以下全部组件，任何一项出现安全缺陷都在报告考量范围内：

• 已发布的@openai/codex-securitynpm 包与codex-securityCLI；
• TypeScript SDK，包括目标选择（target selection）、认证（authentication）、配置（configuration）、执行（execution）与结果校验（result validation）；
• 官方发行版捆绑的 Codex Security 插件、解释器（interpreter）与 Codex 运行时；
• 扫描输出，包括 manifest、findings、coverage、报告、SARIF 与扫描历史（scan history）；
• 官方包、构建与发布的完整性（package/build/release integrity）。

提交报告前，请先确认问题影响的是最新发布的包或当前默认分支；报告中应包含包版本，并在相关时注明 commit、插件版本和操作系统。如果问题存在于旧版本，请说明受支持的发行版是否同样受影响。

二、威胁模型：一个本地信任模型

2.1 运行前提

Codex Security 在你的本地操作系统账号下运行，因此只应扫描你信任、且自己拥有或获得明确授权评估的仓库。需要特别强调的是：拥有评估某仓库的权限，不代表你可以信任该仓库。

你选择的仓库、Git 安装以及你选择的工具和配置，都会以你现有的本地权限运行。常规 Git 操作会使用仓库配置、hooks、filters、attributes、凭据助手（credential helpers）、worktrees 以及PATH上的可执行文件——这些都不是独立的安全边界。

2.2 本地信任与攻击者前提

• 产品不隔离共享同一操作系统账号、凭据或本地状态的用户、任务、仓库或扫描作业，因此不要将共享本地状态视为多用户或多租户系统。
• 私有 Codex 状态、工作台数据库（workbench databases）、输出目录和恢复凭证（resume receipts）与你的操作系统账号之间没有独立安全边界。如果报告依赖更改这些内容，必须证明攻击者可控的输入如何通过受支持的工作流到达它们，并跨越某个安全边界。

2.3 “信任”的边界

信任一个仓库并不授权无关操作。仓库内容、文件名、符号链接、模型输出、补丁、服务响应和导入的工件都只是数据，它们不授权：另一个目标、更宽的作用域、不同的凭据、无关的读写、未经批准的补丁或网络目的地、被绕过的限制，或为不完整覆盖率给出“通过”的结果。

三、扫描如何运行：运行时权限的源码级解析

每次扫描使用产品内置的codex_security_scan文件系统 profile 和自动审批审查（automatic approval review）。基线 profile 允许读取本地文件系统、写入工作区根目录和选定的扫描状态目录。请求会被自动审查（无需交互式提示）；被批准的请求可以为特定操作授予额外权限。

提示：设置approval_policy="never"可拒绝所有请求。

这一策略在 SDK 源码中有明确实现。在 api.ts 中定义了权限 profile 常量：

const SCAN_PERMISSION_PROFILE = "codex_security_scan"; const POLICY_PERMISSION_PROFILE = "codex_security_policy";

scanRuntimeCodexConfig()（api.ts）是扫描会话运行时配置的核心，它做了三件关键的事：

1. 删除sandbox_mode、approvals_reviewer，并遍历删除所有 profile 中的approval_policy、approvals_reviewer、default_permissions、permissions、sandbox_mode；
2. 强制写入approval_policy（来自scanApprovalPolicy的运算结果）与approvals_reviewer: "auto_review"；
3. 注入codex_security_scan权限 profile：文件系统上:root只读、:workspace_roots可写（以及受保护的凭据主目录只读），并设置allow_login_shell: false。

3.1 审批策略的判定逻辑

scanApprovalPolicy()（config.ts）决定最终审批策略：

export function scanApprovalPolicy( config: Readonly<JsonObject>, ): "never" | "on-request" { return config["approval_policy"] === "never" || selectedScanProfile(config)?.["approval_policy"] === "never" ? "never" : "on-request"; }

即：只要当前配置或所选 profile 中存在approval_policy="never"，最终生效的就是never（拒绝一切）；否则默认回落到on-request。默认配置DEFAULT_CODEX_CONFIG（config.ts）也印证了这一点：approval_policy: "on-request"、approvals_reviewer: "auto_review"。

3.2 为什么--codex与codexOverrides无法替换安全基线

SECURITY.md 明确指出：通过--codex或 SDKcodexOverrides设置approval_policy、approvals_reviewer、sandbox_mode或 permissions，不能替换自动审查器或基线文件系统 profile。源码证实了这一设计：scanRuntimeCodexConfig()在注入基线 profile 之前会主动删除上述键，确保扫描会话始终使用产品自身的codex_security_scan权限体系。但严格的approval_policy="never"覆盖（包括所选 profile 中的）会被保留；保存的扫描保留其有效审批策略，旧扫描在重跑时仍然保持“全部拒绝”（deny-all）。

值得补充的是，策略生成路径policyCodexConfig()（api.ts）甚至更严格：它固定approval_policy: "never"、禁用插件/apps/shell 快照、关闭 web 搜索与网络访问，用于生成安全策略时与模型的最小权限交互。另外 config.ts 中的validateOverrideKeys会拒绝__proto__、constructor、prototype等危险键，防止原型污染；validateOverrides（config.ts）则禁止通过 overrides 篡改插件加载配置。

3.3 子进程环境继承

扫描与工作台子进程可以继承你的环境变量。工作台会移除OPENAI_API_KEY和CODEX_API_KEY，但不会移除所有凭据——GITHUB_TOKEN、AWS_SECRET_ACCESS_KEY等其他变量仍可能对本地子进程可用。相关行为在 deep scan worker 实现中可见：executor.ts（[plugins/codex-security/mcp-app/src/deep-scan/executor.ts#L78-L87)）会读取OPENAI_API_KEY、CODEX_API_KEY并决定是否回退到 API key 认证；其测试（test_mcp_app_smoke.mjs）也覆盖了这些环境变量的场景。

实操建议：只给扫描提供其所需的环境凭据（Run a scan with only the environment credentials it needs）。

四、安全边界：什么才算越界

一个安全问题必须跨越产品实际提供的边界才有效。SECURITY.md 列出的边界包括：

• 只扫描选定的目标和请求的作用域；只写入授权的输出路径；
• 遵守显式选择的凭据和文档化的成本控制；
• 未经操作者授权，不得把凭据、私有源码和扫描结果送入模型请求、日志、报告或网络目的地；
• 应用扫描实际的文件系统与执行 profile，并尊重独立于扫描强制执行的主机或网络限制（例如 Docker 场景下，docker/codex-security-seccomp.json 与 docker/codex-security.apparmor 即属于这类独立限制）；
• 不通过符号链接或替换文件进入未授权的读/写；
• 仅当扫描结果与审查的作用域、文档化模式和声明的排除项一致时，才标记扫描完成；
• 保护官方包、捆绑运行时、依赖、构建产物与发布凭据免受未授权更改。

五、范围内的报告（In-scope reports）

请报告官方发行版中可复现的问题，例如：

• 凭据、私有源码或扫描结果在未经授权的情况下被发送到另一个安全主体、模型请求或网络目的地；
• 模型或远程输入绕过了扫描的有效权限，或绕过了独立强制执行的主机、执行、文件系统或网络限制；
• 扫描、补丁、文件写入或网络请求超出了你授权的操作；
• 忽略了你明确选择的目标、路径作用域、凭据或文档化的成本限制；
• 路径穿越（path traversal）、符号链接、压缩包或文件替换竞态，导致写入批准的输出目录之外，或将无关本地文件发送给模型；
• 不完整、伪造或作用域错误的扫描被当作完整结果或通过 CI 的结果接受；
• GitHub、包、更新、依赖或模型服务的输入导致未授权的本地操作或危害发行版；
• 已发布包、捆绑运行时、构建或发布流程中可达的漏洞；
• 资源耗尽（resource exhaustion）到达受支持的服务、CI 进程或其他实际可用性边界。

六、通常不在范围内（Usually out of scope）

以下情形本身不构成安全漏洞：

• 在你授予的权限内读取所选仓库文件、解析 worktrees、运行 Git、使用配置的 hooks、filters、凭据助手和可执行文件；
• 假设已预先控制你的操作系统账号、受信任的本地 Git 设置、私有 Codex 状态或私有扫描输出，却没有证明受支持的输入如何获得该控制权；
• 依赖你主动授予插件、解释器或可执行文件你账号本已拥有的权限；
• 已共享你的账号和本地状态的进程访问、取消或修改私有扫描状态、工作台数据库、结果、恢复凭证或扫描历史；
• 提示注入（prompt injection）、意外模型输出、漏报、误报，或未签名审查凭证——只要它们没有跨越边界、也没有导致受支持的安全门接受不完整或被歪曲的覆盖率；
• 在扫描及其结果中如实反映的文档化排除项、忽略规则、估算或 Git 行为；
• 已披露的估算不确定性，或明确请求的限制仍按文档强制执行时不可避免的进行中成本超支；
• 没有在受支持的终端中证明安全影响的终端格式化或控制字符；
• 在没有“从不可信输入到受保护发布或绕过其完整性控制”路径的情况下，假设受信任的发布运行器、registry 或依赖供应商被攻破；
• 没有对受支持发行版产生可复现影响的依赖公告、理论攻击或旧包版本；
• 你主动选择的文件、文档或仓库处理缓慢；
• 被扫描的第三方仓库中的漏洞；
• 已发布运行时或发布流程无法到达的文档、测试、fixtures 或开发代码。

托管服务、多用户安装、PR CI 和导入的第三方工件可能具有不同的信任边界。对于这些情况，请明确部署方式、攻击者可控输入、受影响组件和实际边界。另外要注意：存储多个本地扫描并不会使 CLI 变成多租户系统。如果不确定发现是否在范围内，请私下报告。

七、报告应包含的内容

提交报告时请包含：

• 受影响的组件、包版本、插件版本和 commit；
• 你的平台、认证方式、扫描模式和目标类型；
• 攻击者的起始权限以及跨越的安全边界；
• 在受支持发行版或默认分支上复现问题的最小步骤；
• 预期行为与实际行为、影响以及任何已知缓解措施；
• 复现问题所需的脱敏日志或扫描工件。

报告内容清理要求：除非私有报告确实需要且你被授权共享，否则请移除 API keys、访问令牌、客户数据和私有源码；绝不要在 PoC 中包含实时凭据。

八、扫描仓库中发现漏洞如何报告

如果扫描在他人仓库中发现了漏洞，请遵循该项目的安全策略，并且只与授权人员共享该发现。OpenAI 的 Bugcrowd 项目只覆盖 OpenAI 的产品与服务，不覆盖其他项目中的漏洞。

九、安全运行扫描的实操清单

SECURITY.md 给出的安全扫描实践可归纳为以下清单：

1. 只扫描你信任、且自己拥有或获得明确授权评估的仓库；
2. 应用补丁或合并前，先审查仓库说明并检查补丁内容；
3. 只传入扫描所需的凭据（本地子进程可能继承其他环境变量）；
4. 将凭据和 Codex home（CODEX_HOME，默认~/.codex）放在仓库目录之外；
5. 将扫描状态、findings、报告、日志和 SARIF 存放在外围 Git worktree 之外；
6. 限制结果的访问、设定保留期限，并在共享或上传前审查；
7. 保持包、运行时和依赖处于最新状态。

结合源码补充一个细节：SDK 写入 Codex 配置文件时使用writeCodexConfig()（config.ts），它以0o600权限创建临时文件、写盘、sync后原子重命名，并且父目录权限为0o700——这体现了“凭据与私有配置不落入他人可读范围”的实现级保障。

十、延伸阅读

• 扫描契约与工件格式：scan-contract.md、scan-artifacts.md
• 扫描配置与预检：config-preflight.md
• 插件能力 profile 与运行时路由：capability-profiles.toml
• 运行时安全配置实现：api.ts、config.ts
• 容器隔离辅助配置：docker/codex-security-seccomp.json、docker/codex-security.apparmor

关于 Codex 沙箱、审批与网络控制的更详细信息，以及 CVE 分配与披露时间线的官方说明，可查阅 OpenAI 公开发布的对应政策页面；本文所有配置与行为描述均以当前仓库源码和 SECURITY.md 为准。

• 应用安全
• 漏洞扫描
• AI 应用