Java Security Audit - AI驱动的Java代码审计
AI驱动的Java代码安全审计技能,实现系统化、高覆盖率的漏洞挖掘。使用场景: (1) 审计Java/Kotlin项目寻找安全漏洞(0day挖掘、代码审计、安全评估) (2) 企业级代码库的安全审计(支持大型项目) (3) 需要高质量、低幻觉率的安全审计报告 (4) CI/CD集成的前期漏洞发现 触发关键词:Java审计、代码审计、安全审计、漏洞挖掘、0day、安全评估、Java security audit、code review for security
安装 / 下载方式
TotalClaw CLI推荐
totalclaw install skilldb:auroraproudmoore~java-audit-skillcURL直接下载,无需登录
curl -fsSL https://skills.taituai.com/api/skills/skilldb%3Aauroraproudmoore~java-audit-skill/file -o java-audit-skill.mdGit 仓库获取源码
git clone https://github.com/openclaw/skills/commit/fe64de0e5e7543bb0ca51a27d73462e5ba6e5826# AI+Java 代码审计 Skill
本 Skill 将资深审计员的工作方法和质量标准编码成 LLM 可执行的协议,解决裸跑 LLM 覆盖率低、幻觉高、优先级混乱等核心痛点。
email : aurora1219@139.com
## 核心理念
**LLM 有能力,缺纪律。** Skill 不教 LLM "什么是 SQL 注入",而是给它装上资深审计员的工作骨架——定义工作流、分配资源、设置护栏、标准化输出。
## 6 阶段审计流水线
```
Phase 0 → Phase 1 → Phase 2 → Phase 2.5 → Phase 3 → Phase 4 → Phase 5
代码度量 项目侦察 全量审计 覆盖率门禁 漏洞验证 规则沉淀 标准化报告
```
每个 Phase 有明确的输入、输出和质量标准,中间结果全量持久化到文件。
---
## Phase 0: 代码库度量
**目标**: 统计项目规模,计算审计工作量,为 Agent 分配提供依据。
### 执行脚本
```bash
# 统计代码行数和文件数(注意括号)
find . \( -name "*.java" -o -name "*.kt" -o -name "*.xml" \) | xargs wc -l | tail -1
# 统计各类型文件
find . -name "*.java" | wc -l
find . -name "*.kt" | wc -l
find . -name "*.xml" | wc -l
# 统计 Controller 数量
grep -r "@Controller\|@RestController\|@WebServlet" --include="*.java" | wc -l
# 统计模块数(Maven 多模块项目)
find . -name "pom.xml" | wc -l
# 统计模块数(Gradle 多模块项目)
find . -name "build.gradle" -o -name "build.gradle.kts" | wc -l
```
### 输出文件: `metrics.json`
```json
{
"total_loc": 131000,
"java_files": 847,
"kt_files": 0,
"xml_files": 156,
"controllers": 40,
"modules": 5,
"complexity_score": "HIGH"
}
```
---
## Phase 1: 项目侦察 & EALOC 资源分配
### 1.1 Tier 分类规则
| 规则 | 条件 | Tier | 分析深度 |
|------|------|------|----------|
| Rule 0 | 第三方库源码 | SKIP | 不审计 |
| Rule 1 | Layer 1 预扫描有 P0/P1 候选项 | T1 | 动态提升 |
| Rule 2 | 含 @Controller/@RestController/@WebServlet/Filter | T1 | 完整深度分析 |
| Rule 3 | 含 @Service/@Repository/@Mapper | T2 | 聚焦关键维度 |
| Rule 4 | 类名含 Util/Helper/Handler | T2 | 聚焦关键维度 |
| Rule 5 | .properties/.yml/security.xml | T2 | 聚焦关键维度 |
| Rule 6 | 含 @Entity/@Table/@Data | T3 | 快速模式匹配 |
| Rule 7 | 未匹配任何规则 | T2 | 保守兜底 |
### 1.2 EALOC 公式
```
EALOC = T1_LOC × 1.0 + T2_LOC × 0.5 + T3_LOC × 0.1
```
**Agent 分配**: `Agent数量 = ceil(EALOC / 15000)`
### 1.3 输出文件: `tier-classification.md`
```markdown
# Tier 分类结果
## 模块: module-biz (131,000 LOC)
| 子任务 | Agent | 文件范围 | 文件数 | Tier分布 | EALOC |
|--------|-------|---------|-------|---------|-------|
| 1a | Agent 1 | controller/ | 147 | T1: 14K | 14,000 |
| 1b | Agent 2 | service/ + dao/ | 200 | T2: 30K | 15,000 |
| 1c | Agent 3 | entity/ + vo/ | 500 | T3: 87K | 8,700 |
**总 EALOC**: 37,700 → 需要 3 个 Agent
```
---
## Phase 2: 三层审计架构
### Layer 1: 全量预扫描(不用 LLM)
使用 ripgrep + Semgrep 扫描所有文件,按 P0-P3 标记危险模式。
#### P0 级危险模式(RCE/反序列化)
```bash
# 反序列化全家族
grep -rn "ObjectInputStream\|XMLDecoder\|XStream" --include="*.java"
grep -rn "JSON\.parseObject\|JSON\.parse\|@type" --include="*.java" # Fastjson
grep -rn "enableDefaultTyping\|activateDefaultTyping" --include="*.java" # Jackson
grep -rn "HessianInput\|Hessian2Input" --include="*.java" # Hessian
# SSTI 全引擎
grep -rn "Velocity\.evaluate\|VelocityEngine\|mergeTemplate" --include="*.java"
grep -rn "freemarker\.template\|Template\.process\|FreeMarkerConfigurer" --include="*.java"
grep -rn "SpringTemplateEngine\|TemplateEngine\.process" --include="*.java" # Thymeleaf
# 表达式注入
grep -rn "SpelExpressionParser\|parseExpression\|evaluateExpression" --include="*.java"
grep -rn "OgnlUtil\|Ognl\.getValue\|ActionContext" --include="*.java"
# JNDI 注入
grep -rn "InitialContext\.lookup\|JdbcRowSetImpl\|setDataSourceName" --include="*.java"
# 命令执行
grep -rn "Runtime\.getRuntime\|ProcessBuilder\|exec(" --include="*.java"
```
#### P1 级危险模式(SQL 注入/SSRF/文件操作)
```bash
# SQL 注入风险
grep -rn "Statement\|createStatement\|executeQuery\|executeUpdate" --include="*.java"
grep -rn '\$\{' --include="*.xml" # MyBatis ${} 注入
# SSRF
grep -rn "URL\(|HttpURLConnection\|HttpClient\|RestTemplate\|WebClient" --include="*.java"
# 文件操作
grep -rn "FileInputStream\|FileOutputStream\|FileWriter\|Files\.read\|Files\.write" --include="*.java"
grep -rn "getOriginalFilename\|transferTo\|MultipartFile" --include="*.java" # 文件上传
```
#### P2 级危险模式(认证/授权/加密)
```bash
# 认证相关
grep -rn "@PreAuthorize\|@Secured\|@RolesAllowed\|hasRole\|hasAuthority" --include="*.java"
grep -rn "permitAll\|anonymous\|authenticated" --include="*.java"
# 加密相关
grep -rn "MessageDigest\|Cipher\|SecretKey\|PasswordEncoder" --include="*.java"
```
### Layer 2: 双轨审计模型
每个 Agent 执行两条并行的审计轨道:
#### 轨道 1: Sink-driven(从危险代码往上追)
发现 `Runtime.exec(cmd)` → 追踪 `cmd` 参数来源 → 检查是否有过滤 → 判断是否来自用户输入
#### 轨道 2: Control-driven(从端点往下查安全控制)
发现 `/api/admin/deleteUser` 端点 → 检查是否有认证注解 → 检查是否有权限校验
**为什么需要两条轨道?** 认证绕过这类漏洞,单独用 Sink-driven 找不到——该漏洞不是某行代码有问题,而是某个端点缺少了应有的权限检查。
### Layer 2.5: 代码分析深度检查
对于 Semgrep 规则无法覆盖的漏洞类型,需要通过代码分析进行判断:
#### 业务逻辑漏洞
```
检查要点:
1. 支付金额:金额是否来自前端?是否有后端校验?
2. 库存并发:是否有并发控制?检查和扣减是否原子操作?
3. 状态机:状态流转是否有前置条件校验?
```
#### 越权漏洞
```
检查要点:
1. 水平越权:数据查询是否校验归属?userId 是否从 Session 获取?
2. 垂直越权:管理接口是否有权限注解?前后端权限是否一致?
```
#### 依赖安全
```
检查要点:
1. 读取 pom.xml/build.gradle
2. 提取 Log4j、Fastjson、Shiro、Spring 等关键依赖版本
3. 使用 web_search 搜索漏洞信息
- 搜索格式: "<组件名> <版本号> CVE vulnerability"
- 示例: "log4j 2.14.1 CVE", "fastjson 1.2.79 vulnerability"
4. 分析搜索结果中的 NVD、官方公告
5. 标记需要升级的依赖
```
**联网搜索示例**:
```
发现依赖:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version>
</dependency>
使用 web_search:
query: "log4j-core 2.14.1 CVE vulnerability"
分析结果:
- CVE-2021-44228 (Log4Shell)
- CVSS: 10.0 Critical
- 影响版本: 2.0-beta9 to 2.15.0
- 修复版本: 2.17.1+
结论: 需要升级到 2.17.1+
```
#### 运行时配置
```
检查要点:
1. Session 超时、Cookie Secure/HttpOnly
2. Actuator 端点暴露
3. 数据库密码明文存储
4. 调试模式开启
```
**详细判断方法见**: [references/vulnerability-conditions.md](references/vulnerability-conditions.md) 第 16-20 节
### Layer 3: 调用链语义级验证
优先使用 LSP 做语义级追踪:
```
候选 Sink (Statement.executeUpdate(sql))
↓ goToDefinition → 确认实际实现
↓ findReferences → 向上追踪所有调用者
↓ hover → 获取中间变量类型
↓ 重复 findReferences → 直到到达 Controller 入口或确认不可达
↓ 记录完整调用链,每一跳标注 文件:行号
```
LSP 不可用时退化到 Grep + Read 手动追踪。
---
## Phase 2.5: 覆盖率门禁
**这是反 LLM 天性的核心设计**——LLM 倾向于跳过"看起来不重要"的代码,而漏洞恰恰喜欢藏在那些地方。
### 模块覆盖矩阵
```markdown
| # | 模块路径 | LOC | EALOC | Controller数 | 风险评估 | 分配 Agent | Phase2 状态 | Phase3 状态 |
|---|---------|-----|-------|-------------|---------|-----------|------------|------------|
| 1 | module-auth | 8,000 | 5,200 | 6 | HIGH | Agent 1 | 完成 | 完成 |
| 2 | module-gateway | 12,000 | 7,800 | 8 | HIGH | Agent 2 | 完成 | 进行中 |
| 3 | module-biz | 131,000 | 37,700 | 40 | HIGH | Agent 3a~3c | 部分完成 | 未开始 |
```
### 文件级覆盖率验证
每个 Agent 输出必须包含审阅文件清单:
```markdown
| # | 文件路径 | Tier | 状态 | 发现数 |
|---|---------|------|------|-------|
| 1 | AuthController.java | T1 | 完成 已审阅 | 2 |
| 2 | ShiroConfig.java | T1 | 完成 已审阅 | 1 |
| 3 | UserServiceImpl.java | T2 | 完成 已审阅 | 0 |
| 4 | User.java | T3 | 完成 已审阅 | 0 |
| 5 | com/alibaba/fastjson/JSON.java | SKIP | 跳过 第三方库 | - |
```
**门禁检查**: 拿这份清单和 `find` 命令的实际文件列表做 diff。清单里没出现的文件 = 漏审。
### 门禁判断逻辑
```
收到每个 Agent 结果后立即执行:
1. 读取 Agent 输出的「审阅文件清单」
2. 与实际文件列表交叉验证
3. 覆盖率 = 100% → 该 Agent 通过
覆盖率 < 100% → 立即为未覆盖文件启动补扫 Agent
所有 Agent 完成后:
- 全部模块 Phase2 = 完成 → 进入 Phase 3
- 存在 未开始 或 部分完成 → 启动补充 Agent → 循环直到 100%
```
**禁止在覆盖率 < 100% 时进入 Phase 3。没有例外。**
---
## Phase 3: 漏洞验证 & DKTSS 评分
### 反幻觉 5 条铁律
1. **报告漏洞前必须用 Read 验证文件存在**
2. **代码片段必须来自实际 Read 输出,不得编造**
3. **调用链每一跳必须标注 文件:行号**
4. **不确定的发现标记为 HYPOTHESIS,不得标记为 CONFIRMED**
5. **宁可漏报,不可误报**
### 漏洞成立条件判断
**详见 [references/vulnerability-conditions.md](references/vulnerability-conditions.md)**
示例 - Fastjson 反序列化判断流程:
```
发现 JSON.parseObject() / JSON.parse() 调用
↓
检查版本:
< 1.2.68 → 直接可利用
1.2.68-1.2.80 → 检查 classpath 是否有特定依赖(groovy/jython/aspectj/commons-io)
≥ 1.2.83 → 检查 safeMode 配置
```
### DKTSS 评分体系
**详见 [references/dktss-scoring.md](references/dktss-scoring.md)**
核心公式:`Score = Base - Friction + Weapon + Ver`
- **Base**: 按漏洞类型和实际影响评分
- **Friction**: 实战阻力(访问路径/权限门槛/交互复杂度)
- **Weapon**: 武器化程度
- **Ver**: 版本因子
### 状态定义
| 状态 | 定义 | 要求 |
|------|------|------|
| **CONFIRMED** | 已验证可利用 | PoC 可执行,调用链完整,影响明确 |
| **HYPOTHESIS** | 疑似漏洞,需人工验证 | 发现可疑模式但无法完全确认 |
**关键原则**: 宁可标记为 HYPOTHESIS 让人工验证,也不要把不确定的发现标记为 CONFIRMED 污染报告可信度。
---
## Phase 4: Semgrep 规则沉淀
将确认的漏洞模式转换为 Semgrep 静态分析规则(YAML 格式),可集成到 CI/CD 流水线。
示例规则:
```yaml
rules:
- id: velocity-ssti
patterns:
- pattern: Velocity.evaluate($