Java-Audit：融合SAST与AI的智能代码审计工具架构与实践

1. 项目概述与核心思路

最近几年，代码审计这个活儿，是越来越不好干了。项目规模动辄几十万行，框架组件五花八门，传统的“人肉审计”模式效率低下，而纯自动化的SAST（静态应用安全测试）工具，报告里又塞满了让人头疼的误报，一个SQL注入的告警，可能只是MyBatis里一个安全的#{}占位符。我们团队在审计一个大型Java Web应用时，就曾被一个商业SAST工具生成的、长达数百页的报告折磨得够呛，真正的高危漏洞反而被淹没在海量噪音里。

正是在这种背景下，我们开始琢磨，能不能把SAST的精准“定位”能力和AI的语义“理解”能力结合起来，搞一个更聪明的审计工具？这就是Java-Audit项目的初衷。它的核心思路非常直接：让专业的工具做专业的事。我们用Joern这类基于CPG（代码属性图）的静态分析引擎，去干它最擅长的事情——精准地追踪数据流，从getParameter这样的Source（源头）一路找到executeQuery这样的Sink（危险函数）。然后，把Joern输出的、经过高度压缩和去噪的“线索”交给大语言模型（比如Claude），让它来扮演资深安全专家的角色，去判断这条数据流是否真的可控、是否存在有效的安全过滤、是否是一个业务逻辑上的越权漏洞。

简单来说，这个工具的工作流就像是一个现代化的工厂流水线：Joern是高度自动化的精密扫描仪，负责找出所有“疑似有问题”的零件；AI则是经验丰富的质检老师傅，拿着放大镜，对着扫描仪标记出的点位，结合整台机器的设计图纸（项目源码），判断这个零件是不是真的“次品”，以及次品的原因和危害等级。最后，生成一份带CVSS评分、有具体代码位置和修复建议的审计报告。这个项目完全开源，用Python实现，通过命令行操作，目标是成为安全研究员和开发者在SDL（安全开发生命周期）中的一个得力助手。

2. 架构深度解析：三阶段异步流水线设计

整个Java-Audit的架构核心，是一个精心设计的三阶段异步流水线。这个设计不是为了炫技，而是为了解决实际工程中的两个核心矛盾：分析精度与处理效率，以及上下文长度与分析深度。

2.1 阶段零：预处理与智能索引

在正式分析开始前，系统会对原始材料进行“预处理”，这是整个流程能高效运行的基础。主要做两件事：

1. Java源码的“瘦身”：一个中型Java项目可能有上千个文件，但并非所有代码都与安全审计相关。java_compressor.py模块提供了两种压缩模式。Normal模式会去掉import语句、注释、空行和日志代码。而更激进的Aggressive模式，则只保留安全审计关心的“骨架”，比如：

   • 所有控制器（Controller）的路由注解（@RequestMapping,@GetMapping等）和方法签名。
   • 所有鉴权相关的类和注解（如@PreAuthorize,Filter,Interceptor）。
   • 所有危险Sink的调用点（如Runtime.exec(),ObjectInputStream.readObject()）。
   • 所有获取用户输入的方法（如getParameter,@RequestParam）。
   • 涉及敏感字段（如password,secret）的代码片段。 通过这种方式，一个2万字符的Service实现类，可能被压缩到只剩3000字符，压缩率高达85%，但安全分析所需的关键信息毫发无损。

2. Joern输出的“提纯”：Joern的原始输出包含了大量的CPG构建日志和调试信息，真正有价值的数据流路径可能只占不到10%。joern_parser.py模块会进行三层过滤：

   • 第一层：噪音过滤。直接剔除[INFO] Pass io.joern... completed这类构建日志，这部分通常能去掉92%的冗余数据。
   • 第二层：关键路径提取。一条完整的数据流可能有几十个调用节点，其中很多是StringUtils.isEmpty、StringBuilder.append这类无关紧要的中间操作。压缩器会识别并只保留源点、跨越文件/类边界的关键跳转点以及最终的危险Sink点，将一条30步的流精简为5-8个关键步骤。
   • 第三层：结果去重。对于指向同一个Sink、路径相似的多条数据流，进行合并，只保留一条最具代表性的，并注明所有不同的入口点。 经过这番处理，一个3.2MB的Joern原始输出文件，可以压缩到仅18KB左右，压缩率99.4%，为后续AI分析节省了巨量的Token。

处理后的“瘦身”源码和“提纯”后的Joern结果，会被存入一个本地的ChromaDB向量数据库。这个数据库不是简单的存储，而是按语义（如“Controller”、“SQL注入”、“鉴权Filter”）建立索引的智能知识库，为后续Agent的按需检索打下基础。

2.2 阶段一：并行信息收集

预处理完成后，两个最重量级的任务会并行执行，充分利用多核CPU资源：

• 任务A：AI路由分析。RouteAnalysisAgent会读取压缩后的项目源码，调用大模型，系统性地识别项目中所有的HTTP API端点。它不仅能识别Spring MVC、Servlet、JAX-RS、Struts2等主流Web框架的注解和配置，还能精准提取每个接口的请求方法（GET/POST等）、处理类、处理方法以及所有参数（包括参数名、Java类型、HTTP位置如Query、Path、Body）。最终，它会为每个路由生成一个类似Burp Suite的请求模板。这个工作如果纯靠正则表达式或静态规则，对于复杂项目极易遗漏或解析错误，而AI的语义理解能力在这里表现出了巨大优势。

• 任务B：Joern全量扫描。JoernRunner模块会在后台启动Joern-CLI，为项目代码构建CPG图，并并行执行我们预先编写好的5个Scala查询脚本：

  • find_routes.sc：作为AI路由分析的补充和交叉验证，通过代码属性图精准定位路由处理方法。
  • find_sinks.sc：识别代码中所有潜在的危险函数调用点，并按类型（SQL、命令、文件、反序列化等）分类。
  • dataflow_analysis.sc：执行污点追踪分析，找出从用户输入源（Source）到危险函数（Sink）的完整数据流路径。这是SAST的核心能力。
  • find_auth.sc：定位项目中与鉴权、授权相关的代码，如Shiro的@RequiresRoles、Spring Security的SecurityFilterChain配置等。
  • hardcoded_secrets.sc：基于变量名模式（如包含password、secret、key）和字符串字面量赋值，检测可能的硬编码密钥。

这个阶段的结果（路由信息和Joern发现）会写回向量数据库，供后续阶段消费。

2.3 阶段二：深度关联分析

有了基础信息，更复杂的分析可以展开了。本阶段同样采用并行策略：

• 任务A：参数追踪与可控性分析。RouteParamAgent是这个工具的灵魂之一。它从向量库中分批加载路由信息（比如每批10个路由），然后针对每个路由：

  1. 根据路由的处理类名，去向量库中语义检索相关的ServiceImpl业务逻辑代码。
  2. 结合Joern发现的数据流（特别是标记为HIGH及以上风险的），让AI分析：“用户传入的这个参数，是否真的能毫无阻拦地流到那个危险的executeQuery函数里？”
  3. AI会沿着数据流步骤，检查每一步是否有过滤、校验、编码或硬编码覆盖。最终给出可控性判定：✅ 完全可控（用户可直接利用）、⚠️ 条件可控（需满足特定条件）、❌ 不可控（有强校验或不可达）。同时，它会生成一段伪代码来描述攻击路径，甚至构造出可复现的HTTP PoC请求包。

• 任务B：鉴权架构与绕过分析。AuthAnalysisAgent专注于应用的安全边界。它会：

  1. 从向量库中检索所有Filter、Interceptor、SecurityConfig等鉴权相关代码。
  2. 结合Joern发现的鉴权代码位置和所有路由信息。
  3. 让AI完成以下工作：识别使用的鉴权框架（Shiro, Spring Security等）及其版本（用于关联已知CVE）；分析鉴权配置的架构（是Filter链还是Interceptor）；绘制“路由-鉴权状态”映射表；最重要的是，检测潜在的鉴权绕过漏洞，例如利用getRequestURI()和getServletPath()解析差异导致的路径匹配绕过。

2.4 阶段三：验证与报告生成

最后阶段，对前序发现进行最终裁决和呈现：

• 任务A：硬编码密钥审计。HardcodedAuditAgent对Joern扫描出的“硬编码密钥”进行二次过滤。Joern的规则匹配可能会误报很多，比如String password = “${db.password}”（这是配置占位符）或String key = “test-key”（这是测试代码）。AI在这里进行语义判断，过滤掉明显的误报，只保留真正有风险的硬编码凭据。

• 任务B：漏洞验证与评分。VulnVerificationAgent是最终的“审判官”。它只从向量库中加载那些被标记为“可控”的数据流和“高危”的Joern发现，极大地缩减了上下文。AI基于以下严格标准进行最终验证：

  1. 可达性：这个漏洞接口是否对外网开放？访问需要什么权限？
  2. 数据流真实性：Joern给出的数据流路径在代码中是否真实、完整地存在？
  3. 利用可行性：是否存在有效的安全防护（如WAF）？是否需要特殊的触发条件？
  4. 证据充分性：必须有具体的文件名、行号、代码片段作为证据。严禁报告“如果服务端没有校验…”这类推测性漏洞。 对于确认为真的漏洞，它会根据一套自定义的三维CVSS评分模型（可达性R、影响I、复杂度C）计算严重等级，并生成详细的修复建议。

• 报告生成：所有结果汇总到ReportGenerator，生成一份结构清晰的Markdown格式审计报告，包含风险统计、漏洞详情（含PoC）、数据流链、鉴权分析等，可直接交付。

核心设计心得：这个流水线架构的关键在于“解耦”和“按需加载”。每个Agent职责单一，通过向量库共享数据，避免了将整个项目源码和原始Joern结果反复塞给AI。通过分批处理（Batch）和语义检索，单次审计的Token消耗从早期设计的约34万降低到了9.5万左右，降幅达72%，使得使用高性能但昂贵的模型（如Claude Opus）进行深度分析变得经济可行。

3. 核心模块实现细节与避坑指南

3.1 Joern集成的实战技巧

Joern是强大的引擎，但直接使用其命令行输出非常“粗糙”。我们的joern_runner.py封装了与Joern-CLI的交互。

关键实现：

1. 异步构建与查询：使用Python的asyncio并发执行多个.sc查询脚本，大幅缩短扫描时间。注意为javasrc2cpg命令设置合理的超时（如900秒），防止复杂项目构建卡死。
2. 输出解析：Joern的JSON输出结构复杂，需要编写健壮的解析器来提取routes、sinks、dataflows等关键字段。特别注意处理可能存在的空值或异常结构。
3. 工作空间管理：每次扫描在独立临时目录进行，扫描完成后清理CPG等中间文件，避免磁盘空间浪费和潜在冲突。

避坑指南：

• 版本兼容性：Joern和其底层的javasrc2cpg插件更新可能带来不兼容的API变化。建议在项目中锁定特定版本，并在Dockerfile或安装脚本中明确指定。
• 内存消耗：对于超大型项目（>50万行），Joern构建CPG可能消耗大量内存（超过4GB）。建议在配置中提供JVM参数调优选项，例如-Xmx8g。
• 自定义查询脚本：项目自带的.sc脚本是起点。在实际使用中，你很可能需要根据目标项目的技术栈（例如使用了特定的RPC框架或ORM）编写自定义的查询脚本，来发现特定的Source和Sink。

3.2 AI Agent的Prompt工程精髓

Agent的能力上限，很大程度上由System Prompt决定。我们的Prompt设计遵循以下原则：

1. 角色定义清晰：例如，给VulnVerificationAgent的Prompt开头就是“你是一名专注Java Web安全的资深审计专家，以严谨和零误报著称。”
2. 输出格式严格：强制要求AI以指定的JSON Schema输出。这对于后续的程序化处理至关重要。在Prompt中提供完整的、合法的JSON示例比单纯描述结构更有效。
3. 规则具体化：避免模糊指令。例如，在漏洞验证Prompt中，我们明确列出了6条“不报告”规则：

   1. 不报告仅因使用${}但无法证明用户输入可控的MyBatis语句。
   2. 不报告框架已提供默认防护的情况（如Spring MVC对路径遍历的防护）。
   3. 不报告纯粹的“信息泄露”类问题，除非能证明可获取敏感数据。
   4. 不报告没有具体代码证据的“潜在”越权。
   5. 不报告已被正确编码或过滤的XSS点。
   6. 不报告仅存在于测试代码(src/test/)中的漏洞。

4. 提供上下文知识：在AuthAnalysisAgent的Prompt中，我们内置了一个“常见URI解析绕过模式表”，帮助AI识别;、..;/、//等绕过手法。还提供了一个简化的“框架版本-CVE”映射表，辅助风险判断。

一个Prompt的示例片段（路由分析Agent）：

你是一个Java Web应用路由分析专家。你的任务是从提供的Java源码中，提取所有HTTP API端点（路由）。 请严格按照以下JSON格式输出，且只输出JSON： { "routes": [ { "path": "/api/v1/user/{id}", "method": "GET", "handler_class": "com.example.UserController", "handler_method": "getUserById", "params": [ {"name": "id", "java_type": "Long", "http_location": "PATH"} ], "burp_template": "GET /api/v1/user/§1§ HTTP/1.1\nHost: example.com" } ], "framework_info": {"primary": "Spring MVC", "version_hint": "Spring Boot 2.x"} } 提取规则： 1. 识别注解：@RequestMapping, @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping。 2. 识别Servlet：继承HttpServlet的类中的doGet/doPost等方法，或@WebServlet注解。 3. 识别JAX-RS：@Path, @GET, @POST等注解。 4. 参数解析： - @RequestParam -> Query - @PathVariable -> Path - @RequestBody -> Body (注明类型，如JSON) - @RequestHeader -> Header - @CookieValue -> Cookie 5. 合并类级别和方法级别的路径。

3.3 向量知识库的巧妙运用

AuditStore（基于ChromaDB）是整个架构的“中枢神经系统”，它解决了大模型上下文有限的核心矛盾。

核心设计：

• 分集合存储：将不同类型的数据存入不同的集合（sourcecode,routes,joern,dataflows,auth,vulns）。每个文档都包含原始内容（或压缩内容）和丰富的元数据（metadata）。
• 语义检索：Agent不直接传递大段代码，而是向向量库“提问”。例如，AuthAnalysisAgent需要找鉴权代码时，会执行类似store.query(“sourcecode”, “authentication filter security config”, where={“filetype”: [“filter”, “config”]})的查询。向量库会返回与“authentication”等关键词语义最相关的代码片段。
• 按需加载：RouteParamAgent分析路由时，一次只加载一小批（如10个）路由信息。然后根据这批路由的处理类名，再去向量库检索与之相关的业务逻辑代码。这样就避免了将整个项目的Service层代码一次性塞入上下文。

性能优化点：

• 元数据过滤优先：在语义检索前，先利用元数据（如filetype）进行过滤，能大幅缩小搜索范围，提升精度和速度。
• 批量操作：对于路由、数据流等可能成百上千条的数据，采用分批写入和查询的策略。
• 持久化：ChromaDB支持持久化到磁盘，这意味着一次审计的中间结果可以保存，后续如果调整AI分析逻辑，可以无需重新运行耗时的Joern扫描，直接从向量库加载数据进行重新分析，极大提升了迭代效率。

3.4 报告生成：从数据到洞察

一份好的审计报告，不仅要罗列问题，更要帮助开发者快速理解风险。我们的ReportGenerator生成的Markdown报告包含以下部分：

1. 执行摘要：项目名称、分析时间、使用的框架、发现的路由总数、漏洞统计概览（饼图或表格）。
2. 风险等级分布：用表格展示Critical, High, Medium, Low各级别的漏洞数量，一目了然。
3. 漏洞详情：这是报告的核心。每个漏洞包含：
   • 唯一ID与标题：如[VULN-001] UserController SQL注入漏洞。
   • 风险矩阵：一个表格，清晰展示严重等级、CVSS分数、可达性、影响、复杂度、可利用性状态（Confirmed/Pending）。
   • 详细描述：用自然语言描述漏洞成因、位置和潜在影响。
   • 数据流执行链：以步骤列表或伪代码形式，展示从Source到Sink的完整路径。
   • PoC请求：提供可直接在Burp Suite或curl中复现的HTTP请求包，替换掉关键参数。
   • 修复建议：给出具体的、可操作的代码修复方案，例如“使用PreparedStatement并参数化查询”或“在调用Files.copy前对输入路径进行规范化校验”。
4. 鉴权分析详情：展示识别的安全框架、发现的潜在绕过点、以及每个路由的鉴权状态（如PUBLIC,AUTHENTICATED,ADMIN）。
5. 硬编码凭证列表：列出发现的真实硬编码密钥，并对值进行部分脱敏显示（如pass****rd）。
6. 附录：可能包含完整的路由列表、数据流图（如果生成的话）等补充信息。

报告价值：我们刻意避免了生成“封面华丽但内容空洞”的报告。报告中的每一个漏洞，都必须有具体的代码文件、行号、代码片段作为证据，以及经过AI验证的可复现的PoC。这确保了报告的可信度和可行动性，让开发和安全团队能快速定位并修复问题。

4. 支持的漏洞与框架覆盖

Java-Audit的设计目标是覆盖Java Web应用中最常见和最高危的安全问题。其能力边界由Joern的检测能力和AI的推理能力共同决定。

4.1 漏洞类型覆盖矩阵

4.2 Java Web框架支持

工具通过结合静态规则（Joern脚本）和AI语义理解，支持主流的Java Web开发框架：

• Spring Boot / Spring MVC：全面支持。能精准识别@RestController,@RequestMapping及其变体，解析@RequestParam,@PathVariable,@RequestBody,@RequestHeader等参数绑定。能分析Spring Security的@PreAuthorize,@Secured注解以及SecurityFilterChain配置。
• Servlet / JSP：支持通过@WebServlet注解或web.xml配置的Servlet，能识别HttpServlet子类中的doGet/doPost方法。
• JAX-RS (如 Jersey)：支持@Path,@GET,@POST等注解，以及@QueryParam,@PathParam参数。
• Struts2：支持识别继承ActionSupport的Action类及execute方法，能分析struts.xml配置（需AI读取XML文件）。
• Apache Shiro：支持识别Shiro的@RequiresAuthentication,@RequiresPermissions,@RequiresRoles注解，以及shiro.ini或Java Config配置。
• JWT：能识别常见的JWT库（如jjwt）的签名验证、解析等相关调用。
• MyBatis / MyBatis-Plus：能识别Mapper XML中的SQL语句，并关键地区分安全的#{}和存在注入风险的${}用法。

5. 常见问题、排查技巧与优化方向

在实际部署和使用Java-Audit的过程中，我们踩过不少坑，也总结了一些经验。

5.1 安装与依赖问题

问题1：Joern安装失败或构建CPG超时。

• 排查：首先确认Java版本（需要JDK 11或17）。Joern对Java环境比较敏感。
• 解决：建议使用Docker运行Joern，这是最干净的方式。在我们的docker-compose.yml中，将项目目录挂载到Joern容器内，通过容器内命令执行扫描，可以避免宿主机环境差异。
• 优化：对于特别大的项目，可以调整javasrc2cpg的JVM堆内存参数（-Xmx），例如设置为-Xmx8g。如果项目包含大量非Java资源文件，可以在配置中指定源码目录，避免扫描无关文件。

问题2：AI API调用失败、超时或返回非JSON格式。

• 排查：检查config.yaml中的base_url和api_key是否正确；确认网络能访问API服务；查看模型是否支持足够长的上下文（如Claude 3.5 Sonnet支持200K）。
• 解决：
  • 超时：在BaseAgent中增加请求超时和重试逻辑。对于长上下文分析，将超时时间设置为300秒以上。
  • 非JSON响应：这是Prompt工程不严谨的常见结果。在解析AI响应前，增加一层健壮性处理：尝试用json.loads()解析，如果失败，则尝试用正则表达式提取可能被Markdown代码块包裹的JSON，或者记录错误并降级处理。更根本的解决方法是优化Prompt，强调“只输出JSON，不要任何额外解释”。
  • 频率限制：实现简单的令牌桶算法进行限流，避免触发API的速率限制。

5.2 分析与结果问题

问题3：AI分析结果漏报严重，尤其是业务逻辑漏洞。

• 排查：检查提供给AI的上下文是否足够。RouteParamAgent是否成功检索到了相关的业务逻辑代码（ServiceImpl）？向量库中sourcecode集合的元数据filetype分类是否准确？
• 解决：
  • 优化java_compressor.py的Aggressive模式规则，确保不会过度裁剪掉包含业务逻辑判断（如if (user.getId().equals(currentUserId))）的代码。
  • 调整向量库的检索策略。尝试在查询时，不仅检索对应的ServiceImpl，也检索其直接调用的Dao或Mapper层代码。
  • 审视Prompt中对“业务逻辑漏洞”的定义和指令是否清晰。可以增加示例，教AI如何识别未校验的资源ID、金额篡改等场景。
• 优化方向：可以训练一个专门的“业务逻辑漏洞分类器”微调模型，或者引入基于代码属性图的更复杂的模式识别作为AI的补充提示。

问题4：误报率仍然偏高，AI有时会“臆想”出漏洞。

• 排查：这是AI代码审计的经典挑战。检查VulnVerificationAgent的Prompt中“不报告”规则是否足够严格和具体。
• 解决：
  • 在Prompt中强化“必须有直接代码证据”的原则。要求AI在输出漏洞时，必须引用包含漏洞代码的文件名和行号。
  • 引入“置信度评分”。让AI在判断漏洞时，输出一个0-1的置信度分数。在报告生成阶段，可以设置一个阈值（如0.7），低于此阈值的发现仅作为“提示”或“待确认”项列出，而非确凿漏洞。
  • 人工复核回路：设计一个机制，将AI标记的漏洞，由人工进行快速确认或驳回。这些反馈可以收集起来，作为未来优化Prompt或模型的宝贵数据。

问题5：对某些冷门框架或自定义组件支持不好。

• 解决：框架支持能力是动态扩展的。
  1. 扩展Joern脚本：在joern_scripts/目录下为新的框架编写查询脚本。例如，要支持Dubbo，可以写一个find_dubbo_providers.sc来识别@Service注解的Dubbo服务。
  2. 扩展路由分析Agent的Prompt：在route_analysis.md中，增加对新框架路由和参数注解的识别规则说明。
  3. 自定义Sink：在find_sinks.sc中，添加该框架特有的危险函数。例如，某个自定义的XML解析库可能存在危险方法CustomParser.unsafeParse()。

5.3 性能与成本优化

问题6：审计大型项目耗时过长，API调用成本高。

• 现状：经过优化，一个中型项目（约500个Java文件）的完整审计流程可在10-20分钟内完成，消耗约10万Token。
• 进一步优化：
  • 增量分析：利用向量库的持久化特性，如果项目只有部分代码变更，可以只对变更文件重新进行源码压缩和索引，然后重新运行相关的Agent，而非全量分析。
  • 模型分级：对于路由提取、硬编码过滤这类相对简单的任务，可以使用更便宜、更快的模型（如Claude Haiku）。对于漏洞验证、可控性分析这类复杂任务，再使用能力更强的模型（如Claude Opus）。
  • 缓存策略：对于常见开源库的代码（如Spring Framework本身），其安全模式是相对固定的。可以构建一个“安全知识缓存”，首次分析后，其分析结果（如“Spring的@PathVariable默认是安全的”）可以缓存，后续项目遇到相同代码模式时直接引用，减少AI调用。
  • 并行度调优：调整各阶段Agent的batch_size和并发数量，找到资源消耗（CPU、内存、网络）和速度之间的最佳平衡点。

最后一点个人体会：开发这样一个工具，最大的挑战不是技术实现，而是在“自动化”和“准确性”之间找到平衡。纯粹的规则引擎（SAST）准确率低，纯粹的大模型（ChatGPT直接读代码）成本高且不可控。将两者结合，让SAST做“显微镜”，AI做“大脑”，是目前看来比较务实的一条路径。这个项目还有很多可以深挖的地方，比如引入动态分析（DAST）的结果进行交叉验证，或者结合SCA工具分析第三方库漏洞。但无论如何，它的目标始终是成为一个能真正提升安全工程师效率、减少重复劳动的“副驾驶”，而不是完全取代人类的“自动驾驶”。在安全这个领域，人的经验和判断，永远是不可或缺的最后一道防线。