基于LLM Agent与SAST的业务逻辑漏洞自动化审计框架实践

技术架构示意：AI Agent模拟安全专家审计流程

传统SAST工具对于SQL注入、XSS等模式化漏洞的检测已相当成熟，但在识别支付绕过、越权访问等依赖于业务上下文的逻辑漏洞方面，能力却十分有限。本文将探讨一种结合代码属性图（CPG）与大语言模型（LLM）的AI Agent驱动自动化审计框架，通过RAG、ToT、ReAct等技术模拟人类专家的审计流程，并提供可落地的技术实现路径与评估数据。

一、传统SAST的技术边界

传统SAST工具基于规则与数据流分析工作，其核心技术包括：

• 模式匹配：定位危险函数调用，如 eval()、system()。
• 污点分析：追踪用户输入（Source）至危险操作（Sink）的路径。
• 控制流图（CFG）与数据流图（DFG）：构建执行路径与数据依赖关系。

然而，其局限也根植于此：

• 高误报：无法理解代码的上下文与开发者的真实意图。
• 业务逻辑盲区：难以理解“订单金额不可为负”、“普通用户禁止访问/admin”等具体业务规则。
• 净化函数识别差：根本原因在于SAST依赖CFG和DFG构建的代码属性图（CPG） 仅反映了语法结构，不包含任何业务语义。

例如，在以下代码片段中，htmlspecialchars净化操作在污点分析中就可能被忽略，导致误报：

$_GET['a']=htmlspecialchars($_GET['a']);
echo $_GET['a']; // SAST可能误报XSS

逻辑漏洞检测的挑战更为突出：

• 强依赖业务场景（如支付、优惠券核销），缺乏通用的代码模式可循。
• 对操作顺序与状态变更敏感（例如，“先扣款后验库存”与“先验库存后扣款”在并发场景下的安全性差异），静态分析难以对这类动态行为进行准确建模。

二、人工审计路径拆解

人工安全专家审计逻辑漏洞时，通常会遵循一套方法论，这个过程为后续的LLM自动化提供了清晰的流程参照：

1. 信息收集：阅读README、架构文档、配置文件，识别技术栈（框架、中间件、数据库）与安全边界。
2. 核心功能定位：梳理认证、交易、权限等核心模块在控制器、Service、DAO各层的代码映射关系。
3. 代码与功能映射：从API路由追踪至具体的业务逻辑实现，绘制数据流向（HTTP入参 → Service处理 → DB写入）。
4. 攻击假设生成：针对每个功能点提出可能的滥用场景：
   • 越权：userId参数是否可被篡改以访问他人资源？
   • 参数篡改：负数金额、特殊字符是否能通过校验？
   • 并发条件：库存扣减与支付操作的时序是否安全？
5. 假设验证：沿着数据流路径，分析输入校验、权限检查、异常处理等分支逻辑，确认攻击的可行性。

人工审计的核心能力在于跨文件上下文关联与业务状态推演，而这恰恰是传统SAST工具无法复现的。

三、LLM驱动的自动化审计框架

自动化审计框架的核心阶段与技术支持

该框架将上述人工审计流程工程化为四个阶段，每个阶段由特定的技术框架驱动。

阶段一：认知建立：RAG + 代码属性图（CPG）

目标：将散乱的源代码转化为可供LLM理解的结构化知识库。

实现路径：

1. 使用Joern、CodeQL等SAST工具生成项目的代码属性图（CPG），其中包含CFG、DFG、调用图（Call Graph）。
2. 通过图查询语言，从CPG中提取关键信息：
   • 所有API端点（例如Spring框架中的 @RequestMapping 注解路径）。
   • 数据模型（实体类字段、数据库表映射关系）。
   • 环境信息（README.md、application.yml、pom.xml依赖列表等）。
3. 将这些信息向量化处理后，存入Faiss或Chroma等向量数据库，构建为知识库，供LLM通过检索增强生成（RAG） 进行调用。

阶段二：攻击构想：ToT框架

目标：模拟专家思维，生成具有高价值的攻击假设树。

实现路径：

1. Agent调用RAG，检索项目的核心业务模块代码（例如订单模块）。
2. LLM基于思维树（Tree-of-Thoughts, ToT） 框架，生成分支化的攻击假设：
   • 分支A：价格篡改（修改前端传入的 totalAmount 参数）。
   • 分支B：越权访问（修改URL或参数中的 userId）。
   • 分支C：重复提交（接口缺乏幂等性校验）。
3. 结合RAG检索到的信息进行初步评估与剪枝。例如，如果RAG结果显示存在 @RepeatSubmit 注解，则可以剪除“重复提交”这个分支。

ToT指令示例：

针对“订单创建”流程，请提出5种最可能的逻辑漏洞攻击假设，并对每个假设给出初步可行性评估。

阶段三：验证追踪：ReAct框架

目标：对攻击假设进行深度验证，形成完整的漏洞确认证据链。

流程（以“价格篡改”假设为例）：

1. 制定计划：LLM生成具体的验证步骤，例如——“确认price参数是否直接流入支付计算函数；确认支付逻辑中是否从数据库二次查询商品真实价格进行校验”。
2. 执行工具调用：
   • 污点分析：通过图查询命令，追踪price参数从HTTP入参到支付服务方法的完整DFG路径。例如：cpg.parameter("price").reachableBy(cpg.method("paymentService.process")).flows.p。
   • 调用图分析：查询paymentService.process方法是否调用了价格校验方法。例如：cpg.method("process").caller.name.l。
3. 审查代码片段：从源码中提取出关键方法的代码，提交给LLM进行语义分析。
4. 结论生成：LLM综合工具返回的证据（如数据流路径存在、校验调用缺失），判定漏洞是否存在。

ReAct循环示例：

• Thought：需要确认 price 参数是否被 validatePrice 方法处理过。
• Action：调用 callGraphQuery("validatePrice") 工具。
• Observation：工具返回空结果，表明未找到相关调用。
• Conclusion：支付流程中缺少价格校验逻辑，“价格篡改”漏洞确认存在。

阶段四：报告与修复

输出内容：

• 严重性评估：依据CVSS 3.1标准进行评分（例如价格篡改：AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N → 6.5 Medium）。
• 修复建议：LLM生成具体的代码修复补丁。
• 证据链：包含DFG路径截图、调用链缺失证明等。

修复代码示例：

// 原始有漏洞的代码
order.setTotalAmount(request.getPrice());

// 修复后的代码
BigDecimal dbPrice = productService.getPrice(productId);
if(request.getPrice().compareTo(dbPrice) != 0){
    throw new BusinessException("价格异常");
}
order.setTotalAmount(dbPrice);

四、效果评估：内部靶场实测数据

我们在内部靶场（包含10个已知的逻辑漏洞，如价格篡改、越权、短信轰炸等）上对该框架进行了测试。

指标	结果
召回率	60%（成功发现6/10个漏洞）
准确率	83%（6个报告中，5个为真实漏洞，1例误报）
审计耗时	平均25分钟（对比人工审计平均需4小时）
效率提升	约10倍
报告质量	包含证据链、修复代码、PoC，可直接用于灰盒交叉验证

未发现的4个漏洞主要涉及需要跨多个微服务进行复杂业务状态理解的场景，这对当前框架的上下文关联能力提出了更高要求。

五、挑战与未来优化方向

1. CPG构建精度：底层SAST工具生成的调用图或数据流若存在缺失（例如对反射、动态代理的支持不足），会导致RAG知识库存在盲区，进而使上层推理失效。优化方向包括引入轻量级动态分析来补充静态调用边。
2. 工具链鲁棒性：ReAct框架依赖的图查询、代码提取等工具需要适配不同编程语言和框架（如Spring、Django、Gin）。工程上的挑战在于维护一套多语言的AST解析器与统一的中间表示（IR）。
3. LLM幻觉抑制：尽管ToT和ReAct框架通过依赖工具证据链降低了幻觉风险，但在复杂推理中，LLM仍可能误解工具返回的结果。缓解方案可以是为关键结论添加验证节点，进行二次规则校验。
4. 成本控制：多轮LLM调用（尤其是在ToT分支探索时）会显著推高Token消耗。平衡策略包括对初步评估为低风险的业务模块关闭ToT，仅执行单路径的快速验证。

总结

实测数据表明，这套融合了SAST、CPG与LLM Agent的自动化审计框架，在保证83%准确率的前提下，能将业务逻辑漏洞的审计效率提升一个数量级。这为安全团队应对日益复杂的业务代码提供了新的思路。

未来，攻克跨服务状态分析、动态代理调用图补全等难点，并进一步优化LLM调用成本以适配CI/CD流水线，将是该技术走向成熟落地的关键。代码安全测试正在从传统的“模式匹配”向更深层的“语义理解”演进，而AI Agent化的智能审计无疑是其中一条重要的实践路径。希望本文的探讨能为安全工程师和开发者们带来启发，也欢迎在云栈社区交流更多关于代码安全与智能化的想法。