Tibo刚开源漏洞扫描器，第一件事不是让Codex修

Tibo刚开源漏洞扫描器，第一件事不是让Codex修

安全工具里最危险的按钮，往往不是“开始扫描”，而是“全部修复”。

Tibo 刚公开了一套开源 CLI 和 TypeScript SDK：它可以扫描代码仓库、检查变更、持续追踪发现结果，也能接进 CI。对 Codex 用户来说，这当然很诱人——既然 AI 能找到问题，也能写补丁，为什么不让它从扫描一路跑到合并？

我的判断恰好相反：

第一次接入时，只让它找，不要让它改。

不是因为 Codex 不会修，而是“发现漏洞”“证明漏洞”“修好漏洞”“确认没有引入新问题”，本来就是四种不同责任。把四步压成一个按钮，速度最快，也最容易把一次安全升级变成生产事故。

它真正补上的，是安全工作的连续性

传统扫描器并不少。真正折磨团队的是，报告常常停在一份越来越长的列表里：旧问题重复出现、修复后没有复查，CI 只告诉你“失败”，却不解释它为什么值得阻断合并。

这次开源工具把扫描仓库、审查变更、追踪发现和 CI 检查串起来，价值不在“又多一个扫描器”，而在于把一次性报告改造成连续闭环。

但连续不等于全自动。

OpenAI 对 Codex Security 的公开说明同样把流程拆成寻找、验证、修复、再次验证。没有验证的“高危”只是信号；没有复查的“已修复”也只是一份看起来合理的补丁。

为什么“自动修复全部”特别危险

代码安全不是语法纠错。一个权限判断看起来少了校验，可能是漏洞，也可能由上游网关统一拦截；一个硬编码字符串看起来像密钥，可能只是测试夹具。

AI 看不到完整部署结构和业务数据流时，既可能为了消除告警而破坏正常权限，也可能交出“测试通过、语义却变了”的补丁。支付回调不再重复入账，但补偿任务也无法重试，就是典型例子。

所以我不会给安全 Agent 一个“把所有问题修完”的目标。我会把目标改成：

只读扫描；给出证据、攻击路径、影响范围和复现条件。没有证据的项目标为“待确认”，不得改代码。

我会这样接进仓库：先跑五步闭环

第一步，建立只读基线。

第一次全仓扫描不改文件，只输出结构化清单：位置、等级、攻击条件、影响和证据。

第二步，只验证 P0 和 P1。

先挑权限绕过、密钥泄露、远程执行、支付与数据越权。验证必须在隔离分支或沙箱里完成，不接生产凭证，不允许任意出网。

第三步，让 Codex 只提交最小补丁。

要求它保持接口不变、避免顺手重构，并把测试一起交付。补丁越小，人越容易审。

第四步，测试与二次扫描一起过。

测试证明旧功能还在，二次扫描证明攻击路径已切断。缺一个，都不能叫修复完成。

第五步，人决定是否合并。

AI 给建议和证据；权限边界、业务损失与上线窗口仍由责任人签字。

五类目录，我会永久保留人工闸门

并不是所有代码都需要同样严格。

普通展示页面、低风险工具函数，可以让 Codex 自动生成补丁并跑测试；下面五类则只允许生成候选补丁：

登录、角色、租户隔离与权限判断；

支付、退款、余额和账务；

加密、签名、令牌与密钥管理；

数据库结构变更与数据回填；

CI、依赖安装、构建脚本和发布权限。

它们的共同点不是“复杂”，而是出错后很难靠回滚恢复。钱已多退、数据已越权、密钥已进日志，代码回到上一版也收不回后果。

接入前，用这张清单验收

准备把安全 CLI 或 SDK 接进 CI 时，我会先回答七个问题：

扫描默认是否只读？

模型能看到哪些目录，是否会读到真实密钥？

验证环境能否访问公网、生产数据库或内部服务？

每条高危是否有证据和复现条件？

修复是否是最小补丁，并且附带测试？

重试会不会重复创建评论、工单或提交？

谁拥有最终合并与上线权限？

任何一项答不上来，就先别追求“全自动”。安全自动化不是让人消失，而是让人只在真正需要判断的地方出现。

顺手看一眼你的 Codex 状态

长时间扫描、验证和修复都很吃额度。如果你同时在用 Codex，可以从下面的真实页面进入「重置雷达」，查看未来 24 小时研判与个人额度趋势。

点击进入「重置雷达」小程序

真正成熟的用法，不是让 Codex 按下“全部修复”，而是让它把证据准备清楚，让人更快、更有把握地做决定。

资料依据：Tibo 7 月 28 日公开说明；OpenAI Codex Security 公开文档。具体包名、命令和兼容版本以项目仓库当期说明为准。