自动化审计&agent的一些思路分享

我此前写过两个项目：

• 基于asm tree实现的变量级别的java静态扫描器
• 基于tree sitter实现的多语言的AI自动书代码审计

但是结果在4月30日被龙虾误删了，只能找到索引的那种，于是我给龙虾加了一层锁：星核协作体系行为监控，具体可参考：https://mp.weixin.qq.com/s/JHB59dccwqHbG16njaftrg

这篇文章首先会整理一下我的实现思路，然后是看一看一些新的项目有没有什么值得借鉴的地方可以为后续的重构增加一些参考。

死去的亡魂

当时被删除心痛了两天，最近忙完了一些东西还是得写一写不然忘了

Java 字节码静态代码扫描器

这是一款基于ast tree实现的变量级别的java静态扫描器，他的功能大致如下：

• 通过扫描class和jar包，支持高版本jdk（本地模块读取依赖）
• 使用neoj4进行基础图信息的存储，也会存储多态信息
• 自定义规则集，当时是收集并验证了40+漏洞规则集并在github上找了两个项目（jdk8和jdk17各一个）并识别出了文件上传、xss、xxe、ip伪造等漏洞
• 前后端分离，在前端完成图数据库的构建、清理、调用链、污点路径的查询更便捷，同时支持代码切片展示

我当时借助这款工具做过一些CVE分析，典型案例就是：https://mp.weixin.qq.com/s/whIZjuhsKfiI_lI-SHLanw 不过当时还没写UI，所以不好展示

实现的原理和细节：

• 扫描class和jar包时通常是非本地jdk依赖，而为了构建更完整的关系或辅助漏洞分析，那么扫描本地依赖是必须的，jdk8及以下版本在java安装目录中，jdk9及以上要通过本地模块去读取所有class文件
• neoj4的存储信息：
  • node：函数、类、污染节点（变量级别）
  • relationship：调用、继承、重载、重写、污染关系
• 方法级别污点分析器：通过扫描所有函数节点和类节点，构建neoj4图数据库，然后通过本地局部变量表和一个污染链路集合去追踪局部变量的污染状态并不断合并污染链路，最后返回所有污染链路
• 跨方法链路追踪：通过提取路由标记source污染源，然后先通过source方法和sink方法定链路，然后再验证链路不断传播污染源从而得到跨越方法的污染链路
• 传播：需要处理各种场景的污染传播情况，比如返回值污染、引用污染等，不止局限于+、.append、数组这样的情况，这可能也是最复杂的地方
• 规则集：很多函数实际有很多重载，最好不仅支持方法级别的定位，还要支持多方法的定位，这通过neoj4很容易实现查询，表明这个主要是尽量避免规则集变得庞大，因为一个函数可能有十来个重写，具有类似sink的方法可能几十个，按方法级别写规则集不现实，哪怕现在可以AI写，但还是需要人工验证的
• 切片展示：有了调用链路可以很轻松切片，有了变量级别的污染链路（source->变量1->变量2-> sink）就可以很方便地进行污染变量高亮

这个项目当时没有从CFG和SSA的角度去做，所以在维护上可能会比较麻烦，因此心痛少了一点，顺便简要介绍一下CFG和SSA：

• CFG = 基本块 + 控制流边，把程序变成图。适合处理分支、循环、异常等结构
• SSA= 变量版本化，一个变量只赋值一次，避免局部变量表变量的重新赋值导致分析变得复杂易错

python多语言Ai静态代码扫描器

这个相对来说就很简单了，尤其是在写完上一个项目的基础上，甚至当时本来是准备做成skill的，所以不算很完善，删了有点心痛但不多。实现思路大致如下：

• 基于 Python tree-sitter 实现多语言 AST 解析从而构建neoj4图数据库
• 根据链路提取完整的漏洞代码块链路，然后把漏洞代码块链路直接喂给AI就可以了，当然中间还会有些细节，比如如何让AI识别source和sink，污染传播的规则，这都是通过脚本+提示词实现的
• 通过提示词完成输出的约束

当时其实还准备做沙箱验证来着，但想起很早之前分析的DeepAudit用python 模拟java执行就绷不住了，沙箱验证可能是相对复杂的，当时忙其他的就没考虑了，但可以作为后续要考虑的一个方向。

开源项目学习

PHP-Code-Audit-Skill

项目路径在：https://github.com/0xShe/PHP-Code-Audit-Skill，是一套面向 PHP Web 的白盒代码安全审计 Skill 集合。

我对PHP没那么熟悉，大概就是初学网安靶场级别的，但我会基于以下角度去梳理这个项目：

• 项目的基本架构
• source：路由提取后污染源如何识别
• propagation：污染如何传播
• sink：汇聚点如何识别

基本架构

由于都是文档，直接按文档结构去看：

  php-audit-pipeline/SKILL.md          # 主编排文档（方法论）
  ├── 阶段1: 侦察   → 调用 php-route-mapper, php-auth-audit, php-vuln-scanner, 框架audit
  ├── 阶段2: 建模   → 本质是 route-tracer 的输出描述（不是独立步骤）
  ├── 阶段2.5: 静态兜底 → 全局sink扫描（CMD/EXPR/DESER/FILE）
  ├── 阶段3: 分批追踪 → 调用 php-route-tracer（对高危路由）
  ├── 阶段4: 分类审计 → 调用 php-*-audit 各种漏洞类型
  └── 阶段5: 汇总报告 → 输出唯一合并MD + 利用链聚合

  shared/
  ├── EVIDENCE_POINT_IDS.md     # 证据点ID字典（EVID_*）
  ├── IO_PATH_CONVENTION.md      # 路径别名约定
  ├── PHP_SINK_REFERENCE.md      # Sink类型定义与验证规则
  └── SEVERITY_RATING.md         # 严重度评级公式

  php-*/SKILL.md (28个)          # 分类漏洞审计 skill

文档写的很复杂，简单来说：

• php-audit-pipeline：一个固定的workflow，
• php-*-audit：用于具体漏洞的审计
• shared/*：用于漏洞审计的参考规范
• php-route-mapper：识别路由
• php-route-tracer：做数据流追踪
• php-vuln-scanner：依赖安全审计

污染源识别

文档中说明会在阶段1做侦查：

• 识别技术栈（其实就是识别依赖）
• 枚举入口（请求路由）
• 枚举参数（要做变量级别的数据流和污点追踪必须找的入口）
• 其他的一些额外操作

这里的污染源就是路由和参数的组合，然后看看专门用于识别路由的php-route-mapper，同样是完全依赖模型能力去识别路由

污染源传播

在阶段二表明要对每个路由建立一条从入口参数到敏感sink的最短路径，并记录路径中的变量名变化、分支结构等信息，然后要求输出数据流链路。

所以传播的识别完全依赖模型能力

汇聚点识别

在阶段3使用PHP Route Tracer通过提取的路由进行分批追踪时按漏洞类型通过关键字去进行sink的识别，关键字也是写文档里面的，sink识别也完全依赖模型能力

汇总

skill文档整体写的很复杂，还包含很多看上去比较专业的术语，总体很混乱，是一个完全没有一个脚本的skill，倒是在php-vuln-scanner会使用composer audit去做依赖安全审计

思路汇总

从一个完整的项目出发并结合agent去记录一些思路，不考虑语言特性和实现复杂度：

1. 依赖分析
2. 知识图谱embedding或是构建neo4j调用图
3. 污染源识别，单纯的路由提取可能不太够，因为理论上数据库、本地配置都可以算是污染源，但通过脚本去提取效果不一定好，走embedding+rerank+AI判定应该可行
4. 汇聚点识别，同样基于embedding+rerank+AI判定
5. 传播规则通过提示词去写，但是需要基于脚本去提取每一对source-sink的完整链路，通过RAG去从source-sink检索出完整链路也许也可行，总体就是完整链路+传播规则去做变量级别的污点追踪，当然污染源需要标记对应的参数和变量
6. 沙箱验证，通过agent自己搭建环境从而完成验证
7. 输出规范

所有的skill都使用脚本+文档规范去约束

基于以上思路做任务拆分：

• 侦查阶段：项目代码embedding（或是构建neo4j调用图）、依赖分析、污染源识别、汇聚点识别是前置简单任务
• 分析阶段：污点追踪是关键复杂任务，可以对每一对source-sink走react推理，会涉及知识图谱检索工具或是neo4j查询工具使用
• 验证阶段：沙箱验证是关键复杂任务，可以使用Plan-and-Execute去规划漏洞环境的搭建和验证
• 交付阶段：输出规范是简单任务

不过是否要整体做个大的Plan-and-Execute然后再在每一个环节做Reflection质检也是可以考虑的，但为了保证效率和token消耗的平衡，走相对确定的workflow会比较合适，然后一些环节也可以做并行。

其他零散的思路：

• 在某个阶段做个反馈，去自动补充source和sink的规则集以增强侦查能力