1. 当我把一段祖传代码丢给AI审计之后先说结论AI做代码审计靠谱但靠谱的程度完全取决于你怎么用它。如果你指望把一整个仓库扔进去然后AI给你吐出一份可以直接提交给安全团队的报告那大概率会失望。但如果你把它当成一个不知疲倦、知识面极广、但偶尔会犯轴的高级实习生那它带来的效率提升是实打实的。我自己维护着一个跑了快六年的老项目中间换过两拨人代码风格从“函数式洁癖”一路漂移到“能跑就行”。前段时间要做一次安全自查我手动翻了两天眼睛都快看花了漏掉的隐患比找到的还多。后来我换了个思路把AI拉进来做第一轮扫描自己只负责复核和深挖。结果一个下午就理出了十几个值得关注的点其中有三四个是我手动翻的时候完全没注意到的。这篇文章就是那次实战的完整复盘。我会讲清楚AI在代码审计这件事上到底能做什么、不能做什么怎么设计提示词才能让它输出有价值的结果以及最关键的——怎么判断它说的是真问题还是在胡说八道。不管你是刚接触代码审计的新手还是已经有一套自己流程的老手应该都能从里面找到能直接用的东西。2. AI在代码审计里到底能干什么不能干什么2.1 它真正擅长的三件事很多人对AI代码审计的期待是“帮我找出所有漏洞”这个定位本身就偏了。根据我自己的使用经验AI在下面这三类任务上表现相当出色。第一类是模式识别型的问题。比如硬编码的密钥、密码、Token不安全的随机数生成用了已知有问题的加密算法像MD5做密码哈希SQL语句的字符串拼接命令执行时没有做参数化处理。这些东西有非常明确的特征AI见过大量类似的代码识别准确率很高。我那次审计里AI一口气标出了七处硬编码的配置信息其中两处是我自己写的当时图方便直接写死了后来完全忘了这回事。第二类是逻辑一致性检查。比如权限校验函数在某个分支里被跳过了资源申请之后在异常路径上没有释放条件判断的边界值写错了导致可以绕过。这类问题人眼扫的时候容易因为“看起来没问题”而忽略但AI会逐行去推演执行路径反而更容易发现不一致的地方。第三类是代码解释和文档生成。你给它一段复杂的业务逻辑让它用自然语言描述这段代码在做什么、有哪些输入输出、可能有哪些边界情况。这个能力在审计老代码的时候特别有用因为很多时候你连这段代码是干什么的都不清楚根本谈不上审计。2.2 它容易翻车的四个场景但AI也有明显的短板如果不了解这些很容易被它带偏。第一个是业务逻辑漏洞。比如一个电商系统里优惠券的叠加规则、退款流程的状态机、积分的过期策略这些逻辑的正确性依赖于具体的业务规则AI不知道你的业务规则是什么它只能看到代码层面的“自洽”看不到业务层面的“正确”。我遇到过AI认为一段退款逻辑“没有问题”但实际上业务上要求退款必须经过两级审批而代码里只检查了一级。第二个是跨文件、跨模块的调用链分析。如果你只给它一个文件它看不到这个函数在其他地方是怎么被调用的参数是怎么传进来的有没有做前置校验。很多注入类漏洞的根源不在漏洞点本身而在上游的数据处理环节。AI在单文件模式下很容易漏掉这类问题。第三个是依赖库和框架的特定版本问题。AI的训练数据有截止时间它可能不知道某个库的最新版本修了什么漏洞也可能把旧版本的用法当成正确的。比如某个Web框架在某个版本之后默认开启了CSRF防护但AI可能还在建议你手动加防护代码。第四个是误报。这是最消耗精力的问题。AI会把一些看起来像漏洞但实际上是安全写法的代码标出来。比如用了参数化查询但写法比较特殊AI可能误判为SQL注入。或者用了某个加密库的安全封装AI不认识这个封装以为你在直接调用底层不安全的API。2.3 一个合理的分工模型基于上面的分析我总结出来的分工模型是这样的审计环节AI负责人负责第一轮扫描全量扫描标记可疑点定义扫描范围和规则可疑点分类按漏洞类型和严重程度分类判断分类是否合理深度分析提供代码上下文解释和攻击路径推演验证攻击路径是否真的可行业务逻辑辅助理解代码意图判断业务逻辑是否正确最终报告生成初稿复核、补充、定稿这个分工的核心逻辑是AI做广度和速度人做深度和判断。不要指望AI替你做出最终判断但可以让它帮你把需要判断的东西整理好。3. 我实际用的提示词长什么样3.1 第一轮扫描让AI做“可疑点标记”第一轮的目标不是找到漏洞而是找到“值得看的地方”。所以提示词的重点是广撒网、低门槛、多标记。我用的提示词大概是这样的你是一个代码审计助手。请分析以下代码标记出所有可能的安全隐患点。 要求 1. 对每个可疑点给出行号范围、问题类型、简要说明、严重程度高/中/低/信息 2. 严重程度判断标准 - 高可直接导致远程代码执行、SQL注入、敏感信息泄露 - 中需要特定条件才能利用或影响范围有限 - 低代码质量问题可能间接导致安全问题 - 信息需要进一步确认的可疑写法 3. 不要试图给出修复方案只做标记 4. 如果某个可疑点你不确定标记为“信息”级别并说明不确定的原因 代码如下 [粘贴代码]这个提示词的关键在于最后一条让AI在不确定的时候明确说出来。如果不加这一条AI会倾向于把所有东西都说得言之凿凿你根本分不清哪些是它真确定的哪些是它在猜。另外我特意要求它不要给修复方案。因为在第一轮修复方案会干扰判断——你看到AI给了一个看起来很合理的修复方案就容易默认它标记的问题也是真的。先标记后分析再修复这个顺序不能乱。3.2 第二轮深挖让AI推演攻击路径第一轮标记出来的可疑点我会挑出严重程度为“高”和“中”的逐个让AI做深度分析。这一轮的提示词重点变成了推演和验证。针对以下代码片段中的[具体问题类型]请做深度分析 1. 攻击者需要满足什么前提条件才能利用这个问题 2. 从攻击者输入到触发问题完整的数据流是怎样的请逐步描述。 3. 如果存在防护措施这些防护措施是否可以被绕过如何绕过 4. 这个问题在实际部署环境中被利用的可能性有多大 5. 如果你认为这个问题不可利用请说明理由。 代码片段 [粘贴相关代码] 上下文信息 - 这个函数被调用的位置[描述] - 输入数据的来源[描述] - 运行环境[描述]这一轮最重要的是第5条。让AI有机会说“这个问题不可利用”而不是强行论证它可利用。很多误报在这一轮会被过滤掉。上下文信息那部分非常关键。如果你只给AI一个函数它不知道这个函数的输入是从哪来的就只能假设最坏情况。但如果你告诉它“这个函数的参数来自内部配置不经过用户输入”它就能做出更准确的判断。3.3 业务逻辑审计换个问法业务逻辑漏洞的审计提示词要换一个思路。不要问“这里有没有漏洞”而是问“这段代码在什么情况下会做出与预期不符的行为”。以下代码实现了一个[描述业务功能]的逻辑。请分析 1. 这段代码的预期行为是什么用自然语言描述 2. 在哪些边界条件下实际行为会偏离预期行为 3. 如果多个请求并发执行是否会出现状态不一致 4. 是否存在某些操作序列可以绕过业务规则 代码 [粘贴代码] 业务规则说明 [描述业务规则]这里我特意加了业务规则说明。如果你不告诉AI业务规则是什么它只能从代码反推而代码本身可能就是错的。把业务规则明确写出来AI才能对比“代码实际做的”和“业务要求做的”之间的差距。3.4 一个我踩过的提示词坑最开始我用AI做审计的时候喜欢一次性把整个文件甚至整个模块丢进去觉得这样AI能看到全貌分析更准确。结果发现完全不是这么回事。代码太长的时候AI的注意力会分散前面分析得很细后面就开始敷衍。而且长代码里噪音太多AI会把大量精力花在无关紧要的地方真正有问题的几行反而被淹没了。后来我改成按函数或按类拆分每次只给一个逻辑单元但把相关的上下文信息用文字补充进去。这样AI的分析深度明显提升误报率也降下来了。提示如果你要审计的文件超过300行建议拆分成多个逻辑单元分别处理。拆分的时候按功能模块拆不要按行数硬拆。4. 怎么判断AI说的是真问题还是在胡说4.1 误报的三种典型模式用了这段时间我发现AI的误报基本可以归为三类识别出类型之后判断起来就快很多。第一类是“模式匹配过度”。AI看到某个危险函数的调用就标记为漏洞但没有仔细看参数是怎么构造的。比如看到字符串拼接就说是SQL注入但实际上拼接的内容是内部生成的枚举值根本不经过用户输入。这类误报的识别方法是追踪数据来源。问自己这个变量是从哪来的如果追溯不到用户可控的输入基本可以判定为误报。第二类是“上下文缺失”。AI在单文件模式下看不到全局的防护措施。比如它在某个函数里发现没有做输入校验但实际上这个函数的所有调用方都做了校验。这类误报的识别方法是检查调用链。找到这个函数被调用的地方看看上游有没有做防护。第三类是“知识过期”。AI基于旧版本的库或框架给出判断但你的项目用的是新版本行为已经变了。这类误报的识别方法是对照官方文档。AI说某个API不安全你去查一下这个API在当前版本的状态。4.2 我的复核流程收到AI的审计结果之后我会按下面的流程逐个复核先看严重程度为“高”的。这些是优先处理的对象但也是最容易出误报的地方因为AI对“高”的判断往往比较激进。对每个可疑点先问三个问题输入可控吗防护措施存在吗利用条件现实吗如果三个问题的答案都是“是”那就需要认真对待手动构造PoC验证。如果任何一个答案是“否”标记为“待确认”继续看下一个。所有“待确认”的在完成第一轮复核之后用更详细的上下文信息再让AI分析一次。这个流程的关键是不要在一个可疑点上纠结太久。先快速过一遍把明显是误报的过滤掉剩下的再花时间深挖。4.3 一个真实的误报案例AI曾经标记过我代码里的一处“命令注入风险”说我把用户输入拼接到了系统命令里。我一看确实有一行类似os.system(process filename)的代码。但仔细看上下文这个filename是从一个内部生成的临时文件名格式是固定的UUID加扩展名根本不经过用户输入。AI之所以标记它是因为它看到了“字符串拼接系统命令调用”这个模式但没有追踪filename的来源。这就是典型的“模式匹配过度”。但这次误报也不是完全没有价值。它让我意识到虽然当前filename是内部生成的但如果以后有人修改了上游代码让这个变量变成用户可控的这里就会变成一个真正的漏洞。所以我后来还是把这行代码改成了参数化调用算是把未来的风险提前堵上了。5. 把AI审计嵌入到开发流程里5.1 提交前的自动扫描我现在在代码提交之前会跑一个自动化的AI审计脚本。不是每次提交都跑全量而是只扫描本次变更涉及的文件。这样每次扫描的代码量不大AI的分析深度有保证而且反馈及时改起来也快。脚本的逻辑大概是这样的# 获取本次提交变更的文件列表 changed_files$(git diff --name-only HEAD~1 HEAD) # 对每个变更的代码文件进行AI审计 for file in $changed_files; do if [[ $file *.py ]] || [[ $file *.js ]] || [[ $file *.java ]]; then echo 审计文件: $file # 调用AI审计接口传入文件内容和审计提示词 # 输出结果到审计日志 fi done这个脚本的关键是只扫描变更部分。全量扫描适合定期做比如每周一次或者每个版本发布前一次。日常提交用增量扫描就够了。5.2 审计结果的跟踪和管理AI审计出来的问题如果不跟踪很容易就忘了。我的做法是给每个确认的问题建一个条目记录问题描述、严重程度、发现时间、修复状态、修复人。这个跟踪表不需要很复杂一个简单的Markdown文件或者表格就够了。编号问题描述严重程度发现时间状态备注001配置文件硬编码密钥高第1周已修复改为环境变量002日志中输出敏感信息中第1周已修复增加脱敏处理003权限校验分支遗漏高第2周待确认需确认业务规则004异常路径资源未释放低第2周已修复增加finally块这个表看起来很简单但它的价值在于让审计结果变得可追踪。没有这个表AI审计就是一次性的事情跑完就完了。有了这个表审计就变成了一个持续的过程。5.3 定期做全量审计增量审计覆盖的是新代码但老代码里的问题不会自己消失。我一般每个月做一次全量审计把整个代码库过一遍。全量审计不需要每次都让AI从头分析可以只分析上次审计之后有变更的文件加上上次标记为“待确认”的问题。全量审计的时候我会把AI的审计结果和上次的结果做对比看看有没有新出现的问题以及上次标记的问题有没有被修复。这个对比过程本身也能发现一些问题比如某个问题被标记了但一直没修说明它可能被忽略了需要重新评估优先级。6. 几个让我印象深刻的实战片段6.1 那个被AI揪出来的越权访问有一次AI在一个接口处理函数里标记了一个“权限校验可能被绕过”的问题。我一开始没太在意因为那个函数里明明有权限检查的代码。但AI指出权限检查是在一个条件分支里如果某个参数为特定值就会跳过检查直接执行核心逻辑。我仔细看了一下确实是这样。代码大概是这个结构def handle_request(user_id, resource_id, action): if action ! read: check_permission(user_id, resource_id) # 执行操作 do_something(resource_id, action)当action为read的时候权限检查被跳过了。开发者的意图可能是“读操作不需要权限”但实际上这个读操作会返回敏感数据应该也需要权限校验。这个问题我手动翻的时候完全没注意到因为我的注意力被check_permission这个函数名吸引了看到它就觉得“哦有权限检查”没有仔细看它是在什么条件下被调用的。AI没有这种“看到函数名就放心”的思维定式它老老实实地推演了所有分支反而发现了问题。6.2 一个AI坚持认为是漏洞但实际不是的例子AI曾经在一个文件上传功能里标记了“路径穿越漏洞”说文件名没有做过滤攻击者可以用../../来覆盖任意文件。这个标记本身是对的但问题是这段代码在调用之前上游已经对文件名做了严格的过滤只允许字母和数字。我把上游的过滤代码贴给AI看它承认过滤是有效的但仍然坚持认为“应该在文件上传函数内部也做一次过滤做纵深防御”。这个观点本身没错但在这个具体场景下上游过滤已经足够严格再加一层过滤的收益很低反而增加了代码复杂度。这个例子说明AI有时候会从“最佳实践”的角度出发而不是从“实际风险”的角度出发。最佳实践当然好但工程上需要在安全性和复杂度之间做权衡。这个权衡AI做不了得人来做。6.3 并发场景下的状态不一致还有一个问题是AI发现的但一开始我完全没看懂它在说什么。它说某个订单处理函数“在并发情况下可能出现状态不一致”。我看了半天觉得逻辑很清晰啊先查订单状态如果是“待支付”就改成“已支付”然后发货。后来我仔细想了想如果两个请求同时到达都查到订单是“待支付”然后都改成“已支付”就会发两次货。这就是典型的检查后执行竞态条件。AI之所以能发现这个问题是因为它在分析的时候会考虑“如果多个执行流同时到达这里会怎样”。人脑在阅读代码的时候默认是顺序执行的思维模式不太容易主动去考虑并发场景。AI没有这种思维定式它会老老实实地考虑各种可能的执行顺序。7. 我对AI代码审计的真实评价用了这段时间我对AI代码审计的定位越来越清晰了。它不是一个“替代人”的工具而是一个“放大人的能力”的工具。在AI出现之前代码审计的瓶颈在于人的精力和注意力。一个人一天能认真审计的代码量是有限的而且随着疲劳度增加漏报率会急剧上升。AI没有这个问题它可以不知疲倦地扫描大量代码而且每次扫描的“注意力”都是均匀的。但AI的短板也很明显它不理解业务不知道什么重要什么不重要容易在细节上过度纠结也容易因为知识过期而给出过时的建议。这些短板恰好是人的长处。所以我的结论是AI做代码审计靠谱但前提是你得知道怎么用它。把它放在正确的位置上它能帮你省下大量时间让你把精力集中在真正需要人类判断的地方。把它放在错误的位置上它产生的噪音会让你比不用它还累。如果你还没开始用AI做代码审计我的建议是从一个小项目开始试。不要一上来就搞全量扫描先拿一个你熟悉的模块让AI分析一下看看它的输出质量怎么样然后根据你的实际情况调整提示词和流程。试过几次之后你自然就知道在哪些环节可以信任它在哪些环节需要自己把关。这个摸索的过程本身也是有价值的因为它会逼着你把自己的审计思路梳理清楚。你得先知道自己是怎么审计的才能告诉AI该怎么帮你。