AI 会找漏洞后，我给它加了一条“证据链”

墨舟 2026-08-13 13:31 浙江

以下文章来源于：一个会聊天的树洞

我是一个会聊天的树洞，你可以尽情的向我倾诉！我的智商虽然很低，但我不是坏人~

从 Codex Security 的动态出发，分享一套把 AI 代码审查变成可复核证据链的实战方法：收窄问题、索取路径、验证补丁、渐进接入流程。

“AI 能把补丁写得很快，但它不能替我们决定：这个补丁究竟修复了什么。”

今天翻到 OpenAI 官方 GitHub 的更新：codex-security 被列为可用于发现、验证和修复安全漏洞的 Codex Security CLI 与 TypeScript SDK。我的第一反应很职业，也很不高尚：太好了，终于有人可以替我多看几眼那些我不想看的代码。

但第二反应随即赶到：它看得快，不等于它替我负责。AI 编程进入“会找漏洞”的阶段后，最值钱的技巧可能不是再收集一套神奇提示词，而是把每一次 AI 审查，变成一条能被人类复查的证据链。

“帮我审一下这个仓库有没有安全问题”是一个很省事的提问，也往往得到一份很难落地的答案。模型会尽力覆盖常见风险，但项目边界、鉴权假设、数据流和部署方式都被你藏在了空气里。空气通常不参与上线，也不参与背锅。

我现在更愿意先把审查任务缩成一个可验证的命题。比如：未登录用户能否通过某个导出接口读取其他租户的数据；回调 URL 是否可能被用来访问内网；这次依赖升级有没有把用户输入重新送进命令执行路径。问题越具体，AI 给出的线索越容易被测试、日志和代码调用链证伪或证实。

这不是限制模型，而是给它一张地图。安全审查不是“发现几个关键词”的竞赛，真正的漏洞通常住在两个看似无害的模块之间。

一个对我有用的 AI 审查输出，至少包含四件事：具体文件与代码位置，攻击者需要满足的前提，从输入到敏感操作的完整路径，以及最小复现或验证思路。缺少其中任意一项，它仍然可能是好建议，却还不够资格进入待修复队列。

我会在提问里直接要求它区分“已证实”“高概率”和“只是猜测”。这一步看上去像在给模型出作文题，实际是在保护自己的注意力。毕竟我们已经有足够多的告警；再加一位语气坚定的实习生，并不会自动增加真相。

AI 很擅长给出“看起来合理”的补丁。危险在于，补丁有时只是把风险挪了一个文件，或者用更严的校验把真实用户也挡在门外。拿到修复建议后，我会反过来问：它改变了哪个安全不变量？哪些正常路径会受影响？请补一条能证明漏洞被堵住、又不误伤正常行为的测试。

这里的关键不是让 AI 多写测试，而是让测试服务于明确的安全断言。比如“跨租户资源永远不能被当前会话读取”，比“覆盖这个 controller”更接近我们真正想守住的东西。前者失败时，你知道该紧张；后者失败时，你通常只知道 CI 又在闹情绪。

OpenAI 官方组织页显示，Codex Security 同时提供 CLI 和 TypeScript SDK，这本身就是一个清晰的工程信号：安全能力可以进入本地开发与自动化流程，而不只是一段聊天记录。对团队来说，最合适的落点通常是变更集中、风险更高的路径，例如鉴权、文件处理、外部请求、反序列化和密钥相关代码。

我不会一上来让它给整个历史仓库“算命”。更稳的做法是在一个小服务或一个敏感目录试跑，记录命中率、误报类型和人工复核时间；只把经过验证的规则与提问模板沉淀下来。这样 AI 带来的不是一座新的告警火山，而是一条逐渐可靠的审查辅助线。

写代码时，我们欢迎它帮忙；审代码时，我们更该要求它说明白。能被复现的发现，才配得上被优先修复。剩下那些漂亮但模糊的结论，就让它们和我凌晨两点的自信一起，先在草稿箱里冷静一会儿。

参考：OpenAI 官方 GitHub 组织页（2026 年 8 月 13 日浏览，确认 codex-security 的项目描述与当日更新状态）。

参考：openai/codex-security 项目页（项目定位为用于发现、验证和修复安全漏洞的 CLI 与 TypeScript SDK；页面访问受网络波动影响，本文未引用未经复核的配置与性能细节）。

阅读原文

跳转微信打开