让 AI 帮我做代码安全审计和漏洞扫描之后，我总结了三个它最容易漏报的地方

我们组去年把 AI 代码审计接进了 PR 流程，号称能自动找出 SQL 注入、XSS、越权这些。头两周报告很漂亮，标了十几个中危，开发照着修。结果上线两个月，一个没被任何报告点名的接口被人用越权刷走了数据——问题出在一处"看起来人畜无害"的 IDOR，AI 把那个参数当成"已鉴权上下文"直接跳过了。

我把同一份代码同时喂给 AI 审计和一个干了十年的老安全，对比两者的产出。老安全没写报告，只在三个地方打了问号，每一个都戳在"数据流从哪来、信任边界在哪"。AI 的报告很全，但全是"模式匹配型"的：看到字符串拼 SQL 就标注入，看到 innerHTML 就标 XSS，看到没加鉴权注解的接口就标越权——它从不追问"这个 token 上游真的校验过吗"。

三个它最容易漏报的地方，我记下来了。

第一，信任边界传递。AI 默认"上游函数已经校验过就不会有问题"，但我们的校验写在一个被 5 个入口共用的工具里，其中两个入口根本没走到那行。它看单个函数安全，看不出调用链上的缺口。

第二，业务逻辑型越权。AI 能认出"没加 @Auth 注解"，但认不出"加了注解但该接口返回的是别人的数据"——因为它不懂你的数据归属模型，只能看代码形态。这种漏洞恰恰是线上最疼的那种。

第三，依赖链里的间接漏洞。它扫的是你写的代码，一个间接依赖把敏感信息打进了日志，它一句没提，最后是我用 dependency check 才翻出来。AI 默认你的依赖是干净的，但干净从来不是默认值。

我现在的结论是，AI 审计最大的盲区不是技术漏洞，是"它不知道你的业务假设"。它能帮你把已知的坏模式扫一遍，但跨函数的信任假设、数据归属这种要靠人脑建模的东西，它现在还差得远。所以我现在让它当第一道粗筛，人工再过一遍业务边界。这个我建议先收藏，下次接 AI 审计进流程前对着自己的代码验证一下。

你觉得到底是先把 AI 审计覆盖率拉满更重要，还是宁可慢点也要保住那几个它必漏的业务漏洞？我站后者，但见过有人靠前者把漏洞数报表做得特别好看。