用 AI 写产品上线前，我是怎么给项目做一次彻底安全扫描的

最近一位国内开发者分享了他自己的一段经历：他用 AI 辅助写了一个上线两个月的小工具，结果上线第一周就被扫描攻击找出了好几个高危漏洞，最危险的一个是鉴权逻辑被绕过。这次教训让他意识到，对独立开发者来说，「能用 AI 写出产品」只是第一步，「让产品扛得住基础扫描」是第二步。他后来用一套最近刚开源的 AI 安全扫描工具给自己从头扫了一遍，结果一个多小时跑完，找出了 21 个安全问题。

这位开发者做的事情在今天越来越普遍：自己不是专业程序员，靠 AI 助手把一个想法做成可运行的产品，再部署到云服务器上对外提供服务。门槛低、上线快、迭代灵活，是这种开发方式最大的优势。但它的反面是，绝大多数独立开发者并没有受过系统的安全训练，对常见的漏洞类型、攻击路径几乎没有概念。结果就是产品功能没问题，但代码里到处是给攻击者留的后门。

他上个月刚开始做这个工具的时候根本没想过安全。他让 AI 写了一个有用户登录、有数据存储、有后端调用接口的小产品，自测了一下功能正常就直接上线了。运营了不到一周，云厂商就发来一封告警邮件：你的服务正在被大量扫描请求攻击，建议立即排查。

他当时还想着「是不是夸大其词」，结果打开日志一看：来自不同 IP 的扫描请求每秒钟就有一两次，每条请求都在尝试不同的注入参数、不同的鉴权绕过路径。这位开发者第一次直观地感受到了「互联网上有多少人在盯着公网服务」。

他花了几天时间手忙脚乱地修补漏洞，最严重的一个就是鉴权被绕过——代码查询了第二层授权，但真正放行的时候没有使用这个结果，导致任何通过第一层登录的用户都能直接访问受限接口。这个漏洞他自己看代码是看不出来的，但扫描工具一跑就直接定位到了具体函数和行号。这次教训之后，他开始认真研究「产品上线之前到底应该怎么排查安全」。

刚好这一周，有家头部 AI 公司开源了一套专门给 AI 生成项目用的安全扫描插件。这个插件最早可以追溯到 2025 年 10 月发布的 Aardvark 项目。当时它被描述为「由 GPT-5 驱动的智能安全研究员」，能自动阅读代码、寻找漏洞、验证风险，并提出修复方案。后来这套能力更名为现在这个名字，被整合进该公司的开发者工具产品里。2026 年 6 月，它又迎来了一次重要升级，深度扫描、攻击路径追踪、威胁模型构建、漏洞验证和补丁生成等完整流程，都可以通过命令行工具直接调用。

过去这套能力是封闭在那家公司自己的生态里使用的。这次开源之后，它开始变成任何开发助手都能调用的开放工具。无论你用的是哪款主流 AI 编程助手，都可以直接把项目交给它扫描。

这位开发者的扫描过程是这么做的：他把自己产品的代码打包之后发给了扫描工具，让它跑了一遍默认配置。整个过程持续了一个多小时，扫完了项目里的 200 多个文件，最终找到 21 个安全问题：1 个高风险、11 个中风险、9 个低风险。

扫描工具自动生成了详细的安全报告，每个问题都包含问题位置、风险等级、触发路径和修复建议。1 个高风险就是那个鉴权被绕过的漏洞；11 个中风险主要集中在报表生成、文件导出和重复触发任务的功能上，比如某些导出文件可能被电子表格软件识别成公式，或者某些 调用调用频率限制做得不够严，导致普通账号短时间内烧掉大量 API 额度；9 个低风险则更零碎，包括报错信息泄露、上传文件检查顺序不合理等。

这位开发者按照报告的建议一步步修复漏洞，然后再跑了一次扫描，确认所有高风险和中风险都已经解决。整个过程花了大约两天时间。这两天时间换来的，是他终于可以睡一个安稳觉，不用再担心半夜被告警邮件吵醒。

从他的经验里，独立开发者可以提炼出几条非常实用的安全建议。第一，公网服务上线之后，被扫描攻击几乎是必然的，不要抱有任何侥幸心理。第二，自己看代码很难发现鉴权绕过这种逻辑漏洞，必须借助工具去跑。第三，对小项目来说，每周花一次时间让扫描工具跑一遍，性价比远高于事后补救。第四，最严重的安全问题往往不是技术问题，而是代码本身的疏忽。

对所有正在用 AI 写产品的开发者来说，这位开发者的经历值得记下来：功能能跑通不等于产品能上线。安全扫描这件事不能等到出问题再做，越早建立习惯，越能避免被攻击者当免费测试对象。

（来源：人人都是产品经理 2026 年 8 月稿件《用 Codex Security 给 AI 产品做安全扫描的实操记录》）

AI 工具使用经验，上乌鸦部落。

创业找资源，上乌鸦部落。