AI 代码审计的 3 个盲区:模型都会漏的那类洞
原创
奋斗的小浪
奋斗的小浪
船山信安
2026年10月31日 17:51
湖南
去阅读
AI安全 · AUDIT
AI 代码审计的 3 个盲区:模型都会漏的那类洞
别神话 LLM 审计。 practice 下来,有三类洞模型系统性漏掉:业务逻辑、跨文件数据流、配置/部署型。
这篇讲清楚它们长什么样,以及人怎么补位。
本文为 AI 辅助审计的方法论分享,案例均为通用示意,不涉及未修复系统的可利用细节。
0101 业务逻辑:模型看不懂「业务想干嘛」
很多高危问题不是代码写错,而是「流程设计就错了」。比如:改密流程只验短信码不验旧密码、提现额度在服务端没二次校验。模型读单函数看不出,因为它不知道业务规则。
业务逻辑漏洞的本质是「代码忠实地实现了错误的需求」。LLM 没有需求文档,就只能看到「代码自洽」,看不到「业务错位」。
补位靠威胁建模:先把「这个功能的正常规则是什么」写清楚,再逐条问「有没有办法绕过这条规则」。这一步目前只能人做。
0202 跨文件数据流:源头和终点不在一屏
A 文件接收输入,B 文件做处理,C 文件才进危险函数。模型一次只看一段,链就断了。这是它最容易漏的一类。
1解法:用 CodeQL / Semgrep 做跨文件污点追踪,先把「源→汇」路径画出来。
2再让 LLM 基于这条路径做「这段是否真的可达」的判断。
3人是最后一道:确认路径在真实配置下是否成立。
顺序很关键:先有路径,再有判断。直接让模型「找漏洞」,它只会看眼前这一段。
0303 配置与部署型:代码没错,环境错了
.env 里明文密钥、对象存储设为公开、K8s 的 allowPrivilegeEscalation 开着——这些根本不在代码里,模型扫源码自然看不见。
这类问题靠配置扫描,不靠代码审计
grep -rE 'AKIA[0-9A-Z]{16}' . # 硬编码云密钥
tfsec / checkov # IaC 安全扫描
所以代码审计之外,必须有独立的配置/基础设施扫描,否则「代码干净」不等于「部署安全」。
0404 工具组合才是答案
| 漏洞类型 | 主力工具 | LLM 角色 |
| 单函数坏味道 | LLM 初筛 | 快速标疑似 |
| 跨文件数据流 | CodeQL / Semgrep | 基于路径做可达性判断 |
| 业务逻辑 | 人 + 威胁建模 | 定义规则再查 |
| 配置/部署 | tfsec / 配置扫描 | 不参与 |
结论:LLM 是审计流水线的第一道筛子,不是终审。把它和静态分析、威胁建模、人工复核拼起来,覆盖率才上得去。
一个可落地的节奏:CodeQL/Semgrep 出路径 → LLM 判可达性 → 人做业务逻辑与配置复核 → 三类结果分别归档。既快又不漏大类。
参考来源
GitHub CodeQL 文档 — 污点追踪
Semgrep 文档 — 跨文件规则
OWASP — Threat Modeling / DevSecOps
MITRE CWE-20 — Improper Input Validation
本文为 AI 辅助代码审计的方法论分享。案例为通用示意,不涉及未修复系统的可利用细节或完整利用链。
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。











评论