SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsjava-audit-skill

java-audit-skill

Security & auditing

View repository

Updated 10-15 17:26

About this skill

AI+Java Code Audit Skill

This Skill encodes a senior auditor's working methods and quality standards into an LLM-executable protocol, solving core pain points of bare-run LLMs such as low coverage, high hallucination, and chaotic prioritization. email : aurora1219@139.com

Core Philosophy

The LLM has capability, but lacks discipline. The Skill does not teach the LLM "what SQL injection is"; instead, it equips it with a senior auditor's working skeleton—defining workflows, allocating resources, setting guardrails, and standardizing output.

6-Phase Audit Pipeline

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

Each Phase has clear inputs, outputs, and quality standards, and all intermediate results are fully persisted to files.

Phase 0: Codebase Measurement

Objective: Measure project scale, calculate audit workload, and provide a basis for Agent allocation.

Execution Script

# 统计代码行数和文件数（注意括号）
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

Output file: metrics.json

{
  "total_loc": 131000,
  "java_files": 847,
  "kt_files": 0,
  "xml_files": 156,
  "controllers": 40,
  "modules": 5,
  "complexity_score": "HIGH"
}

Phase 1: Project Reconnaissance & EALOC Resource Allocation

1.1 Tier Classification Rules

Rule Condition Tier Analysis Depth
Rule 0 Third-party library source code SKIP No audit
Rule 1 Layer 1 pre-scan has P0/P1 candidates T1 Dynamic promotion
Rule 2 Contains @Controller/@RestController/@WebServlet/Filter T1 Full in-depth analysis
Rule 3 Contains @Service/@Repository/@Mapper T2 Focus on key dimensions
Rule 4 Class name contains Util/Helper/Handler T2 Focus on key dimensions
Rule 5 .properties/.yml/security.xml T2 Focus on key dimensions
Rule 6 Contains @Entity/@Table/@Data T3 Fast pattern matching
Rule 7 Matches no rule T2 Conservative fallback

1.2 EALOC Formula

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

Agent Allocation: Agent数量 = ceil(EALOC / 15000)

1.3 Output file: 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: Three-Layer Audit Architecture

Layer 1: Full Pre-Scan (No LLM)

Use ripgrep + Semgrep to scan all files and flag dangerous patterns by P0-P3.

P0-Level Dangerous Patterns (RCE/Deserialization)

# 反序列化全家族
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-Level Dangerous Patterns (SQL Injection/SSRF/File Operations)

# 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-Level Dangerous Patterns (Authentication/Authorization/Encryption)

# 认证相关
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: Dual-Track Audit Model

Each Agent executes two parallel audit tracks:

Track 1: Sink-driven (trace upward from dangerous code)

Discover Runtime.exec(cmd) → trace cmd parameter source → check whether there is filtering → determine whether it comes from user input

Track 2: Control-driven (inspect security controls downward from endpoints)

Discover /api/admin/deleteUser endpoint → check whether there is an authentication annotation → check whether there is permission validation

Why are two tracks needed? For vulnerabilities such as authentication bypass, Sink-driven alone cannot find them—the vulnerability is not that a certain line of code has a problem, but that an endpoint lacks the permission check it should have.

Layer 2.5: Code Analysis Depth Check

For vulnerability types that Semgrep rules cannot cover, judgment is needed through code analysis:

Business Logic Vulnerabilities

检查要点：
1. 支付金额：金额是否来自前端？是否有后端校验？
2. 库存并发：是否有并发控制？检查和扣减是否原子操作？
3. 状态机：状态流转是否有前置条件校验？

Authorization Bypass Vulnerabilities

检查要点：
1. 水平越权：数据查询是否校验归属？userId 是否从 Session 获取？
2. 垂直越权：管理接口是否有权限注解？前后端权限是否一致？

Dependency Security

检查要点：
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. 标记需要升级的依赖

Web Search Example：

发现依赖:
  <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+

Runtime Configuration

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

For detailed determination methods, see: references/vulnerability-conditions.md Sections 16-20

Layer 3: Call Chain Semantic-Level Verification

Prefer using LSP for semantic-level tracing:

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

When LSP is unavailable, fall back to Grep + Read for manual tracing.

Phase 2.5: Coverage Gate

This is the core design that goes against LLM nature—LLMs tend to skip code that "looks unimportant," yet vulnerabilities love to hide in exactly those places.

Module Coverage Matrix

| # | 模块路径 | 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 | 部分完成 | 未开始 |

File-Level Coverage Verification

Each Agent output must include a list of reviewed files:

| # | 文件路径 | 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 | 跳过 第三方库 | - |

Gate Check: Take this list and diff it against the actual file list from the find command. Files that do not appear in the list = missed review.

Gate Decision Logic

收到每个 Agent 结果后立即执行：
1. 读取 Agent 输出的「审阅文件清单」
2. 与实际文件列表交叉验证
3. 覆盖率 = 100% → 该 Agent 通过
   覆盖率 < 100% → 立即为未覆盖文件启动补扫 Agent

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

It is forbidden to proceed to Phase 3 when coverage < 100%. No exceptions.

Phase 3: Vulnerability Verification & DKTSS Scoring

5 Ironclad Rules Against Hallucination

  1. Before reporting a vulnerability, you must use Read to verify the file exists
  2. Code snippets must come from actual Read output and must not be fabricated
  3. Each hop in the call chain must be annotated with file:line number
  4. Uncertain findings must be marked as HYPOTHESIS and must not be marked as CONFIRMED
  5. Better to miss a report than to report a false positive

Determining Whether a Vulnerability Holds

See references/vulnerability-conditions.md

Example - Fastjson Deserialization Determination Flow:

发现 JSON.parseObject() / JSON.parse() 调用
↓
检查版本：
  < 1.2.68 → 直接可利用
  1.2.68-1.2.80 → 检查 classpath 是否有特定依赖（groovy/jython/aspectj/commons-io）
  ≥ 1.2.83 → 检查 safeMode 配置

DKTSS Scoring System

See references/dktss-scoring.md

Core Formula:Score = Base - Friction + Weapon + Ver

  • Base: Score based on vulnerability type and actual impact
  • Friction: Practical resistance (access path/permission threshold/interaction complexity)
  • Weapon: Degree of weaponization
  • Ver: Version factor

Status Definitions

Status Definition Requirements
CONFIRMED Verified Exploitable PoC is executable, call chain is complete, impact is clear
HYPOTHESIS Suspected vulnerability, requires manual verification Suspicious pattern found but cannot be fully confirmed

Key Principle: Better to mark as HYPOTHESIS for manual verification than to mark uncertain findings as CONFIRMED and pollute the report's credibility.

Phase 4: Semgrep Rule Consolidation

Convert confirmed vulnerability patterns into Semgrep static analysis rules (YAML format), which can be integrated into CI/CD pipelines.

Example Rule:

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]

Phase 5: Standardized Report Generation

See references/report-template.md

9 Required Field Groups

  1. Basic Information: Status, vulnerability type, CWE-ID, severity, DKTSS score, affected component, file location
  2. Trigger Conditions: Prerequisites for triggering the vulnerability
  3. Required Permissions: Permissions required to exploit the vulnerability (no authentication/low privilege/high privilege)
  4. Vulnerability Principle: Detailed technical analysis
  5. Code Evidence: Actual code snippet (must come from Read output)
  6. Call Chain: Complete path from Source → Sink, with each hop annotated with file:line number
  7. PoC: Executable verification code
  8. Verification results: PoC execution results
  9. Remediation recommendations: Immediate fix/architectural optimization/defense in depth

Report output files

  • findings-raw.md: Candidate vulnerabilities discovered in Phase 2
  • findings-verified.md: Confirmed vulnerabilities after Phase 3 verification (final data source)
  • audit-report.md: Final report formatted in Phase 5

6 Core Methods of AI Code Auditing

1. Semantic rule matching

The rules of traditional tools are "dead"—they can only match fixed parameter names. AI identifies core business meanings through semantics and adapts to any naming convention.

Example: Privilege escalation vulnerability detection

  • Traditional rules: Check whether user_id parameter exists
  • AI semantic rules: Identify all parameters in the interface that represent user identity identifiers, and verify whether, when such a parameter is used to locate the ownership of business data, it is forcibly bound to the identity of the currently logged-in user

Applicable scenarios: Unauthorized access, general privilege escalation, CAPTCHA bypass, password reset vulnerabilities

2. Business process anomaly auditing based on causal reasoning

AI first builds a causal relationship baseline and state machine model for the business, clarifying the mandatory preconditions (causes) and legitimate postconditions (effects) of each business operation, and then verifies them through counterfactual reasoning.

Example: E-commerce payment scenario

  • Mandatory preconditions: The order has been created and unpaid, the payment amount matches, and the callback credential is legitimate
  • Legitimate postconditions: The order becomes pending shipment, inventory is deducted, and a shipping order is generated
  • Test case: Skip payment and directly call the shipment confirmation interface

Applicable scenarios: Process bypass, step reversal, illegal state transition

3. Logical consistency auditing of permissions and access control

Build a complete permission-resource binding model and perform three types of checks:

Check type Method Covered vulnerabilities
Horizontal privilege escalation check Test with credentials of different users with the same role Accessing others' private data
Vertical privilege escalation check Test high-privilege interfaces with low-privilege credentials Privilege escalation
Consistency check Compare permission check logic of similar interfaces Partially missing checks

Applicable scenarios: Horizontal/vertical privilege escalation, unauthorized access, frontend-backend permission inconsistency

4. Adversarial generation auditing of boundary conditions and exception branches

Generate adversarial test cases based on the business semantics of parameters, rather than random strings:

Parameter type Test value Target vulnerability
Amount Negative numbers, 0, extremely large values, more than 2 decimal places 0-yuan payment, negative-amount refund
Quantity Negative numbers, exceeding inventory upper limit Negative inventory, ordering in excess
Time Expired time, earlier than the current time Bypassing validity period restrictions

White-box scanning focus: Whether the exception handling branch contains "skip permission verification", "return success on exception", or "leak sensitive information"

5. Multi-dimensional correlated vulnerability chain reasoning

Associate individual defects according to business scenarios, interface dependencies, and data flow relationships, and automatically identify vulnerability points that can be chained together.

Example vulnerability chain：

  1. /api/user/list Unauthorized access → obtain the full set of users' mobile phone numbers and user_id
  2. /api/user/password/reset Only mobile phone number and user_id are verified, with no verification code

→ Chained together to form a complete attack chain, enabling password reset for any user

6. Code semantic-level logic defect auditing in white-box scenarios

Focus on scanning high-frequency logic defect scenarios:

  • Missing permission verification (only verifies login, does not verify data ownership)
  • Business logic errors (amount calculation order, inventory deduction order)
  • Exception handling defects (directly returning success after catching an exception)
  • Interface design defects (no idempotency, no secondary verification for sensitive operations)

5-layer solution for long-context problems

Layer 1: Source governance (best cost-effectiveness, reduces context by 60%+)

Must-filter content：

  • Comments, blank lines, pure log-printing code
  • Unit test files
  • Third-party dependency libraries
  • Build configuration files
  • Auto-generated code (protobuf, MyBatis Mapper)

Low-risk content that can be filtered：

  • Pure data entity classes containing only get/set
  • Utility methods with no security risk
  • Non-core statistical report code

Note: Filtering must be based on semantic recognition and must not mistakenly delete core security code such as permission verification, encryption and decryption, and input filtering.

Layer 2: Three-tier progressive audit architecture (core solution)

Layer Content Token control
First layer: global architecture layer Project architecture description, module division, global permission model, core interceptor rules, external interface list ≤ 8K
Second layer: module-level audit Split independent audit units by business domain, input module code + global security baseline + dependent interface metadata 32K-64K
Third layer: cross-module verification Input only core code snippets of related modules + call chain metadata ≤ 64K

Layer 3: Structured semantic compression (reduces tokens by 70%+)

Convert code into structured metadata:

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

Layer 4: RAG + multi-turn dialogue (break through physical window limits)

  1. Build a code knowledge base: split by function/class, generate vector embeddings and store them in a vector database
  2. Accurately retrieve relevant context: retrieve relevant code snippets through natural language or risk features
  3. Multi-turn dialogue incremental audit: handle one subdivided goal per round, with the previous round's output serving as lightweight context for the next round

Layer 5: Incremental audit mechanism (engineering implementation)

Integrate with Git/CI/CD, and audit only the code changed in this commit and the related call chains, reducing context volume by 90%+.

5 major implementation pitfalls

❌ Pitfall 1: Simply splitting code by line count

Problem: It breaks code semantic associations, making cross-file call chains impossible to understand, and causing severe underreporting

Correct approach: Split according to business boundaries and dependencies, and adopt a three-layer progressive architecture

❌ Misconception 2: Over-reliance on long-context models

Problem: After exceeding 128K tokens, attention degrades severely, and the cost is extremely high

Correct approach: Medium context + chunking with pruning + RAG, with long context used only as an auxiliary for cross-module verification

❌ Misconception 3: Throwing all code at AI

Problem: Context overflow, interference from irrelevant information, sharp rise in false positives, and extremely slow speed

Correct approach: Complete invalid information filtering and risk classification, and follow "do not input unless necessary"

❌ Misconception 4: Completely abandoning traditional tools

Problem: Large models have hallucination issues that cannot be compensated for by rule matching

Correct approach: Traditional tools for pre-filtering + AI deep reasoning + traditional tools for post-validation

❌ Misconception 5: Focusing only on known vulnerabilities

Problem: Wastes AI's core capability—detecting business logic vulnerabilities

Correct approach: Focus on logic flaws, privilege escalation vulnerabilities, and process bypasses that traditional tools cannot cover

Reference documents

Document Content
vulnerability-conditions.md Vulnerability condition judgment table (Fastjson, JNDI, SSTI, etc.)
dktss-scoring.md Detailed explanation of the DKTSS scoring system
report-template.md Standardized vulnerability report template

Execution checklist

Before audit starts

  • Confirm project path and tech stack (Java/Kotlin version, framework)
  • Run the Phase 0 measurement script
  • Complete project reconnaissance, generate Tier classification and EALOC calculation

During the audit

  • Layer 1 pre-scan completed, P0-P3 marked in place
  • Dual-track audit for each Agent (Sink-driven + Control-driven)
  • Update the coverage matrix in real time
  • File-level coverage verification (checklist vs actual file diff)

After the audit is completed

  • Coverage gate passes 100%
  • Every vulnerability follows the 5 iron rules against hallucination
  • DKTSS score is complete
  • The report has all 9 required fields
  • CONFIRMED vs HYPOTHESIS status is correct

Precautions

  1. Do not trust the LLM's "memory": Persist all intermediate results to files
  2. "No findings is also a valid result": Every file must have either "reviewed, no findings" or a findings record
  3. javax. and jakarta. dual namespace**: Java EE → Jakarta EE migration history; scanning rules must match both namespaces at the same time
  4. Large module split tracking: Modules with EALOC > 15000 must be split into multiple subtasks