前言

在上个月参加先知的白帽大会的时候，有幸和多位师傅线下交流了下，尤其是AI对于我们渗透、审计等工作的赋能，AI审计的工作流实现等等，收获颇丰。

熟悉我或者是有看过我B站第一期公开课《JAVA代码审计实战》的师傅应该知道，由于我的代码功底差，早期很多业务代码的通读都依赖于AI，这也让我很早就敏锐地意识到：AI审计在未来极大概率会取代大部分人工审计工作。因此，我当时设计公开课内容的核心理念，就是“审计思路主导 + AI分析代码流”。道理很简单，在AI技术飞速发展的当下，我们已无需再死记硬背繁琐的业务开发代码细节，而应将重心转移到对框架原理与业务架构的宏观把控上。具体的业务实现代码，则交由AI进行深度分析。我们只需结合AI的代码解读，利用自身对漏洞产生本质的理解进行最终判断。在去年我写了第一款内部AI审计工具，在我的一些文章中应该也有师傅看到过

当时的设计思路和一些拼接的ai赋能的审计产品很像，只是把正则和ai分析结合起来，我当时在工具开发的时候，在规则匹配上下了很大的功夫，规则调试、信赖度机制、二次匹配等等一系列操作，虽然说这个工具手工用起来很舒服，但是其中的AI分析我一直不满意，因为工具本地的核心点在于正则，发生给ai的只是方法块，没实现跨文件，误报率高，确实能初筛掉很多点，但是效率还是偏低，导致我用这个工具的时候就没用过AI分析模块，都是用正则

然后在上个月和一些师傅交流了它们公司和工作室自研的产品的一些思路，让我模糊的思维一点点紧密了起来，于是在大会结束后，我回到我的狗窝，开始了AI审计工作流的设计与构建

AI基础知识与概念    LLM    Agent    Skills /Tools    MCP正篇    我们代码审计需要什么？    工作流实现会遇到的问题成果结语

AI基础知识与概念

1. LLM (Large Language Model) —— 大语言模型

通用定义：基于深度学习技术（通常是 Transformer 架构），在海量文本数据上训练出来的数学模型。

• 本质：它是一个概率预测引擎。它通过计算，预测给定上文后，下一个字（Token）出现的概率。

• 核心能力：

• 理解与生成：处理自然语言，实现对话、翻译、摘要。

• 逻辑推理：通过训练获得的知识模拟人类的逻辑思考过程。

• 知识库：压缩了人类文明的大部分文本信息，是一个“百科全书”。

• 通俗比喻：它是“缸中之脑”。它非常有才华，知识渊博，但它没有身体，无法直接接触现实世界，只能通过文字和你交流。

2. Agent —— 智能体

通用定义：一种能够感知环境、进行推理、做出决策并采取行动以实现特定目标的自主系统。

• 本质：它是以 LLM 为核心驱动力的“数字化员工”。LLM 只是 Agent 的一个组件（大脑）。

• Agent 的公式：Agent = LLM + 规划(Planning) + 记忆(Memory) + 工具使用(Tool Use)。

• 核心特征：

• 自主性：你只需给它一个目标（如“帮我策划一场旅行”），它会自己拆解步骤，而不是你一步步教。

• 闭环思考：它会观察行动后的结果，如果失败了，它会自我反思并调整策略。

• 通俗比喻：它是一个“聪明的员工”。它不仅会说话（LLM），还会查资料、写文档、发邮件，直到把活干完。

3. Skills / Tools —— 技能与工具

通用定义：Agent 为了完成任务而调用的外部程序或 API 接口。

• 本质：它是 AI 与物理世界/数字世界交互的媒介。

• 为什么需要它：LLM 本身不会做算术（容易算错）、无法联网看实时新闻、无法控制你的电脑。

• 常见示例：

• 搜索技能：让 AI 能上百度/谷歌查信息。

• 计算技能：让 AI 调用 Python 解释器进行精准数学运算。

• 控制技能：让 AI 控制智能家居开关灯。

• 通俗比喻：它是 AI 的“工具箱”。大脑（LLM）发现需要钉钉子，于是手（Agent）从工具箱里拿出了锤子（Skill）。

4. MCP (Model Context Protocol) —— 模型上下文协议

通用定义：由 Anthropic 公司提出的一种开放标准协议，旨在让 AI 模型能够以统一的方式连接到各种数据源和工具。

• 本质：它是 AI 界的“USB 接口标准”。

• 核心价值：

• 标准化：在 MCP 出现前，每个开发者都要为不同的 AI 编写专门的连接代码。有了 MCP，只要大家都遵守这个协议，任何工具都可以“秒连”任何 AI。

• 上下文集成：它让 AI 能更安全、更规范地读取你的本地文件、数据库或第三方服务。

• 通俗比喻：它是 “万能插头”。以前每个电器（工具）的插头都不一样，你得买各种转换器；现在有了 MCP 这个统一插座，所有电器插上就能用，数据传输（上下文）畅通无阻。

正篇

我们代码审计需要什么？

AI审计，简单来说就是代替我们人工去进行一系列操作，所以要实现ai审计的完整流程，你就得明白，一套系统的规范审计流程是什么，这个也是我一直在教的东西

首先拿出一张图片

我们可以参考经典的 Agent 设计流程。一套完整的审计 Agent 应该包含以下几个关键步骤（漏洞复现环节可选，视需求而定）：

1. 架构分析与策略制定：分析项目的整体架构，根据不同的框架（如 Spring Boot, ThinkPHP 等），寻找鉴权实现方式、业务路由规则以及框架特有的潜在漏洞。

1. 鉴权缺陷挖掘：针对寻找到的鉴权方法进行深度挖掘，提取白名单接口，分析是否存在未授权访问或权限绕过风险。

1. 核心漏洞代码审计：针对 SQL 注入、文件操作（读写/上传）、RCE（远程代码执行）、SSRF（服务端请求伪造）、XXE（XML 外部实体注入）等高危漏洞点进行代码审计，分析用户输入是否可达危险函数（Sink）。

1. 漏洞复现与二次确认：通过第一层代码层面的确认，结合给出的 POC，利用 MCP 对接本地环境进行漏洞复现，进行二次确认，排除误报。

1. 整合输出报告：整合所有分析结果，产出专业报告。内容应涵盖项目架构分析、鉴权机制分析、已确认漏洞详情及 POC 等。

当然这里只是一个大体的实现框架，在我们真正开始实现每个步骤的时候，还需要设计非常多的东西，我这里简单讲几个从手工审计转到AI实现的点

1、分析项目架构要如何分析，这里可能需要ai分析项目框架，拿java为例，是struts2、spring MVC 、传统javaweb？根据不同的架构，鉴权装配的位置也大不相同，spring mvc可能是注册拦截器，struts2可能是Action继承，可能是Filter这些逻辑都是需要我们封装好的，如果单纯的直接让AI，一些推理能力差的或者知识库不够完善的模型给出的结果和我们需要的会差很多，还有框架组件特有漏洞的判断等等

2、鉴权缺陷，还是拿java为例，我们常见的鉴权缺陷分为两种，白名单缺陷、鉴权凭据缺陷，那么AI知不知道要分析白名单匹配逻辑，甚至是采用组件例如shiro的鉴权绕过CVE，这些都是我们在设计的时候需要喂给AI的

3、漏洞代码审计，我们拿注入来说，一套中型系统的数据库操作可能有几百到一千条，如何让AI快速找到非预编译的点，一些漏洞成立的条件规范等等

每一步都要详细的按照人工的思路去实现，这样才能避免一些问题，尽可能的让AI出的结果符合我们的预期，而不是简单的让ai分析一套系统然后就没了

工作流实现会遇到的问题

ok，流程是这样，但是当我们实现的时候会发现很多问题，我这里来简单说几个我遇到的，有一些到现在也没解决

1、这套agent是全部交给ai的，那么这里会遇到第一个问题，一套小系统可能会有400+个文件，大系统3000+个文件，这里还不包含组件包，尽管现在的大部分好的模型的上下文已经很强了，但是涉及到这种大型项目的时候，还是会出现上下文缺失，变蠢，变笨的问题，其实这个我也有一个思路，我称之为农场主大法，用一个推理逻辑强的ai，拿着鞭子抽另一个ai干活，把步骤分块，避免上下文缺失的情况，开个玩笑，这个方法确实可以但是实际也会有一些问题。

2、也是第一个问题的延申，对于大型项目ai分析的token使用量非常大，一套系统你要全权分析，可能要花费100-1000不等价格的token，并且还会遇到前面的问题，上下文缺失，要么重复跑一些代码，要么缺少一部分代码，导致漏报，误报的情况

那么我是如何解决这些问题的，我的方案是AST扫描加AI逐条分析链路(也有缺陷)

我的工作流实现方案如下：

1. AST 语法转换与链路提取：首先对项目进行 AST（抽象语法树）语法转换，通过静态分析精准定位危险函数（Sink）与用户输入点（Source），从而提取出完整的代码调用链路。

1. 逐条链路的 LLM 分析：将提取到的每一条调用链路，配合精心设计的 LLM 提示词（Prompt），逐条发送给 AI 进行深度分析。

1. 鉴权 Skill 专项分析：设计一个专门的“鉴权分析 Skill”，让 AI 针对提取出的接口进行鉴权逻辑的专项审计。

1. 整合产出报告：最后整合所有分析内容，自动化产出最终审计报告。

这套工作流可以避免几个问题：

1. 不会出现需要大量分析项目文件的情况，只分析链路涉及到的文件

1. 每条链路都是一次新的对话，不会出现上下文过长的问题，一些上下文差的ai也可以用

1. 成本低，只分析链路问题涉及到的读操作少，token的用量自然就低了

那么缺点是什么？

工作流实现的核心关键点在于链路的提取。如果静态工具的设计遗漏了某个 Sink 点，或者项目采用了一些复杂的写法——例如反射调用、复杂的变量赋值、方法封装在 JAR 包中——都会导致链路中断，无法被提取，从而出现漏报的情况。

这一点在 PHP 项目中尤为明显。由于语言的高度灵活性，很多闭源项目都有一套自研的写法，导致 AST 分析往往面临大量的误报或漏报；相比之下，使用 ThinkPHP 等成熟框架的项目反而情况较好。

那么，能不能通过放宽规则来解决呢？答案是：不行。

在一些优化思路中，最简单的做法就是放宽链路提取规则，例如把变量赋值类的点也加入进静态设计中。

• 少数情况有效：有些不常规的赋值写法，不会和正常代码重复，这样可以覆盖到特有情况。

• 大多数情况失效：大部分的规则放宽导致的结果几乎都是大批量误报。

这就好比原先你的工具扫描项目提取到了 100+ 条链路，有 3 条漏洞不在其中；如果放宽了规则，扫描提取到了 300 条链路，虽然那 3 条漏洞被包含进来了，但同时也可能增加了 197 条误报。这将大大增加 AI 分析的成本。

最后我敲定的思路是AI二次反思把 AI 分析过的所有“确认漏洞”和“排除漏洞”去除，再通过提示词让 AI 分析系统是否存在遗漏的漏洞，并让其分析工具未能提取到链的原因，探讨能否通过技术手段解决并完善静态工具。

成果

那么成果呢？

一个月时间，边划水，边测试，写的代码审计平台

目前写了php和java两种的审计流，工具开发测试项目均为闭源，也集成了在线AI分析，也可以只用于链路提取，保留链路文件交给本地AI分析

一些报告

本地的审计流

CVE可日刷50+甚至更多，懒得写报告交

CNVD目前从写工具测试到现在产出10+

结语

文章的最后简单再说说，这也是很多师傅问我的问题，AI会取代人工代码审计吗？

在我看来，这是一个“必然中的偶然”。

必然性在于：AI 介入代码分析流程几乎是不可逆的趋势。它能以极低的成本，替代掉 80% 以上重复、枯燥的人力劳动。无论是污点追踪、逻辑解释还是 PoC 生成，AI 的效率已经让传统人工审计显得有些“原始”。

偶然性（或者说不可替代性）在于：我始终认为 AI 无法完全取代人工，我的理解仍然是信任度问题，或许有的师傅觉得我在扯淡，但是反正我是这么觉得的，与其焦虑是否会被Ai取代，不如学习如何用AI优化自己的工作流，提升工作效率，阿里白帽大会有个师傅说的一句话我觉得挺有道理了，AI就像是高达，高达的强度除了机甲本身，对战起来更多的还是看驾驶人。共勉！！！

有其它问题或者对文章内容有疑问的，可以加作者微信，加交流群的话备注”交流群”

公众号培训广告，有需要可联系(混口饭吃)

新一期课程介绍详细可看：菜狗安全《代码审计培训》新春优惠开启

JAVA审计闭源专题课表

1、国内几个源码站会员：9k9k，刀客，小蚂蚁，优选源码，源码庄，狗凯等，如果有需要其他源码站会员可联系我，我看情况开通

学员反馈

放几张意思下，还有一堆懒得找了