java-audit-skill

name	java-audit-skill
description	AI驱动的Java/前端代码安全审计技能，实现系统化、高覆盖率的漏洞挖掘。使用场景： (1) 审计Java/Kotlin项目寻找安全漏洞（0day挖掘、代码审计、安全评估） (2) 审计前端项目（JavaScript/TypeScript/React/Vue）寻找安全漏洞 (3) 企业级代码库的安全审计（支持大型项目） (4) 需要高质量、低幻觉率的安全审计报告 (5) CI/CD集成的前期漏洞发现 触发关键词：Java审计、代码审计、安全审计、漏洞挖掘、0day、安全评估、前端审计、React审计、Vue审计、Java security audit、code review for security

AI+Java/前端 代码审计 Skill

本 Skill 将资深审计员的工作方法和质量标准编码成 LLM 可执行的协议，解决裸跑 LLM 覆盖率低、幻觉高、优先级混乱等核心痛点。

支持的语言类型

语言类型	框架支持	主要检查内容
Java/Kotlin	Spring、Spring Boot、Struts、Jersey、Dubbo、gRPC	反序列化、SQL注入、命令执行、认证绕过、SSRF、文件操作
JavaScript/TypeScript	原生、Node.js	XSS、代码注入、原型污染、敏感信息泄露
React	React 16+、Next.js	dangerouslySetInnerHTML、href注入、SSR XSS
Vue	Vue 2/3、Nuxt.js	v-html XSS、模板注入、不安全渲染
混合项目	前后端分离	后端API安全 + 前端XSS/配置安全

脚本架构

⚠️ 重要：脚本已按语言类型拆分，职责清晰

scripts/
├── audit.py              # 通用入口（语言检测 + 路由分发）
├── java_audit.py         # Java/Kotlin 后端审计
└── frontend_audit.py     # JavaScript/React/Vue 前端审计

脚本职责

脚本	职责	包含功能
audit.py	通用入口	语言检测、路由分发、统一参数解析
java_audit.py	Java 审计	Java Tier 分类、Java 危险模式、EALOC 计算、覆盖率检查
frontend_audit.py	前端审计	前端 Tier 分类、前端危险模式、依赖检查、配置安全

调用流程

用户执行: python audit.py /path/to/project --scan --tier
                    ↓
              [audit.py]
                    ↓
         语言检测: detect_project_language()
                    ↓
    ┌───────────────┼───────────────┐
    │               │               │
  java          react/vue      mixed
    │               │               │
    ↓               ↓               ↓
[java_audit.py] [frontend_audit.py] [两者都执行]

使用方法

# 自动检测语言并执行审计
python scripts/audit.py /path/to/project --scan --tier

# Java 项目审计（直接调用）
python scripts/java_audit.py /path/to/java-project --scan --tier

# 前端项目审计（直接调用）
python scripts/frontend_audit.py /path/to/frontend-project --language react --scan --tier

核心理念

LLM 有能力，缺纪律。 Skill 不教 LLM "什么是 SQL 注入"，而是给它装上资深审计员的工作骨架——定义工作流、分配资源、设置护栏、标准化输出。

6 阶段审计流水线

Phase 0 → Phase 1 → Phase 2 → Phase 2.5 → Phase 3 → Phase 5 → Phase 4（可选）
 代码度量   项目侦察   多层审计   覆盖率门禁  漏洞验证  标准化报告   规则沉淀

每个 Phase 有明确的输入、输出和质量标准，中间结果全量持久化到文件。

⚠️ Phase 编号说明：

• Phase 0-3：核心审计流程（必须执行）
• Phase 5：标准化报告（在验证后生成）
• Phase 4：规则沉淀（可选，在报告后执行）

Phase 4 放在最后的原因：规则沉淀基于最终确认的漏洞（Phase 3 输出），且需要完整的报告（Phase 5 输出）作为参考。

---

Phase 0: 代码库度量

目标: 统计项目规模，计算审计工作量，为 Agent 分配提供依据。

语言检测（新增）

⚠️ 在开始审计前，必须先检测项目语言类型：

# 执行语言检测
python scripts/java_audit.py /path/to/project --detect-lang

检测结果决定审计流程：

语言类型	审计流程	Semgrep 规则集
java	Java 后端审计流程	java-rce.yaml, java-config.yaml, java-sqli.yaml
javascript	前端通用审计流程	js-security.yaml, frontend-config.yaml
react	React 审计流程	react-security.yaml, js-security.yaml
vue	Vue 审计流程	vue-security.yaml, js-security.yaml
mixed	前后端分离审计流程	Java 规则 + 前端规则

语言检测逻辑：

1. 统计文件扩展名：
   - .java/.kt → Java/Kotlin
   - .js/.ts/.jsx/.tsx/.vue → 前端

2. 检测框架特征：
   - pom.xml/build.gradle → Java 项目
   - package.json → 前端项目
   - react/vue 依赖 → React/Vue 项目

3. 判断项目类型：
   - 纯 Java/Kotlin → java
   - 纯前端 → javascript/react/vue
   - 前后端分离 → mixed

执行脚本

Linux/macOS (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/入口点数量（多种框架）
# 入口点定义详见 Phase 1 Tier 分类规则 Rule 2

# Spring MVC
grep -r "@Controller\|@RestController" --include="*.java" | wc -l

# 原生 Servlet
grep -r "@WebServlet\|extends HttpServlet\|implements Servlet" --include="*.java" | wc -l

# Struts Action
grep -r "extends ActionSupport\|implements Action\|@Action" --include="*.java" | wc -l

# Filter（也是 T1 级文件）
grep -r "@WebFilter\|implements Filter\|extends OncePerRequestFilter" --include="*.java" | wc -l

# 统计模块数（Maven 多模块项目）
find . -name "pom.xml" | wc -l

# 统计模块数（Gradle 多模块项目）
find . -name "build.gradle" -o -name "build.gradle.kts" | wc -l

Windows (PowerShell):

# 统计代码行数和文件数
Get-ChildItem -Recurse -Include *.java,*.kt,*.xml | Measure-Object -Property Length -Sum

# 统计各类型文件数
(Get-ChildItem -Recurse -Filter *.java).Count
(Get-ChildItem -Recurse -Filter *.kt).Count
(Get-ChildItem -Recurse -Filter *.xml).Count

# 统计 Controller/入口点数量（多种框架）
# Spring MVC
Select-String -Path (Get-ChildItem -Recurse -Filter *.java).FullName -Pattern "@Controller|@RestController" | Measure-Object | Select-Object -ExpandProperty Count

# 原生 Servlet
Select-String -Path (Get-ChildItem -Recurse -Filter *.java).FullName -Pattern "@WebServlet|extends HttpServlet|implements Servlet" | Measure-Object | Select-Object -ExpandProperty Count

# Struts Action
Select-String -Path (Get-ChildItem -Recurse -Filter *.java).FullName -Pattern "extends ActionSupport|implements Action|@Action" | Measure-Object | Select-Object -ExpandProperty Count

# Filter（也是 T1 级文件）
Select-String -Path (Get-ChildItem -Recurse -Filter *.java).FullName -Pattern "@WebFilter|implements Filter|extends OncePerRequestFilter" | Measure-Object | Select-Object -ExpandProperty Count

# 统计模块数（Maven）
(Get-ChildItem -Recurse -Filter pom.xml).Count

# 统计模块数（Gradle）
(Get-ChildItem -Recurse -Include build.gradle,build.gradle.kts).Count

输出文件: audit-metrics.json

{
  "total_loc": 131000,
  "java_files": 847,
  "kt_files": 0,
  "xml_files": 156,
  "controllers": 40,
  "modules": 5,
  "t1_loc": 14000,
  "t2_loc": 30000,
  "t3_loc": 87000,
  "ealoc": 37700,
  "project_size": "中型",
  "coverage_requirement": "95%",
  "build_system": "maven"
}

EALOC 计算

EALOC（Effective Audit Lines of Code）在 Phase 0 计算，用于判断项目规模和后续执行策略：

EALOC = T1_LOC × 1.0 + T2_LOC × 0.5 + T3_LOC × 0.1

项目规模	EALOC	覆盖率要求	执行策略
小型	< 15,000	100%	单会话完成，可简化流程
中型	15,000 - 50,000	95%	按模块拆分
大型	> 50,000	90%	必须拆分多 Agent

Tier 分类规则（用于 EALOC 计算）：

Tier	文件类型	权重
T1	Controller、Filter、Servlet、Action	× 1.0
T2	Service、DAO、Util、配置文件	× 0.5
T3	Entity、VO、DTO	× 0.1

使用 Python 脚本可生成更多输出：

# 度量 + Tier 分类
python scripts/java_audit.py /path/to/project --tier

# 度量 + 场景标签（Phase 1）
python scripts/java_audit.py /path/to/project --scenario

# 度量 + Layer 1 预扫描
python scripts/java_audit.py /path/to/project --scan

可生成的输出文件：

• audit-metrics.json - 项目度量数据
• tier-classification.md - Tier 分类报告（--tier）
• scenario-tags.json - API 场景标签（--scenario，Phase 1）
• p0-critical.md, p1-high.md, p2-medium.md - Layer 1 扫描报告（--scan）
• coverage-report.md - 覆盖率验证报告（--coverage）

---

Phase 1: 项目侦察 & EALOC 资源分配

1.1 业务场景标签

核心理念：不是所有 API 都需要深度审计。通过业务场景标签快速识别高风险 API，精准分配审计资源。

场景类型分类

场景类型	典型 API	默认风险等级	重点检查
FINANCIAL_TRANSACTION	支付、退款、转账	CRITICAL	金额篡改、并发竞争、状态机绕过
PRIVILEGED_OPERATION	用户管理、系统配置	HIGH	垂直越权、权限绕过
RESOURCE_ALLOCATION	下单、抢购、预约	HIGH	并发竞争、库存绕过
STATE_TRANSITION	审批、发货、退款	HIGH	状态机绕过、流程跳跃
DATA_ACCESS	订单详情、用户列表	MEDIUM	水平越权、信息泄露
USER_OPERATION	个人资料、修改密码	MEDIUM	认证绕过、密码安全
PUBLIC_ACCESS	首页、公告、公开文章	LOW	XSS、SSRF（可快速模式）

自动识别脚本

Linux/macOS (Bash):

# 识别资金交易接口
grep -rn "pay\|payment\|refund\|transfer\|withdraw" --include="*.java" --include="*.kt" | grep -i "mapping"

# 识别特权操作接口
grep -rn "@PreAuthorize.*ADMIN\|@Secured.*ADMIN\|hasRole.*ADMIN" --include="*.java" --include="*.kt"

# 识别公开访问接口
grep -rn "permitAll\|anonymous" --include="*.java" --include="*.kt"

Windows (PowerShell):

# 识别资金交易接口
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "pay|payment|refund|transfer|withdraw" | Select-String -Pattern "mapping" -CaseSensitive:$false

# 识别特权操作接口
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "@PreAuthorize.*ADMIN|@Secured.*ADMIN|hasRole.*ADMIN"

# 识别公开访问接口
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "permitAll|anonymous"

详细说明: references/business-scenario-tags.md

1.2 Tier 分类规则

规则	条件	Tier	分析深度
Rule 0	第三方库源码	SKIP	不审计
Rule 1	Layer 1 预扫描有 P0/P1 候选项	T1	动态提升
Rule 2	入口点类（详见下方）	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	保守兜底

Rule 2: 入口点类定义（T1 级文件）

入口点是接收外部 HTTP 请求的类，必须 100% 覆盖审计：

框架类型	入口点特征	示例
Spring MVC	@Controller, @RestController	@RestController public class UserController
原生 Servlet	@WebServlet, extends HttpServlet, implements Servlet	@WebServlet("/api/user") public class UserServlet
Struts 2	extends ActionSupport, implements Action, @Action	public class UserAction extends ActionSupport
Filter	@WebFilter, implements Filter, extends OncePerRequestFilter	@WebFilter("/*") public class AuthFilter
Jersey/JAX-RS	@Path, @Provider	@Path("/users") public class UserResource
Play Framework	extends Controller, extends Action	public class UserController extends Controller

扫描命令：

# Spring MVC
Select-String -Pattern "@Controller|@RestController"

# 原生 Servlet
Select-String -Pattern "@WebServlet|extends HttpServlet|implements Servlet"

# Struts 2
Select-String -Pattern "extends ActionSupport|implements Action|@Action"

# Filter
Select-String -Pattern "@WebFilter|implements Filter|extends OncePerRequestFilter"

# Jersey/JAX-RS
Select-String -Pattern "@Path|@Provider"

# 全部入口点
Select-String -Pattern "@Controller|@RestController|@WebServlet|extends HttpServlet|implements Servlet|extends ActionSupport|implements Action|@Action|@WebFilter|implements Filter|@Path"

1.3 EALOC 场景修正

基础 EALOC 计算：见 Phase 0（EALOC = T1_LOC × 1.0 + T2_LOC × 0.5 + T3_LOC × 0.1）

场景修正系数（用于高风险 API）：

场景	修正系数	原因
FINANCIAL_TRANSACTION（资金交易）	× 1.5	需要更深度审计
PRIVILEGED_OPERATION（特权操作）	× 1.2	越权风险高
RESOURCE_ALLOCATION（资源分配）	× 1.2	并发竞争风险
STATE_TRANSITION（状态变更）	× 1.2	状态机绕过风险
DATA_ACCESS（数据访问）	× 1.0	基准
USER_OPERATION（用户操作）	× 1.0	基准
PUBLIC_ACCESS（公开访问）	× 0.5	风险较低

修正后 EALOC：Adjusted_EALOC = Σ (API_EALOC × Scenario_Multiplier)

Agent 分配: Agent数量 = ceil(Adjusted_EALOC / 15000)

说明：此处的 "Agent" 为概念性描述，指审计任务拆分后的独立执行单元。实际执行时：

• 小型项目（EALOC < 15000）：单会话完成，无需拆分
• 中型项目（EALOC 15000-50000）：按模块拆分，可用 sessions_spawn 启动子会话并行执行
• 大型项目（EALOC > 50000）：必须拆分，每个子任务独立输出 findings-raw.md，最后合并

1.4 依赖安全检查

执行时机：在 Phase 1 读取 pom.xml/build.gradle 时，同步检查依赖安全。

检查流程（mvnrepository.com 联网核实）

核心理念：不再依赖离线规则表，直接查询 Maven 仓库官方数据，获取准确的漏洞信息。

Step 1: 读取 pom.xml/build.gradle 提取依赖版本
  ↓
Step 2: 构建 mvnrepository.com 查询 URL
  ↓
Step 3: 使用 tavily + web_fetch 查询组件页面
  ↓
Step 4: 检查 "Direct vulnerabilities" 标记
  ↓
Step 5: 找到无漏洞的安全版本

mvnrepository.com 查询方法

URL 格式：

https://mvnrepository.com/artifact/{groupId}/{artifactId}

示例 URL：

https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient
https://mvnrepository.com/artifact/com.alibaba/fastjson
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
https://mvnrepository.com/artifact/org.apache.shiro/shiro-core

页面漏洞标记识别：

• 有漏洞版本：显示 Direct vulnerabilities: CVE-XXXX-XXXXX
• 安全版本：无 Direct vulnerabilities 标记

执行命令

方式一：tavily 搜索定位 + web_fetch 提取

# 1. tavily 搜索组件 mvnrepository 页面
node ~/.openclaw/workspace/skills/tavily-search/scripts/search.mjs "mvnrepository {groupId} {artifactId}" -n 5

# 2. web_fetch 提取页面内容
# 在 OpenClaw 中使用 web_fetch 工具访问组件页面

方式二：直接 web_fetch 组件页面

访问 https://mvnrepository.com/artifact/{groupId}/{artifactId}

在页面内容中搜索：
- "Direct vulnerabilities" → 存在漏洞
- 无此标记 → 安全版本

⚠️ CVE 核实铁律

1. 禁止凭记忆编造 CVE 编号或安全版本 - 必须联网核实
2. 必须使用 mvnrepository.com 官方数据 - 这是最准确的来源
3. 必须检查 "Direct vulnerabilities" 标记 - 不是间接依赖漏洞
4. 必须找到无漏洞的安全版本 - 在版本列表中寻找无标记的最新版本

检查示例：httpclient 4.5.12

Step 1: 访问 https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient

Step 2: 检查版本列表：

• 4.5.12: Direct vulnerabilities: CVE-2020-13956 → ❌ 有漏洞
• 4.5.13: Direct vulnerabilities: CVE-2020-13956 → ❌ 有漏洞
• 4.5.14: 无标记 → ✅ 安全版本

结论: 当前版本 4.5.12 存在漏洞，建议升级到 4.5.14+

高优先级检查组件

以下组件历史上频繁出现高危漏洞，必须逐一检查：

组件	groupId	artifactId	检查 URL
Log4j2	org.apache.logging.log4j	log4j-core	mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
Fastjson	com.alibaba	fastjson	mvnrepository.com/artifact/com.alibaba/fastjson
Shiro	org.apache.shiro	shiro-core	mvnrepository.com/artifact/org.apache.shiro/shiro-core
Jackson	com.fasterxml.jackson.core	jackson-databind	mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind
HttpClient	org.apache.httpcomponents	httpclient	mvnrepository.com/artifact/org.apache.httpcomponents/httpclient
Netty	io.netty	netty-all	mvnrepository.com/artifact/io.netty/netty-all
Hessian	com.caucho	hessian	mvnrepository.com/artifact/com.caucho/hessian
XStream	com.thoughtworks.xstream	xstream	mvnrepository.com/artifact/com.thoughtworks.xstream/xstream
SnakeYAML	org.yaml	snakeyaml	mvnrepository.com/artifact/org.yaml/snakeyaml
Commons Collections	commons-collections	commons-collections	mvnrepository.com/artifact/commons-collections/commons-collections
Commons Text	org.apache.commons	commons-text	mvnrepository.com/artifact/org.apache.commons/commons-text
Nacos	com.alibaba.nacos	nacos-core	mvnrepository.com/artifact/com.alibaba.nacos/nacos-core
Dubbo	org.apache.dubbo	dubbo	mvnrepository.com/artifact/org.apache.dubbo/dubbo

输出模板：dependency-security.md

## 依赖安全检查报告

**检查方法**：通过 mvnrepository.com 联网核实
**检查时间**：YYYY-MM-DD

| 组件 | groupId | artifactId | 当前版本 | Direct vulnerabilities | 安全版本 | 状态 |
|------|---------|------------|----------|------------------------|----------|------|
| httpclient | org.apache.httpcomponents | httpclient | 4.5.12 | CVE-2020-13956 | 4.5.14+ | ❌ 需升级 |
| log4j-core | org.apache.logging.log4j | log4j-core | 2.17.1 | 无 | - | ✅ 安全 |
| fastjson | com.alibaba | fastjson | 1.2.83 | 无 | - | ✅ 安全 |

### 详细检查记录

#### httpclient 4.5.12
- 检查 URL: https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient
- 当前版本状态: Direct vulnerabilities: CVE-2020-13956
- 安全版本: 4.5.14（无 Direct vulnerabilities 标记）
- 建议: 升级到 4.5.14+

#### log4j-core 2.17.1
- 检查 URL: https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
- 当前版本状态: 无 Direct vulnerabilities
- 结论: 安全，无需升级

离线环境处理

无法联网时：

1. 标记为 HYPOTHESIS：无法确认版本安全性
2. 报告备注：注明"离线环境无法确认，建议联网后复查 mvnrepository.com"
3. 保守评估：按"可能存在漏洞"处理，但不作为 CONFIRMED 漏洞

1.5 输出文件

• tier-classification.md: Tier 分类结果
• scenario-tags.json: API 场景标签
• dependency-security.md: 依赖安全检查结果

tier-classification.md 示例

# 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/反序列化）

Linux/macOS (Bash):

# 反序列化全家族（同时检查 Java 和 Kotlin 文件）
grep -rn "ObjectInputStream\|XMLDecoder\|XStream" --include="*.java" --include="*.kt"
grep -rn "JSON\.parseObject\|JSON\.parse\|@type" --include="*.java" --include="*.kt"  # Fastjson
grep -rn "enableDefaultTyping\|activateDefaultTyping" --include="*.java" --include="*.kt"  # Jackson
grep -rn "HessianInput\|Hessian2Input" --include="*.java" --include="*.kt"  # Hessian
grep -rn "Yaml\(\)\.load\|Yaml\(\)\.loadAll\|new Yaml" --include="*.java" --include="*.kt"  # SnakeYAML
grep -rn "Kryo\|Kryo\.readObject\|FSTObjectInput" --include="*.java" --include="*.kt"  # Kryo/FST

# SSTI 全引擎
grep -rn "Velocity\.evaluate\|VelocityEngine\|mergeTemplate" --include="*.java" --include="*.kt"
grep -rn "freemarker\.template\|Template\.process\|FreeMarkerConfigurer" --include="*.java" --include="*.kt"
grep -rn "SpringTemplateEngine\|TemplateEngine\.process" --include="*.java" --include="*.kt"  # Thymeleaf

# 表达式注入
grep -rn "SpelExpressionParser\|parseExpression\|evaluateExpression" --include="*.java" --include="*.kt"
grep -rn "OgnlUtil\|Ognl\.getValue\|ActionContext" --include="*.java" --include="*.kt"

# JNDI 注入
grep -rn "InitialContext\.lookup\|JdbcRowSetImpl\|setDataSourceName" --include="*.java" --include="*.kt"

# 命令执行
grep -rn "Runtime\.getRuntime\|ProcessBuilder\|exec(" --include="*.java" --include="*.kt"

# 脚本引擎代码执行
grep -rn "ScriptEngine\.eval\|ScriptEngineManager\|NashornScriptEngine" --include="*.java" --include="*.kt"

# 动态类加载（配合反射可 RCE）
grep -rn "Class\.forName\|ClassLoader\.loadClass\|URLClassLoader" --include="*.java" --include="*.kt"
grep -rn "getMethod\|invoke\|newInstance" --include="*.java" --include="*.kt"  # 反射调用

Windows (PowerShell):

# 反序列化全家族（同时检查 Java 和 Kotlin 文件）
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "ObjectInputStream|XMLDecoder|XStream"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "JSON\.parseObject|JSON\.parse|@type"  # Fastjson
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "enableDefaultTyping|activateDefaultTyping"  # Jackson
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "HessianInput|Hessian2Input"  # Hessian
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "Yaml\.load|new Yaml"  # SnakeYAML
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "Kryo|FSTObjectInput"  # Kryo/FST

# SSTI 全引擎
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "Velocity\.evaluate|VelocityEngine|mergeTemplate"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "freemarker\.template|Template\.process|FreeMarkerConfigurer"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "SpringTemplateEngine|TemplateEngine\.process"  # Thymeleaf

# 表达式注入
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "SpelExpressionParser|parseExpression|evaluateExpression"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "OgnlUtil|Ognl\.getValue|ActionContext"

# JNDI 注入
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "InitialContext\.lookup|JdbcRowSetImpl|setDataSourceName"

# 命令执行
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "Runtime\.getRuntime|ProcessBuilder|exec\("

# 脚本引擎代码执行
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "ScriptEngine\.eval|ScriptEngineManager|NashornScriptEngine"

# 动态类加载（配合反射可 RCE）
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "Class\.forName|ClassLoader\.loadClass|URLClassLoader"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "getMethod|invoke|newInstance"  # 反射调用

P1 级危险模式（SQL 注入/SSRF/文件操作/XXE/LDAP）

Linux/macOS (Bash):

# SQL 注入风险
grep -rn "Statement\|createStatement\|executeQuery\|executeUpdate" --include="*.java" --include="*.kt"
grep -rn '\$\{' --include="*.xml"  # MyBatis ${} 注入
grep -rn "createQuery\|createNativeQuery" --include="*.java" --include="*.kt"  # JPA/HQL 注入

# SSRF
grep -rn "URL\(|HttpURLConnection\|HttpClient\|RestTemplate\|WebClient" --include="*.java" --include="*.kt"

# 文件操作
grep -rn "FileInputStream\|FileOutputStream\|FileWriter\|Files\.read\|Files\.write" --include="*.java" --include="*.kt"
grep -rn "getOriginalFilename\|transferTo\|MultipartFile" --include="*.java" --include="*.kt"  # 文件上传
grep -rn "\.\./\|getAbsolutePath" --include="*.java" --include="*.kt"  # 路径穿越

# XXE（XML 外部实体）
grep -rn "DocumentBuilder\|SAXParser\|XMLReader\|SAXReader" --include="*.java" --include="*.kt"
grep -rn "setFeature.*external.*false\|setExpandEntityReferences.*false" --include="*.java" --include="*.kt"  # XXE 防护检查

# LDAP 注入
grep -rn "SearchControls\|DirContext\.search\|ldapsearch" --include="*.java" --include="*.kt"

# 开放重定向
grep -rn "sendRedirect\|Response\.sendRedirect" --include="*.java" --include="*.kt"

# 日志注入
grep -rn "log\.info\|log\.debug\|log\.error" --include="*.java" --include="*.kt" | grep -i "request\|param\|input"  # 日志记录用户输入

Windows (PowerShell):

# SQL 注入风险
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "Statement|createStatement|executeQuery|executeUpdate"
Get-ChildItem -Recurse -Include *.xml | Select-String -Pattern '\$\{'  # MyBatis ${} 注入
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "createQuery|createNativeQuery"  # JPA/HQL 注入

# SSRF
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "URL\(|HttpURLConnection|HttpClient|RestTemplate|WebClient"

# 文件操作
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "FileInputStream|FileOutputStream|FileWriter|Files\.read|Files\.write"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "getOriginalFilename|transferTo|MultipartFile"  # 文件上传
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "\.\./|getAbsolutePath"  # 路径穿越

# XXE（XML 外部实体）
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "DocumentBuilder|SAXParser|XMLReader|SAXReader"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "setFeature.*external|setExpandEntityReferences"  # XXE 防护检查

# LDAP 注入
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "SearchControls|DirContext\.search|ldapsearch"

# 开放重定向
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "sendRedirect|Response\.sendRedirect"

# 日志注入
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "log\.info|log\.debug|log\.error"

P2 级危险模式（认证/授权/加密/敏感信息）

Linux/macOS (Bash):

# 认证相关
grep -rn "@PreAuthorize\|@Secured\|@RolesAllowed\|hasRole\|hasAuthority" --include="*.java" --include="*.kt"
grep -rn "permitAll\|anonymous\|authenticated" --include="*.java" --include="*.kt"

# 加密相关
grep -rn "MessageDigest\|Cipher\|SecretKey\|PasswordEncoder" --include="*.java" --include="*.kt"
grep -rn "MD5\|SHA1\|DES\|AES/ECB" --include="*.java" --include="*.kt"  # 弱加密算法

# 不安全随机数
grep -rn "new Random\(\)\|Math\.random\(\)" --include="*.java" --include="*.kt"

# 硬编码敏感信息
grep -rn "password\s*=\s*\"\|secret\s*=\s*\"\|apiKey\s*=\s*\"" --include="*.java" --include="*.kt"
grep -rn "jdbc:mysql://\|jdbc:oracle:" --include="*.java" --include="*.kt"  # 数据库连接字符串

# @InitBinder 配置检查
grep -rn "@InitBinder\|setDisallowedFields" --include="*.java" --include="*.kt"  # Spring 参数绑定配置

Windows (PowerShell):

# 认证相关
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "@PreAuthorize|@Secured|@RolesAllowed|hasRole|hasAuthority"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "permitAll|anonymous|authenticated"

# 加密相关
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "MessageDigest|Cipher|SecretKey|PasswordEncoder"
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "MD5|SHA1|DES|AES/ECB"  # 弱加密算法

# 不安全随机数
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "new Random\(\)|Math\.random\(\)"

# 硬编码敏感信息
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "password\s*=\s*\"|secret\s*=\s*\"|apiKey\s*=\s*\""
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "jdbc:mysql://|jdbc:oracle:"  # 数据库连接字符串

# @InitBinder 配置检查
Get-ChildItem -Recurse -Include *.java,*.kt | Select-String -Pattern "@InitBinder|setDisallowedFields"  # Spring 参数绑定配置

⚠️ @InitBinder 分析指南（重要）

当发现 @InitBinder 或 setDisallowedFields 时，必须按以下步骤验证：

Step 1：验证类继承关系

# 检查 Controller 是否继承了父类
Select-String -Path $controllerFile -Pattern "class.*Controller.*extends|class.*Controller\s*\{"

情况	结论
继承父类 + 有自己的 @InitBinder	可能是"覆盖"
未继承父类 + 有自己的 @InitBinder	不是"覆盖"，是"新增配置"

Step 2：验证参数绑定方式

# 检查接口参数注解
Select-String -Path $controllerFile -Pattern "@RequestBody|@ModelAttribute|@RequestParam|public.*\("

参数注解	受 @InitBinder 影响	分析重点
@RequestBody	❌ 否（JSON 反序列化）	检查 DTO 字段
@ModelAttribute	✅ 是	高风险，需详细分析
无注解（对象参数）	✅ 是	高风险，需详细分析
@RequestParam	⚠️ 部分（单个字段）	低风险

Step 3：验证业务场景

# 检查是否涉及用户管理
Select-String -Path $files -Pattern "UserService|UserRepository|isAdmin|role|permission"

Step 4：验证 DTO 字段

# 读取 DTO 类定义，检查字段
Get-Content $dtoFile

正确结论格式：

在 XxxController 中存在危险的 @InitBinder 配置：`binder.setDisallowedFields(new String[]{})`。
当前该控制器有 X 个接口，其中 Y 个使用表单参数绑定（受影响），Z 个使用 @RequestBody（不受影响）。
受影响的接口 DTO 只含 [字段列表]，无敏感字段。
若后续新增参数绑定接口，可能存在批量分配风险。

错误案例（2026-04-01）：

错误：报告"批量分配防护被覆盖"，但 Controller 未继承父类，且全部使用 @RequestBody。 教训：未验证继承关系、参数绑定方式、业务场景、攻击路径。

Layer 2: 双轨审计模型

每个 Agent 执行两条并行的审计轨道：

轨道 1: Sink-driven（从危险代码往上追）

发现 Runtime.exec(cmd) → 追踪 cmd 参数来源 → 检查是否有过滤 → 判断是否来自用户输入

轨道 2: Control-driven（从端点往下查安全控制）

发现 /api/admin/deleteUser 端点 → 检查是否有认证注解 → 检查是否有权限校验

为什么需要两条轨道？ 认证绕过这类漏洞，单独用 Sink-driven 找不到——该漏洞不是某行代码有问题，而是某个端点缺少了应有的权限检查。

Layer 2 执行流程

Step 1: 执行轨道 1 (Sink-driven)
  ↓ 对 L1 发现的危险 Sink 追踪参数来源
  ↓ 判断是否用户可控
  ↓ 输出普通漏洞候选列表

Step 2: 执行轨道 2 (Control-driven)
  ↓ 列出所有 Controller 入口
  ↓ 检查权限控制
  ↓ 输出越权/认证绕过候选列表

Step 3: 执行 Layer 2.5（仅对逻辑漏洞）
  ↓ 对资金交易、状态变更等敏感接口
  ↓ 执行 CoT 四步推理
  ↓ 输出逻辑漏洞候选列表

Layer 2.5: 逻辑漏洞 CoT 四步推理

执行时机：当发现以下场景时，必须执行 Layer 2.5：

场景	触发条件	示例
资金交易	涉及支付、退款、转账	pay(), refund(), transfer()
状态变更	涉及订单状态、审批流程	updateStatus(), approve()
资源分配	涉及库存、名额	createOrder(), book()
数据访问	涉及敏感数据查询	getUserInfo(), getOrderDetail()

⚠️ Layer 2.5 触发条件检查清单：

在执行 Layer 2 之前，必须先检查是否需要触发 Layer 2.5：

□ API 路径包含 pay/payment/refund/transfer/withdraw？
□ 方法名包含 updateStatus/approve/reject/confirm/cancel？
□ 涉及金额、价格、库存、数量字段？
□ 涉及状态机流转（订单状态、审批状态）？
□ 涉及用户间数据隔离（水平越权风险）？
□ 涉及特权操作（管理员功能、系统配置）？

→ 任一为是 → 必须执行 Layer 2.5
→ 全部为否 → 可跳过 Layer 2.5

注意：Layer 2.5 专门用于逻辑漏洞分析，普通漏洞（SQL注入、命令注入等）用 Layer 2 双轨审计即可。

对于 Semgrep 规则无法覆盖的漏洞类型，需要通过代码分析进行判断。

逻辑漏洞 CoT 四步推理

核心理念：逻辑漏洞的本质是"合法的代码执行了非预期的业务流程"，需要强制 AI 像安全专家一样进行攻防推演。

Step 1: 场景与入口识别 → 识别 API 功能场景，分析用户可控参数
Step 2: 防御机制审计 → 寻找代码中的"锁"和"盾"，分析完备性
Step 3: 对抗性沙箱模拟 → AI 设计 PoC，模拟真实链路处理
Step 4: 漏洞结果判定 → 基于推演给出负责任结论

Step 1: 场景与入口识别

识别内容：
1. API 功能场景（资金交易/数据访问/状态变更等）
2. 用户可控参数列表
3. 参数风险标签：
   - ID 类（userId, orderId）→ 数据定位，可能越权
   - 金额类（amount, price）→ 资金相关，可能篡改
   - 状态类（status, state）→ 状态控制，可能绕过状态机
   - 数量类（count, quantity）→ 资源相关，可能并发问题

Step 2: 防御机制审计

寻找代码中的"锁"和"盾"：

锁类型	代码特征	检查点
权限锁	@PreAuthorize, hasRole()	是否存在？是否完整？
归属锁	userId.equals(currentUser.getId())	数据是否校验归属？
状态锁	if (order.getStatus() == PAID)	状态前置条件是否完整？
金额锁	amount.equals(order.getAmount())	金额是否后端校验？
并发锁	synchronized, SELECT FOR UPDATE	是否有并发控制？

Step 3: 对抗性沙箱模拟

基于业务语义生成对抗性测试用例：

参数类型	测试值	目标漏洞
金额	负数、0、极大值	0元支付、负金额退款
数量	负数、超库存上限	库存为负、超量下单
状态	跳跃状态值	状态机绕过
ID	他人 ID	水平越权

Step 4: 漏洞结果判定

• CONFIRMED: PoC 可执行，调用链完整，影响明确
• HYPOTHESIS: 发现可疑模式但无法完全确认，需人工验证

详细推理模板: references/logic-vulnerability-cot.md

业务逻辑漏洞检查要点

支付金额检查：
1. 金额是否来自前端？是否有后端校验？
2. 价格是否可被篡改？
3. 是否有金额一致性校验？

库存并发检查：
1. 是否有并发控制（锁/原子操作）？
2. 检查和扣减是否原子操作？

状态机检查：
1. 状态流转规则是否明确？
2. 敏感操作是否校验前置状态？
3. 是否有非法状态跳转？

越权漏洞检查要点

水平越权检查：
1. 数据查询是否校验归属？
2. userId 是否从 Session 获取（不可伪造）？
3. UPDATE/DELETE 是否有 userId 条件？

垂直越权检查：
1. 管理接口是否有权限注解？
2. 前后端权限是否一致？
3. 是否有权限配置遗漏？

依赖安全检查

⚠️ 必须通过 mvnrepository.com 联网核实，不再使用离线规则表。

检查流程：
1. 读取 pom.xml/build.gradle 提取依赖版本
2. 构建 mvnrepository.com 查询 URL
3. 使用 tavily + web_fetch 查询组件页面
4. 检查当前版本的 "Direct vulnerabilities" 标记
5. 找到无漏洞的安全版本

mvnrepository.com 查询方法：

URL 格式: https://mvnrepository.com/artifact/{groupId}/{artifactId}

示例:
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
https://mvnrepository.com/artifact/com.alibaba/fastjson
https://mvnrepository.com/artifact/org.apache.shiro/shiro-core

漏洞标记识别：

• 有漏洞版本：页面显示 Direct vulnerabilities: CVE-XXXX-XXXXX
• 安全版本：无 Direct vulnerabilities 标记

执行命令：

# 方式一：tavily 搜索定位
node ~/.openclaw/workspace/skills/tavily-search/scripts/search.mjs "mvnrepository {groupId} {artifactId}" -n 5

# 方式二：直接 web_fetch 组件页面
# 使用 OpenClaw 的 web_fetch 工具访问 mvnrepository.com 页面

检查示例：

发现依赖: httpclient 4.5.12

Step 1: 访问 mvnrepository.com/artifact/org.apache.httpcomponents/httpclient

Step 2: 检查版本列表:
  - 4.5.12: Direct vulnerabilities: CVE-2020-13956 → ❌ 有漏洞
  - 4.5.14: 无标记 → ✅ 安全版本

结论: 需要升级到 4.5.14+

⚠️ 核实铁律：

1. 禁止凭记忆编造安全版本 - 必须在 mvnrepository.com 上核实
2. 必须检查 "Direct vulnerabilities" - 这是直接依赖漏洞，非间接依赖
3. 必须找到无标记的安全版本 - 在版本列表中寻找无漏洞标记的最新版本

运行时配置

检查要点：
1. Session 超时、Cookie Secure/HttpOnly
2. Actuator 端点暴露
3. 数据库密码明文存储
4. 调试模式开启

详细判断方法见: references/vulnerability-conditions.md 第 16-19 节

Layer 3: 调用链语义级验证

优先使用 LSP 做语义级追踪：

候选 Sink (Statement.executeUpdate(sql))
↓ goToDefinition → 确认实际实现
↓ findReferences → 向上追踪所有调用者
↓ hover → 获取中间变量类型
↓ 重复 findReferences → 直到到达 Controller 入口或确认不可达
↓ 记录完整调用链，每一跳标注 文件:行号

LSP 不可用时退化到 Grep + Read 手动追踪。

---

Phase 2.5: 覆盖率门禁

这是反 LLM 天性的核心设计——LLM 倾向于跳过"看起来不重要"的代码，而漏洞恰恰喜欢藏在那些地方。

自动化覆盖率检查

使用 scripts/java_audit.py 自动检查覆盖率：

# Python 脚本（跨平台）
python scripts/java_audit.py /path/to/project --coverage --reviewed-file findings-raw.md

# 输出示例：
# [*] 覆盖率统计:
#   实际文件总数: 847
#   已审阅文件数: 820
#   遗漏文件数: 27
#   覆盖率: 96.8%
#
# [!] 门禁未通过 - 覆盖率 < 100%，需要补扫

门禁阈值

⚠️ 核心原则：T1 文件（Controller/Filter）必须 100% 覆盖，无例外。

项目规模	EALOC	T1 覆盖率	T2 覆盖率	T3 覆盖率	总体覆盖率
小型项目	< 15,000	100%	95%	90%	100%
中型项目	15,000 - 50,000	100%	95%	85%	95%
大型项目	> 50,000	100%	90%	80%	90%

门禁判断逻辑：

门禁通过条件（必须全部满足）：
1. T1 覆盖率 == 100%（硬性要求，无例外）
2. T2 覆盖率 >= 阈值（中型 95%，大型 90%）
3. T3 覆盖率 >= 阈值（中型 85%，大型 80%）
4. 总体覆盖率 >= 阈值（小型 100%，中型 95%，大型 90%）

说明：

• T1（Controller/Filter）：入口点文件，安全风险最高，必须全部审计
• T2（Service/DAO）：业务逻辑层，覆盖率要求较高
• T3（Entity/VO）：数据模型层，覆盖率要求相对较低

模块覆盖矩阵

| # | 模块路径 | 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 输出必须包含审阅文件清单：

| # | 文件路径 | 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. 覆盖率达到阈值 → 该 Agent 通过
   覆盖率未达标 → 立即为未覆盖文件启动补扫 Agent

所有 Agent 完成后：
- 全部模块 Phase2 = 完成 → 进入 Phase 3
- 存在 未开始 或 部分完成 → 启动补充 Agent → 循环直到达标

覆盖率不达标处理流程

┌─────────────────────────────────────────────────────────────────┐
│                覆盖率门禁回溯机制                                 │
└─────────────────────────────────────────────────────────────────┘

  Phase 2.5: 检查覆盖率
  ┌─────────────────────────────────────┐
  │ 计算覆盖率 = 已审阅文件 / 总文件数  │
  └─────────────────────────────────────┘
              ↓
        ┌─────┴─────┐
        │ 覆盖率达标？│
        └─────┬─────┘
         是 ↓     ↓ 否
  ┌──────────┐  ┌──────────────────────┐
  │进入      │  │ 1. 列出遗漏文件列表  │
  │Phase 3   │  │ 2. 返回 Phase 2      │
  └──────────┘  │ 3. 补扫遗漏文件      │
                │ 4. 更新审阅清单      │
                │ 5. 再次检查覆盖率    │
                └──────────┬───────────┘
                           ↓
                     ┌─────┴─────┐
                     │ 达标？    │
                     └─────┬─────┘
                      是 ↓     ↓ 否
                ┌──────────┐  ┌──────────┐
                │Phase 3   │  │ 循环补扫 │
                └──────────┘  └──────────┘

补扫命令：

# 1. 获取遗漏文件列表
# 对比实际文件列表和已审阅清单
$allFiles = Get-ChildItem -Recurse -Filter *.java | Select-Object -ExpandProperty Name
$reviewedFiles = Get-Content findings-raw.md | Select-String -Pattern "\.java" 
$missingFiles = Compare-Object $allFiles $reviewedFiles

# 2. 对遗漏文件执行审计
foreach ($file in $missingFiles) {
    Read $file
    # 执行 Layer 2 分析
}

# 3. 更新 findings-raw.md
# 4. 重新计算覆盖率

阈值说明：见上门禁阈值表，按项目规模分级执行。T1 文件必须 100% 覆盖。

质量校验自动化

每个阶段输出后，自动运行质量校验脚本检查输出质量。

校验脚本

# Linux/macOS
./scripts/quality-checker.sh <phase> <project_path>

# Windows PowerShell
.\scripts\quality-checker.ps1 -Phase <phase> -ProjectPath <project_path>

# 全量校验
./scripts/quality-checker.sh all /path/to/project

校验阶段与检查项

阶段	校验项	不通过条件
phase1	EALOC 计算	缺失
phase1	Tier 分类	缺失或 T1=0
phase2-layer1	危险模式文件	p0/p1/p2 全缺失
phase2-layer2	精确行号	无 文件:行号 格式
phase2-layer2	调用链分析	0 个调用链
phase25	覆盖率	总体 < 90%
phase25	T1 覆盖率	< 100%
phase3	CONFIRMED/HYPOTHESIS	无状态标记
phase3	DKTSS 评分	缺失
phase5	报告结构	缺少漏洞列表/审计进度
phase5	完整路径	代码位置非绝对路径
phase5	标题格式	包含严重程度标签

自动化流程

Phase 1 执行完成
  ↓ 自动运行
  quality-checker.sh phase1 /project/path
  ↓
  通过 → 继续执行 Phase 2
  不通过 → 返回 Phase 1 补充
  
Phase 2 Layer 1 执行完成
  ↓ 自动运行
  quality-checker.sh phase2-layer1 /project/path
  ↓
  通过 → 继续执行 Layer 2
  不通过 → 检查扫描命令
  
...以此类推...

校验示例

# Phase 5 报告校验
$ ./scripts/quality-checker.sh phase5 /path/to/project

[*] Phase 5 质量校验...
[✓] 「漏洞列表」部分存在
[✓] 「审计进度」部分存在
[✓] 代码位置格式正确（完整绝对路径）
[✓] 标题格式正确（无严重程度标签）
[✓] 调用链分析完整
[✓] 修复建议存在
[*] Phase 5 校验完成: 0 错误, 0 警告

---

Phase 3: 漏洞验证 & DKTSS 评分

⚠️ Phase 3 与 Layer 3 的区别

名称	所属阶段	作用
Layer 3	Phase 2 内部	调用链语义验证，用 Read 验证每一跳
Phase 3	独立阶段	最终漏洞确认、反幻觉检查、DKTSS 评分

Phase 2 内部:
  Layer 1 → Layer 2 → Layer 3（调用链验证）
                ↓
         输出 findings-raw.md

Phase 3:
  读取 findings-raw.md
    → 反幻觉铁律检查
    → CVE 联网核实
    → DKTSS 评分
    → 状态标记
                ↓
         输出 findings-verified.md

反幻觉 7 条铁律

1. 报告漏洞前必须用 Read 验证文件存在
2. 代码片段必须来自实际 Read 输出，不得编造
3. 调用链每一跳必须标注 文件:行号
4. 不确定的发现标记为 HYPOTHESIS，不得标记为 CONFIRMED
5. 宁可漏报，不可误报
6. CVE 编号必须联网核实，禁止凭记忆编造
7. 行号必须用 Read 验证，禁止模糊范围或猜测

CVE 核实铁律详解

❌ 错误做法：
  报告 CVE-2020-1948 为 Hessian 漏洞
  实际情况：CVE-2020-1948 是 Apache Dubbo 漏洞，与 Hessian 库无关

✅ 正确做法：
  1. 使用 tavily 搜索 "<组件名> <版本号> CVE"
  2. 从 NVD/Snyk 官方数据确认 CVE 真实性
  3. 确认影响版本范围
  4. 确认 CVE 影响的具体组件（artifact）

行号验证铁律详解

❌ 错误做法：
  grep 搜索后直接使用 grep 输出的行号
  报告模糊范围：HeaderModelUtils.java:18-35

✅ 正确做法：
  1. grep 搜索定位关键代码
  2. 使用 Read 工具读取文件，验证实际行号
  3. 精确标注：HeaderModelUtils.java:35
  4. 多段代码分开标注：HttpUtil.java:252-253, 321

行号验证示例：
  # grep 搜索
  Select-String -Path $file -Pattern "getLoginUserByStr" | ForEach-Object { "Line $($_.LineNumber)" }
  
  # Read 验证（必须执行）
  Read 文件，确认 grep 输出的行号与实际内容匹配

分析深度铁律

漏洞分析必须达到 L3 级别，禁止写成三点式（成因+攻击+影响），禁止片面分析。

必须包含以下所有要素：

• ✅ 具体方法名：精确到 ClassName.methodName()
• ✅ 具体行为：方法具体做了什么
• ✅ 缺少的安全控制：什么保护措施没有（列表形式）
• ✅ 攻击路径：攻击者可以如何利用（步骤形式）
• ✅ 调用链追踪：从入口到漏洞点的完整路径
• ✅ 漏洞类型归纳：标准漏洞分类（CWE）
• ✅ 未使用的安全机制：项目中存在但未启用的安全配置

禁止片面分析：

❌ 片面分析（不可接受）：
`CommonController.uploadFile()` 方法接收用户上传的文件，没有对文件类型进行校验，
攻击者可以上传恶意文件。

问题：
- 没有说明具体哪个方法有问题
- 没有调用链追踪
- 没有说明缺少哪些具体的安全控制
- 没有对比分析
- 没有攻击路径说明

✅ 全面分析（符合要求）：
`CommonController.uploadFile()` 方法（CommonController.java:49）接收 MultipartFile 参数，
直接调用 `FileUtil.saveFile()` 保存到服务器。

**调用链追踪**：
Controller → Service → FileUtil

**缺少的安全控制**：
1. 文件类型校验：未检查 Content-Type 和文件扩展名
2. 文件内容校验：未检查文件魔数/文件头
3. 文件名处理：使用原始文件名，未重命名

**攻击路径**：
1. 攻击者构造恶意 JSP WebShell
2. 修改 Content-Type 为 image/jpeg 绕过前端校验
3. 上传到服务器可访问目录
4. 访问上传的文件执行任意命令

**归纳漏洞类型**：任意文件上传（CWE-434）

样例（必须参照此格式）：

`HeaderModelUtils.getLoginUserByStr()` 方法仅对 Header 中的 Base64 编码数据进行解码，
然后直接反序列化为 LoginUserBo 对象。系统没有对用户信息进行任何签名验证或加密保护，
攻击者可以轻松伪造任意用户的登录信息。

控制器层（如 `FlightController.setFlightCityHistory()`）直接从请求头 `la517_loginUser`
获取用户信息，该信息未经服务器端验证就传递给服务层使用，形成**客户端信任漏洞**。

经审查 `pom.xml` 发现项目已引入 JWT 相关依赖（`jjwt`），但全局搜索显示实际并未使用。
`LogInterceptor` 拦截器仅用于日志追踪（requestId 生成），不包含任何认证逻辑。

漏洞成立条件判断

详见 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

核心公式：Score = Base - Friction + Weapon + Ver

• Base: 按漏洞类型和实际影响评分
• Friction: 实战阻力（访问路径/权限门槛/交互复杂度）
• Weapon: 武器化程度
• Ver: 版本因子

状态定义

状态	定义	要求
CONFIRMED	已验证可利用	PoC 可执行，调用链完整，影响明确
HYPOTHESIS	疑似漏洞，需人工验证	发现可疑模式但无法完全确认

关键原则: 宁可标记为 HYPOTHESIS 让人工验证，也不要把不确定的发现标记为 CONFIRMED 污染报告可信度。

---

Phase 4: Semgrep 规则沉淀（可选）

目标：将确认的漏洞模式转换为 Semgrep 静态分析规则，可集成到 CI/CD 流水线。

Semgrep 安装

详见 rules/semgrep/README.md

# macOS
brew install semgrep

# Linux
pip install semgrep

# Windows (通过 pip)
pip install semgrep

# 验证安装
semgrep --version

快速扫描：

# 扫描所有规则（含新增的新兴技术安全规则）
semgrep --config rules/semgrep/ /path/to/project

# 仅扫描 P0 级规则
semgrep --config rules/semgrep/java-rce.yaml /path/to/project
semgrep --config rules/semgrep/java-emerging.yaml /path/to/project

# 输出 JSON 格式
semgrep --config rules/semgrep/ --json /path/to/project > semgrep-results.json

规则列表：见 rules/semgrep/README.md，共 314 条规则覆盖：

• 传统漏洞：RCE、SQL注入、SSRF、文件操作、加密安全
• 新兴技术：LLM/AI 安全、GraphQL、Kotlin 特有漏洞、Java 21 新特性
• 微服务安全：Feign、Gateway、Dubbo、gRPC、NoSQL 注入
• 组件配置：Log4j2、Spring Security、Shiro、Fastjson、JWT 等
• 业务安全：并发安全、输入验证、敏感数据处理

执行条件

Phase 4 为可选步骤，在以下情况下执行：

• 发现了新的漏洞模式，现有 Semgrep 规则未覆盖
• 需要将漏洞检测集成到 CI/CD 流水线
• 项目需要长期的自动化安全检测

输出文件

文件	说明
custom-rules.yaml	自定义 Semgrep 规则文件
semgrep-results.json	规则测试结果

规则编写规范

rules:
  - id: custom-vulnerability-id
    patterns:
      - pattern: 危险模式
      - pattern-not: 安全模式（排除误报）
    message: 规则描述，说明漏洞风险和修复建议
    severity: ERROR  # ERROR / WARNING / INFO
    languages: [java]
    metadata:
      category: security
      cwe: "CWE-XXX"
      references:
        - https://example.com/reference

示例规则

rules:
  - id: velocity-ssti
    patterns:
      - pattern: Velocity.evaluate($CONTEXT, $WRITER, $NAME, $USER_INPUT)
      - pattern-not: Velocity.evaluate($CONTEXT, $WRITER, $NAME, "...")
    message: 检测到用户可控的 Velocity 模板输入，存在 SSTI 风险
    severity: ERROR
    languages: [java]
    metadata:
      category: security
      cwe: "CWE-94"

规则测试

# 测试单个规则
semgrep --config custom-rules.yaml /path/to/test/code

# 验证规则语法
semgrep --validate --config custom-rules.yaml

跳过条件

以下情况可跳过 Phase 4：

• 所有发现的漏洞都已被现有 Semgrep 规则覆盖
• 不需要 CI/CD 集成
• 时间紧迫，优先完成报告

---

Phase 5: 标准化报告生成

⚠️ 必须先阅读模板

在生成报告之前，必须完整阅读 references/report-template.md。

报告格式以 report-template.md 为准，SKILL.md 不再重复定义格式细节。

报告整体结构

报告包含以下部分：

1. 漏洞列表：包含漏洞的名字
2. 审计进度：包含 L1-L3 审计的进度
3. 详细漏洞报告：每个漏洞包含三部分
   • 描述：漏洞归纳描述，100字左右
   • 漏洞详情：代码位置、问题代码展示、漏洞分析（300字以上）
   • 修复建议：完整的解决方案

报告格式规范

内容	标签	说明
漏洞名称	h1 (#)	单独一个大名称
描述	h3 (###)	漏洞归纳描述，100字左右
漏洞详情	h3 (###)	包含代码位置、代码展示、漏洞分析
修复建议	h3 (###)	完整解决方案

⚠️ 报告格式铁律

1. 代码位置必须使用完整绝对路径

❌ 错误：
**代码位置**：
CommonController.java:49-62

✅ 正确：
**代码位置**：
E:\工作代码\xx\xx\src\main\java\com\example\controller\CommonController.java:49-62

2. 漏洞分析必须详细完整（300字以上）

漏洞分析部分必须包含：

要素	说明
1. 调用链追踪	从入口到漏洞点的完整路径，每一跳标注 文件:行号
2. 缺少的安全控制	表格形式列出
3. 攻击路径	步骤形式（1、2、3...）
4. 对比分析	与安全代码的差异
5. 未使用的安全机制	项目中存在但未启用
6. 漏洞类型归纳	CWE 标准分类

详细示例见 report-template.md。

3. 禁止在标题中添加严重程度标签

❌ 错误：
# 任意文件上传漏洞（Critical）

✅ 正确：
# 任意文件上传漏洞

反幻觉铁律（再次强调）

1. 报告漏洞前必须用 Read 验证文件存在
2. 代码片段必须来自实际 Read 输出，不得编造
3. 调用链每一跳必须标注 文件:行号
4. 不确定的发现标记为 HYPOTHESIS，不得标记为 CONFIRMED
5. 分析深度必须达到 L3 级别（见 report-template.md）

行号定位规范

• 必须使用实际验证的行号，禁止模糊范围
• 精确到方法起始行，多段代码分开标注
• 示例：HttpUtil.java:252-253, 321 而非 HttpUtil.java:177-193

报告输出文件

• findings-raw.md: Phase 2 发现的候选漏洞
• findings-verified.md: Phase 3 验证后的确认漏洞（最终数据源）
• audit-report.md: Phase 5 格式化的最终报告

---

AI 代码审计 6 大核心方法

1. 语义化规则匹配

传统工具的规则是"死"的——只能匹配固定参数名。AI 通过语义识别核心业务含义，适配任意命名规范。

示例：越权漏洞检测

• 传统规则：检查是否存在 user_id 参数
• AI 语义规则：识别接口中所有代表用户身份标识的参数，校验该参数用于定位业务数据归属时，是否与当前登录用户的身份存在强制绑定

适用场景：未授权访问、通用越权、验证码绕过、密码重置漏洞

2. 基于因果推理的业务流程异常审计

AI 先构建业务的因果关系基准与状态机模型，明确每个业务操作的强制前置条件（因）与合法后置状态（果），再通过反事实推理验证。

示例：电商支付场景

• 强制前置条件：订单已创建且未支付、支付金额一致、回调凭证合法
• 合法后置状态：订单变为待发货、库存扣减、生成发货单
• 测试用例：跳过支付直接调用发货确认接口

适用场景：流程绕过、步骤颠倒、非法状态跳转

3. 权限与访问控制的逻辑一致性审计

构建完整的权限-资源绑定模型，执行三类校验：

校验类型	方法	覆盖漏洞
水平越权校验	用同角色不同用户凭证测试	访问他人私有数据
垂直越权校验	用低权限凭证测试高权限接口	权限提升
一致性校验	对比同类接口权限校验逻辑	部分遗漏校验

适用场景：水平/垂直越权、未授权访问、前后端权限不一致

4. 边界条件与异常分支的对抗性生成审计

基于参数的业务语义生成对抗性测试用例，而非随机字符串：

参数类型	测试值	目标漏洞
金额	负数、0、极大值、超2位小数	0元支付、负金额退款
数量	负数、超库存上限	库存为负、超量下单
时间	超期时间、早于当前时间	绕过有效期限制

白盒扫描重点：异常捕获分支是否存在"跳过权限校验"、"异常时返回成功"、"泄露敏感信息"

5. 多维度关联的漏洞链推理

将单个缺陷按业务场景、接口依赖、数据流转关系关联，自动识别可串联的漏洞点。

示例漏洞链：

1. /api/user/list 未授权访问 → 获取全量用户手机号和 user_id
2. /api/user/password/reset 仅校验手机号和 user_id，无验证码

→ 串联形成完整攻击链，实现任意用户密码重置

6. 白盒场景的代码语义级逻辑缺陷审计

重点扫描高频逻辑缺陷场景：

• 权限校验缺失（仅校验登录，未校验数据归属）
• 业务逻辑错误（金额计算顺序、库存扣减顺序）
• 异常处理缺陷（捕获异常后直接返回成功）
• 接口设计缺陷（无幂等性、敏感操作无二次校验）

---

长上下文问题 5 层解决方案

层级 1: 源头治理（性价比最高，降低 60%+ 上下文）

必过滤内容：

• 注释、空行、纯日志打印代码
• 单元测试文件
• 第三方依赖库
• 构建配置文件
• 自动生成代码（protobuf、MyBatis Mapper）

可过滤低风险内容：

• 仅含 get/set 的纯数据实体类
• 无安全风险的工具方法
• 非核心统计报表代码

注意：过滤必须基于语义识别，不能误删权限校验、加密解密、输入过滤等核心安全代码。

层级 2: 三层递进式审计架构（核心方案）

层级	内容	Token 控制
第一层：全局架构层	项目架构说明、模块划分、全局权限模型、核心拦截器规则、对外接口清单	≤ 8K
第二层：模块级审计	按业务域拆分独立审计单元，输入模块代码+全局安全基线+依赖接口元数据	32K-64K
第三层：跨模块验证	仅输入关联模块核心代码片段+调用链路元数据	≤ 64K

层级 3: 结构化语义压缩（降低 70%+ Token）

将代码转化为结构化元数据：

函数名：updateOrder
输入参数：orderId（用户可控字符串）、orderStatus（整型枚举）
核心业务逻辑：根据 orderId 修改订单状态
安全特征：无订单归属用户校验，无操作权限校验
下游依赖：orderDao.update
风险标签：越权风险高

层级 4: RAG + 多轮对话（突破窗口物理限制）

1. 构建代码知识库：按函数/类拆分，生成向量嵌入存入向量库
2. 精准检索相关上下文：通过自然语言或风险特征检索相关代码片段
3. 多轮对话增量审计：每轮处理一个细分目标，上一轮输出作为下一轮轻量上下文

层级 5: 增量审计机制（工程化落地）

与 Git/CI/CD 集成，仅审计本次提交变更的代码及相关调用链路，减少 90%+ 上下文量。

---

5 大落地误区

❌ 误区 1：简单按行数拆分代码

问题：破坏代码语义关联，导致跨文件调用链路无法理解，严重漏报

正确做法：按业务边界、依赖关系拆分，采用三层递进式架构

❌ 误区 2：过度依赖长窗口模型

问题：超过 128K token 后注意力严重衰减，且成本极高

正确做法：中等窗口 + 裁剪分块 + RAG，长窗口仅作跨模块验证辅助

❌ 误区 3：全量代码丢给 AI

问题：上下文溢出、无关信息干扰、误报率飙升、速度极慢

正确做法：完成无效信息过滤与风险分级，遵循"非必要不输入"

❌ 误区 4：完全抛弃传统工具

问题：大模型存在幻觉问题，无法被规则匹配弥补

正确做法：传统工具前置过滤 + AI 深度推理 + 传统工具后置验证

❌ 误区 5：只关注已知漏洞

问题：浪费 AI 核心能力——检测业务逻辑漏洞

正确做法：聚焦传统工具无法覆盖的逻辑缺陷、越权漏洞、流程绕过

---

参考文档

文档	内容
vulnerability-conditions.md	漏洞成立条件判断表（Fastjson、JNDI、SSTI 等）
dktss-scoring.md	DKTSS 评分体系详细说明
cve-offline-lookup.md	常见 CVE 离线速查表（Log4j、Fastjson、Spring、Shiro 等）
report-template.md	标准化漏洞报告模板
logic-vulnerability-cot.md	逻辑漏洞 CoT 四步推理流程
business-scenario-tags.md	业务场景标签系统
security-checklist.md	Java Web 应用安全审计检查清单

Semgrep 规则文件

文件	覆盖内容	规则数
java-rce.yaml	反序列化、SSTI、表达式注入、命令注入	21
java-sqli.yaml	SQL 注入、MyBatis ${} 注入	12
java-ssrf.yaml	SSRF 漏洞	8
java-file.yaml	文件操作漏洞	14
java-crypto.yaml	加密算法安全	8
java-misc.yaml	XXE、XSS、认证授权等	56
java-config.yaml	组件配置安全（60+ 组件）	95
java-emerging.yaml	LLM/AI、GraphQL、Kotlin、Java 21、并发安全	14

总计 314 条规则

示例项目

目录	说明
examples/vulnerable-springboot/	完整审计报告示例（含 4 个漏洞详细分析）

---

执行检查清单

审计开始前

• 确认项目路径和技术栈（Java/Kotlin 版本、框架）
• 运行 Phase 0 度量脚本
• 完成项目侦察，生成 Tier 分类和 EALOC 计算
• 生成业务场景标签（scenario-tags.json）

审计过程中

• Layer 1 预扫描完成，P0-P3 标记到位
• 每个 Agent 双轨审计（Sink-driven + Control-driven）
• 逻辑漏洞执行 CoT 四步推理
• 实时更新覆盖矩阵
• 文件级覆盖率验证（清单 vs 实际文件 diff）

审计完成后

• 覆盖率门禁达标（小型 100% / 中型 95% / 大型 90%）
• 每个漏洞遵循反幻觉 7 条铁律
• CVE 编号已联网核实（禁止凭记忆编造）
• 行号已用 Read 验证（禁止模糊范围）
• 依赖安全检查使用 tavily（禁止 web_search）
• 逻辑漏洞有完整 CoT 推理记录
• DKTSS 评分完整
• 报告三段式格式齐全（描述 + 漏洞详情 + 修复建议）
• 分析达到 L4 级别（1500字以上，包含完整 7 要素）
• CONFIRMED vs HYPOTHESIS 状态正确
• 已阅读 references/report-template.md

---

注意事项

1. 不要信任 LLM 的"记忆"：所有中间结果都持久化到文件
2. "没有发现也是有效结果"：每个文件必须有"已审阅，无发现"或发现记录
3. javax. 和 jakarta. 双命名空间**：Java EE → Jakarta EE 迁移历史，扫描规则必须同时匹配两个命名空间
4. 大模块拆分追踪：EALOC > 15000 的模块必须拆分成多个子任务

---

大型项目增强：CPG 工具支持

对于 EALOC > 50000 的大型项目，推荐使用代码属性图（CPG）工具增强分析能力。

推荐工具：Joern

优势：

• 支持反编译伪代码分析（可用于 jar 包审计）
• 提供完整的代码属性图（AST + CFG + PDG）
• 支持复杂的跨文件调用链追踪
• 内置查询语言（Joern Query）进行自定义规则

集成方式：

# 安装 Joern
./joern --script audit.sc

# audit.sc 示例
importCode("path/to/project")
cpg.method.name("exec").callIn.l.foreach { call =>
  println(s"Potential RCE: ${call.location}")
}

适用场景：

• 超大型项目（>50 万行）
• 需要跨模块调用链分析
• 反编译代码审计

与现有架构整合

Layer 0: Joern CPG 构建（大型项目可选）
    ↓
Layer 1: ripgrep + Semgrep 预扫描
    ↓
Layer 2: LLM 双轨审计
    ↓
Layer 2.5: CoT 四步推理（逻辑漏洞）
    ↓
Layer 3: LSP/Joern 语义级验证

---

输出文件清单

文件	生成阶段	说明
audit-metrics.json	Phase 0	项目度量数据（文件数、行数、EALOC）
tier-classification.md	Phase 1	Tier 分类结果
scenario-tags.json	Phase 1	API 场景标签
dependency-security.md	Phase 1	依赖安全检查结果
p0-critical.md	Phase 2 Layer 1	P0 级危险模式（需 --scan 参数）
p1-high.md	Phase 2 Layer 1	P1 级危险模式（需 --scan 参数）
p2-medium.md	Phase 2 Layer 1	P2 级危险模式（需 --scan 参数）
findings-raw.md	Phase 2	候选漏洞列表（未验证）
findings-verified.md	Phase 3	验证后漏洞列表（已确认）
audit-report.md	Phase 5	最终审计报告
custom-rules.yaml	Phase 4（可选）	自定义 Semgrep 规则

说明：

• 标注"需 --scan 参数"的文件需要执行 python scripts/java_audit.py --scan 才会生成
• Phase 4 的 custom-rules.yaml 为可选输出，仅当需要将漏洞模式沉淀为规则时生成

---

⚠️ 输入长度限制应对策略（重要）

问题: LLM 存在输入长度限制（约 200KB），一次性加载过多内容会导致 Range of input length should be [1, 202745] 错误。

分阶段执行策略

⚠️ 必须遵循以下分阶段执行策略，避免输入长度超限：

┌─────────────────────────────────────────────────────────────┐
│                    分阶段执行策略                              │
└─────────────────────────────────────────────────────────────┘

Step 1: 脚本执行（不直接读取文件）
  ├── python audit.py --detect-lang     # 仅获取语言检测结果
  ├── python java_audit.py --scan --tier # 仅获取扫描摘要
  └── 输出内容是精简的摘要信息（< 10KB）

Step 2: 针对性搜索（不全文件读取）
  ├── search_content "password|secret"  # 只返回匹配行
  ├── search_content "Runtime.getRuntime"
  └── 输出内容是匹配的关键行（< 5KB）

Step 3: 分段读取关键文件（限制行数）
  ├── read_file offset=50 limit=30      # 只读取 30 行
  ├── read_file offset=100 limit=50     # 分段读取
  └── 每次读取限制在 50-100 行以内

Step 4: 分段生成报告（分段写入）
  ├── write_to_file 先写框架
  ├── replace_in_file 逐个添加漏洞
  └── 避免一次性写入大量内容

内容量限制规则

操作类型	限制	说明
脚本执行输出	< 10KB	脚本输出是精简摘要，不会超限
search_content 结果	< 5KB	只返回匹配行，使用 headLimit 限制
read_file 单次读取	< 100 行	使用 offset 和 limit 参数分段读取
单次响应总内容	< 50KB	控制单次响应中的总内容量

大型项目处理策略（EALOC > 10000）

⚠️ 当 EALOC > 10000 时，必须采用以下策略：

┌─────────────────────────────────────────────────────────────┐
│                   大型项目审计流程                             │
└─────────────────────────────────────────────────────────────┘

Phase 0: 仅执行脚本
  ├── python audit.py --detect-lang
  ├── python java_audit.py --scan --tier
  └── 不直接读取任何源文件

Phase 1: 根据扫描结果确定重点
  ├── 读取 p0-critical.md、p1-high.md（脚本生成的报告）
  ├── 确定需要深入分析的文件列表（< 10 个）
  └── 不全量读取所有文件

Phase 2: 针对性分析关键文件
  ├── 只读取 P0/P1 级危险模式涉及的文件
  ├── 分段读取（每次 < 100 行）
  └── 使用 search_content 搜索关键模式

Phase 3: 分段生成报告
  ├── 先写入报告框架
  ├── 逐个添加漏洞详情
  └── 每次添加 1-2 个漏洞

禁止的操作

禁止操作	原因	正确做法
❌ 一次性读取整个文件	可能超过 200KB	✅ 使用 offset/limit 分段读取
❌ 一次性读取多个大文件	累积超限	✅ 逐个读取，控制总量
❌ 不使用脚本直接读取源文件	内容量不可控	✅ 先执行脚本获取摘要
❌ 在单次响应中处理过多漏洞	报告内容超限	✅ 分多次响应处理

正确的审计流程示例

# 正确流程（避免超限）

## Step 1: 执行脚本获取摘要
→ python audit.py /path/to/project --detect-lang
→ 输出: 语言类型、文件数量（< 2KB）

## Step 2: 执行扫描获取危险模式
→ python java_audit.py /path/to/project --scan --tier
→ 输出: P0/P1/P2 发现数量、文件列表（< 10KB）

## Step 3: 读取扫描报告确定重点
→ read_file p0-critical.md（< 5KB）
→ read_file p1-high.md（< 5KB）
→ 确定需要深入分析的文件（< 10 个）

## Step 4: 针对性搜索关键模式
→ search_content "password|secret" --headLimit 20
→ search_content "Runtime.getRuntime" --headLimit 10
→ 输出: 匹配的关键行（< 5KB）

## Step 5: 分段读取关键文件
→ read_file Controller.java offset=50 limit=30
→ read_file Service.java offset=100 limit=50
→ 每次读取 < 100 行

## Step 6: 分段生成报告
→ write_to_file findings-raw.md（先写框架）
→ replace_in_file（添加漏洞 1）
→ replace_in_file（添加漏洞 2）
→ 分多次添加，避免一次性写入过多

---

小型项目简化流程

适用条件：EALOC < 15,000（小型项目）

简化执行策略

标准流程	简化流程	说明
Phase 0 + Phase 1 分开执行	合并执行	一次性统计 + 读取 pom.xml
Phase 2 Layer 1/2/3 分开	合并执行	直接 Read 所有文件
Phase 2.5 覆盖率检查	可跳过	小型项目必须 100% 覆盖
Phase 3 + Phase 5 分开	合并执行	验证 + 报告一起生成

简化流程图

Step 1: 度量 + 侦察
  ↓
  - 统计文件数、行数
  - 计算 EALOC，判断项目规模
  - 读取 pom.xml，检查依赖安全
  - 列出所有 Controller 入口

Step 2: 全量代码审计
  ↓
  - Read 所有 Java 文件
  - 检查权限控制（Control-driven）
  - 追踪危险模式（Sink-driven）
  - 记录所有发现

Step 3: 验证 + 报告
  ↓
  - 应用反幻觉铁律
  - CVE 联网核实
  - 生成 audit-report.md
  - 报告末尾添加覆盖率统计

小型项目执行命令

# Step 1: 度量
$files = Get-ChildItem -Recurse -Filter *.java
$files.Count  # 文件数
($files | Get-Content | Measure-Object -Line).Lines  # 行数

# Step 2: 列出所有文件
$files | Select-Object -ExpandProperty FullName

# Step 3: 逐个读取审计
foreach ($file in $files) {
    Read $file.FullName
    # 检查权限控制、危险模式
}

# Step 4: 生成报告
# 按 report-template.md 格式书写

覆盖率统计模板

## 审计覆盖率统计

| 层级 | 扫描内容 | 覆盖数量 | 总数量 | 覆盖率 |
|------|----------|----------|--------|--------|
| Layer 1 | 危险模式预扫描 | 18 个文件 | 18 个 Java 文件 | 100% |
| Layer 2 | 双轨审计 | 11 个 Controller | 11 个 Controller | 100% |
| Layer 3 | 调用链验证 | 6 个漏洞 | 6 个候选漏洞 | 100% |

---

文档版本: v1.9.2
最后更新: 2026-04-03

版本历史

版本	日期	变更内容
v1.9.2	2026-04-03	新增：前端审计支持（JS/React/Vue）、语言检测功能、前端 Semgrep 规则
v1.9.1	2026-04-03	修复：Tier 分类扩展支持多框架、覆盖率正则修复、Jakarta EE 规则、Layer 2.5 触发条件检查清单
v1.9.0	2026-04-02	依赖安全检查重构（mvnrepository.com 联网核实）、新增质量校验脚本
v1.8.0	2026-04-01	重构报告格式：h1漏洞名称 + 漏洞列表 + 审计进度 + 三段式漏洞详情
v1.7.0	2026-03-31	初始版本