摘要：OpenAI 将 Codex Security 命令行工具和 TypeScript SDK 开源。开发者可以在本地工作流中扫描代码仓库、验证漏洞并生成修复建议。AI 安全工具降低了代码审计门槛，也可能带来大量误报、重复报告和责任不清。
OpenAI 在 7 月开源 Codex Security CLI 及其 TypeScript SDK。
这套工具面向开发者和安全团队，用于发现、验证和修复自有代码中的安全漏洞。项目采用 Apache 2.0 许可证发布，可以接入命令行、开发工具和持续集成流程。
Codex Security 与传统静态代码扫描工具的工作方式有所不同。
传统扫描器依赖预先编写的规则，检查危险函数、依赖版本和常见错误模式。
Codex Security 会先阅读代码仓库结构、功能说明和上下文，再根据自然语言定义的安全技能寻找漏洞。发现问题后，它还可以尝试验证漏洞是否能够触发，并提出修复方案。
安全扫描开始进入代码语义层
很多漏洞无法通过单行规则发现。
一个接口单独看没有问题，和另一个权限模块组合后可能绕过身份校验。一个数据库查询使用了参数化语句，上游拼接逻辑却可能引入新的输入路径。
语言模型能够跨文件阅读代码，理解函数关系和业务意图，因此适合发现这类上下文漏洞。
Codex Security 还允许团队编写自己的安全技能。
金融系统可以重点检查资金转账和权限升级，工业软件可以检查控制参数、远程接口和设备认证，医疗系统则可以加强患者数据和访问记录审查。
安全知识由此从固定扫描规则，扩展为可复用的自然语言检查规范。
漏洞发现数量可能快速增长
工具门槛降低后，更多开发者能够对开源项目和企业代码进行安全检查。
这会增加有效漏洞的发现数量，也会制造大量误报和重复报告。
Linux 内核社区已经遇到类似压力。自动化工具生成的漏洞报告数量不断增长，维护者需要花费大量时间确认问题是否存在、能否复现，以及是否已经被其他人提交。
一个未经验证的报告，看起来可能非常专业，实际却无法触发。维护者阅读、回复和关闭这些报告的成本，最终由开源社区承担。
因此，AI 扫描工具的价值不能只按“发现了多少漏洞”计算。
报告是否包含复现步骤、影响范围、修复补丁和人工分析，更能决定它是否有用。
人工责任不能交给模型
一项针对 1000 个热门 GitHub 仓库的研究发现，研究人员识别出 118 项与 AI 贡献有关的政策。
其中 78% 允许使用 AI 辅助，51% 要求披露 AI 参与情况，74% 明确要求人工参与和复核。
这些数字反映了开源社区正在形成的基本原则：工具可以生成代码和报告，提交者需要理解内容，并对结果负责。
模型无法承担法律责任，也不会长期维护补丁。
一段 AI 生成的修复代码可能消除当前漏洞，同时引入性能下降、兼容性问题或新的安全缺口。提交者必须完成测试、解释设计选择，并在后续版本中处理问题。
“模型说这里有漏洞”无法成为完整证据。
企业需要建立漏洞验证流水线
企业接入 Codex Security 后，可以把流程分成四个阶段。
第一阶段由 AI 扫描代码，生成候选问题。
第二阶段在隔离环境中验证漏洞，确认输入条件、攻击路径和影响范围。
第三阶段由开发人员检查修复方案，并运行单元测试、回归测试和性能测试。
第四阶段由安全负责人完成风险分级和发布审批。
对于关键基础设施和工业控制软件，还需要记录模型版本、扫描规则、验证环境和人工签字人。
这套记录能够帮助企业回答：漏洞由谁发现，谁确认，谁决定修复，以及补丁为什么可以进入生产环境。
开源让工具本身也接受检查
Codex Security 开源后，社区可以检查其技能定义、调用逻辑和数据处理方式。
企业能够了解工具向模型发送了哪些信息，也可以根据内部安全要求修改流程。
开源还方便国产模型和本地推理服务进行适配。对代码不能离开内网的企业来说，本地部署和可审计性非常重要。
同时，开源工具仍可能依赖外部模型服务。企业在使用前需要确认代码是否上传、日志保留多久、模型提供商能否访问扫描内容。
AI安全工具进入责任阶段
过去两年，AI 编程工具的宣传重点集中在提高开发速度。
随着生成代码进入核心系统，行业开始关注另一组问题：谁验证代码，谁维护代码，出现事故后谁承担责任。
Codex Security 能够扩大安全团队的检查范围，也会增加对人工判断的需求。
未来优秀的安全工程师不一定亲自阅读每一行代码，但需要判断模型发现的问题是否成立，修复方案是否合理，以及工具遗漏了哪些业务风险。
AI 可以承担大量搜索工作。
漏洞进入报告、补丁进入代码库、版本进入生产系统时，仍然需要一个明确的人签字。