name: code-security-audit
description: 基于中国国家标准（GB/T 34943/34944/34946/39412）的代码安全审计工具。支持 Java、C/C++、C#、Python 多语言漏洞检测，采用「快速扫描 + LLM 深度审计」双引擎，自动去重生成的 Markdown 格式审计报告。适用于项目验收、安全合规审查、代码质量评估等场景。

代码安全审计技能

> 测试环境：已在 GLM-5 模型下测试通过
>
> 详细文档：
> - 详细审计流程 - LLM 审计执行流程和验证机制
> - 输出质量检查标准 - 修复方案编写要求和验证机制
> - 常见问题解决方案 - 问题排查指南
> - 漏洞知识库 - 各类漏洞的危险模式与修复方案
> - 国标规则文件 - GB/T 34943/34944/34946/39412 完整规则

📋 概述

本技能提供完整的代码安全审计工作流，基于中国国家标准检测源代码中的安全漏洞。

核心流程：

快速扫描 → 基线入库 → LLM 深度审计 → 生成报告

输出物：
- findings/baseline/*.md — 快速扫描发现的漏洞
- findings/llm_audit/*.md — LLM 独立审计发现的漏洞
- audit_report_YYYYMMDD_HHMMSS.md — 最终审计报告

🎯 审计原则

• 独立性优先：LLM 审计必须完全独立于快速扫描
• 双重验证：LLM 审计发现创建后立即验证，finalize_report 时批量验证
• 全面覆盖：LLM 审计应全面覆盖所有安全问题，不自我设限
• 国标为准绳：漏洞定性和分类严格遵循 GB/T 标准

🔧 三层审计分工明确

根据审计结果，正确的分工应该是：

第一层：快速扫描（代码负责）

职责：使用正则表达式搜索高风险函数，发现高风险函数调用

⚠️ 重要说明：快速扫描规则已在 scripts/skill.py 的 quick_scan_patterns() 函数中定义，LLM 审计不应重复这个工作。

特点：
- ✅ 高效率、低精度
- ✅ 特征明显，容易识别
- ✅ 不需要上下文分析
- ✅ 具体规则见 scripts/skill.py 第 319-420 行

第二层：LLM审计（LLM负责）

职责：语义分析，发现需要上下文分析的漏洞

⚠️ 重要说明：LLM审计应专注于需要上下文分析的漏洞，不应使用关键字搜索。

特点：
- ✅ 低效率、高精度
- ✅ 需要理解代码上下文
- ✅ 需要分析业务逻辑
- ✅ 具体方法见 audit_workflow.md

第三层：LLM审查（LLM负责）

职责：深入分析复杂业务逻辑，验证漏洞，做出最终决策

特点：
- ✅ 最高精度
- ✅ 需要深入理解业务逻辑
- ✅ 需要综合分析多个漏洞

代码负责（格式验证）

代码特点：
- ✅ 只做基本格式检查，不做语义质量判断
- ✅ 行号验证智能化，可自动修正错误行号
- ✅ 所有验证函数都有明确注释说明"仅做格式检查"

LLM负责（语义质量）

LLM质量判断要求：
- ✅ 问题描述：必须说明漏洞成因、攻击方式、潜在风险
- ✅ 修复方案：必须提供具体修复方法、修复原理、代码示例或API建议
- ✅ 严重等级：必须符合漏洞实际危害，考虑上下文和可利用性
- ✅ 误报判定：必须分析是否有安全防护措施

⚠️ 行号验证责任（重要）

LLM责任：
- 🔴 必须使用 Grep 工具验证行号
- 🔴 确保行号对应实际代码行而非注释行
- 🔴 创建 md 文件前必须验证行号准确性

代码辅助功能：
- ✅ validate_code_snippet() 会自动修正错误的行号
- ✅ 如果行号错误，会返回修正后的行号和实际代码
- ⚠️ 但这不应成为 LLM 不验证行号的借口

工作流程：

LLM创建md文件 → finalize_report 自动验证 → 
如果行号错误：
  代码自动修正行号 → 状态设为"有效"
如果验证失败：
  记录为幻觉 → 不出现在报告中

违反后果：
- 行号错误会导致验证失败，记录为幻觉
- 验证失败的发现不会出现在审计报告中
- 可能遗漏关键漏洞位置

🚀 LLM 审计优势发挥

LLM 审计相比传统静态分析工具具有独特优势，必须充分利用：

LLM 审计应发现的典型问题（传统工具难以检测）：

1. 业务逻辑缺陷
   - 认证绕过：密码重置流程漏洞、会话管理缺陷
   - 权限问题：水平/垂直越权、缺失权限检查
   - 状态篡改：订单状态绕过、支付流程漏洞

2. 数据流安全问题
   - 用户输入从 A 文件传递到 B 文件的危险函数
   - 敏感数据从存储到展示的泄露路径
   - 配置数据影响多个模块的安全风险

3. 组合攻击链
   - 信息泄露 + 身份伪造 → 账户接管
   - SSRF + 内网访问 → 权限提升
   - 路径遍历 + 文件上传 → RCE

审计检查技巧：
- 从用户入口追踪数据流：输入 → 处理 → 存储 → 输出
- 从敏感操作逆向追踪：危险函数 → 调用链 → 数据来源
- 从配置文件分析影响：配置项 → 使用位置 → 安全影响

⚠️ LLM 审计强制要求

🔴 强制执行：LLM 在执行审计前必须完整阅读以下文档：

1. LLM 审计执行指南 - 包含：
   - 漏洞类型检查清单（严重/高危/中危）
   - 分层审计策略（四轮审计流程）
   - 语言特定审计指导（Python/Java/C++/C#）
   - 审计执行检查清单（逐项确认）
   - 行号验证流程和防幻觉机制

2. 输出质量检查标准 - 包含：
   - 🔴 质量检查清单（创建 md 文件时必须核对）
   - 修复方案编写要求（禁止敷衍内容）
   - 修复方案示例库（合格/不合格对比）
   - 禁止行为检查
   - 审计完成确认清单

违反后果：未阅读上述文档将导致审计不完整、遗漏关键漏洞、行号错误、质量不合格等问题。

行号验证强制要求（LLM创建md文件前必须执行）

⚠️ 极其重要：行号错误会导致验证逻辑错误修正，报告中显示错误位置，严重影响审计可信度。

必须执行的验证步骤

步骤 1：使用 Grep 精确搜索

# 搜索函数定义
Grep pattern="def auth_bypass" path="目标文件" output_mode="content" -n

# 搜索类定义
Grep pattern="class VulnerableClass" path="目标文件" output_mode="content" -n

# 搜索变量声明
Grep pattern="HARDCODED_PASSWORD" path="目标文件" output_mode="content" -n

步骤 2：确认行号对应实际代码
- 检查返回的行号是否为代码行（非注释行、非空行）
- 检查代码片段是否与源文件内容完全匹配

步骤 3：填写验证后的精确行号
- 使用 Grep 返回的精确行号
- 禁止凭记忆填写
- 禁止根据函数名推断行号

❌ 常见错误示例

⚠️ 验证逻辑的局限性

finalize_report 的验证逻辑使用关键词匹配：
- 只要 2 个关键词重叠就认为匹配
- 例如：def + self 就会被错误匹配
- LLM 必须主动验证行号，不能依赖验证逻辑

错误修正示例：

原始行号: 185 (auth_bypass函数)
验证逻辑关键词匹配: def + self → 匹配到第32行
错误修正后: 行号变成32
报告显示: 错误位置

✅ 正确流程

发现漏洞 → Grep搜索精确位置 → 确认行号 → 创建md文件 → finalize_report验证通过

📋 执行前必知

1. 执行前确认关键函数存在（quick_scan、finalize_report）
2. 发现文档提到不存在的函数时，先修复文档再执行
3. "学习标准"步骤必须输出确认（见下方步骤 4）

语言与标准对应关系

理论上支持所有编程语言的代码安全审计。

> 详细规则见国标文件：
> - GBT_34943-2017.md - C/C++ 专用
> - GBT_34944-2017.md - Java 专用
> - GBT_34946-2017.md - C# 专用
> - GBT_39412-2020.md - 通用基线（所有语言）

步骤 2：学习标准（必须输出确认）

🔴 强制要求：此步骤必须输出确认信息，否则不应继续后续步骤。

确认输出格式

【步骤 2 学习标准确认】
- 已阅读：audit_workflow.md（审计执行流程）
- 已阅读：quality_standards.md（质量检查清单）
- 已学习：国标规则 X 条（语言：Java/C++/Python/...）
- 已理解：质量检查清单 5 项
- 已理解：修复方案要求（字数≥30，禁止敷衍内容）
- 下一步：步骤 3 - 创建目录

学习内容

审计流程

┌─────────────────────────────────────────────────────────────────────┐
│                        Agent 代码安全审计流程                        │
├─────────────────────────────────────────────────────────────────────┤
│  0️⃣ 学习流程  ◀ 【强制】阅读 SKILL.md + audit_workflow.md + quality_standards.md │
│  1️⃣ 语言判定  ◀ 【LLM 自主】通过文件扩展名判断语言                  │
│  2️⃣ 创建目录  ◀ 【必须】创建 findings/baseline 和 llm_audit 目录   │
│  3️⃣ 快速扫描  ◀ 【自动】调用 quick_scan，直接生成 baseline md 文件  │
│  4️⃣ 学习标准  ◀ 【必须输出】确认已学习的国标及规则数                │
│  5️⃣ LLM 审计  ◀ 【必须】多 agent 并行审计 + 创建 md                  │
│  6️⃣ 生成报告  ◀ 【必须调用 finalize_report】去重 + 验证 + 生成     │
│  7️⃣ 审计完成  ◀ 【输出】报告路径和验证结果                          │
└─────────────────────────────────────────────────────────────────────┘

💡 流程设计说明：
- 快速扫描在"学习标准"之前：快速扫描是自动执行的（正则匹配），不需要LLM了解国标规则
- 学习标准在LLM审计之前：LLM审计需要国标知识来正确分类漏洞，此时学习针对性更强

⚠️ 步骤 0 强制要求：
- 必须阅读 SKILL.md - 了解审计原则和流程
- 必须阅读 LLM 审计执行指南 - 掌握审计方法和检查清单
- 必须阅读 输出质量检查标准 - 掌握质量检查清单和修复方案要求
- 违反后果：审计不完整、遗漏关键漏洞、行号错误、质量不合格

步骤 4：快速扫描（自动生成 baseline）

⚠️ 此步骤自动完成，无需 LLM 参与：

步骤 4：快速扫描（自动）
┌─────────────────────────────────────────────────────────────────────┐
│  ThreadPoolExecutor 并行扫描所有代码文件                             │
│  ┌──────┬──────┬──────┬──────┬──────┬──────┬──────┬──────┐          │
│  │文件1 │文件2 │文件3 │文件4 │文件5 │文件6 │文件7 │文件8 │ ← 按文件 │
│  │扫描  │扫描  │扫描  │扫描  │扫描  │扫描  │扫描  │扫描  │ 并行     │
│  └──────┴──────┴──────┴──────┴──────┴──────┴──────┴──────┘          │
└─────────────────────────────────────────────────────────────────────┘
    ↓
生成 baseline md 文件（状态默认为"误报"）

执行方式：
- 调用 quick_scan --target <target> 命令
- 自动按文件并行扫描（ThreadPoolExecutor）
- 自动创建 baseline md 文件
- 状态字段自动填写为"误报"
- 不再生成 scan_result.json

步骤 5：LLM 审计（多 agent 并行）

⚠️ 此步骤需要 LLM 参与，推荐多 agent 并行处理：

步骤 5 流程

┌─────────────────────────────────────────────────────────────────────┐
│                    步骤 5 LLM审计流程                               │
├─────────────────────────────────────────────────────────────────────┤
│  ⚠️ 强制要求：必须审计全部代码文件（详见 audit_workflow.md）          │
│  5a：独立审计全部代码文件（不查看 baseline md 文件）                  │
│  5b：多 agent 并行审计 + 状态判定 + 创建 llm_audit md 文件           │
└─────────────────────────────────────────────────────────────────────┘

⚠️ 全部代码文件审计要求（步骤 5）

🔴 强制要求：LLM审计必须覆盖项目中的全部源代码文件，不得遗漏任何文件。

原因说明：
- 不同LLM对"关键代码文件"的理解不一致，可能导致遗漏
- 漏洞可能存在于任何代码文件中，包括配置文件、工具类、实体类等
- 仅审计"关键文件"会降低审计的完整性和检出率

执行方法：

# 1. 使用Glob获取全部代码文件列表
Glob path="项目目录" pattern="**/*.java"  # Java项目
Glob path="项目目录" pattern="**/*.py"     # Python项目

# 2. 逐个阅读并审计每个文件
Read file_path="文件1路径" limit=200
Read file_path="文件2路径" limit=200
...

# 3. 发现漏洞后创建llm_audit md文件
Write file_path="findings/llm_audit/xxx.md" content="..."

> ** 详细检查清单**：见 audit_workflow.md "LLM审计详细检查清单"章节

多 Agent 并行审计（步骤 5b）

⚠️ 推荐多 agent 并行处理，提升效率：

步骤 5b：按批次并行审计（LLM）
┌─────────┬─────────┬─────────┬─────────┐
│ Agent 1 │ Agent 2 │ Agent 3 │ Agent 4 │  ← 多 agent 并行审计
│ 批次 1  │ 批次 2  │ 批次 3  │ 批次 4  │
│ 文件1-20│文件21-40│文件41-60│文件61-80│
└─────────┴─────────┴─────────┴─────────┘
    ↓
合并结果 → 进入步骤 6

分批策略：

并行处理要求：

• 每个 agent 独立审计分配的文件
• 每个 agent 必须使用 Read 工具检查代码上下文
• 每个 agent 完成以下任务：
• 状态判定：判定 baseline md 文件的状态（有效/误报）
• 独立审计：发现快速扫描遗漏的漏洞，创建 llm_audit md 文件
• 所有 agent 完成后继续步骤 6

状态判定规则

状态判定流程（每个 agent 执行）

┌─────────────────────────────────────────────────────────────────────┐
│                    单个发现状态判定流程                              │
├─────────────────────────────────────────────────────────────────────┤
│  ⚠️ 必须使用 Read 工具检查代码上下文（前后 10 行）                    │
│  1️⃣ 检查是否仅导入  ◀ 是 → 保持"误报"                               │
│  2️⃣ 检查是否测试代码  ◀ 是 → 保持"误报"                             │
│  3️⃣ 检查是否有安全防护  ◀ 是 → 保持"误报"                           │
│  4️⃣ 检查是否实际危险调用  ◀ 是 → 改为"有效"                         │
│  5️⃣ 更新 md 文件  ◀ 修改状态字段                                    │
└─────────────────────────────────────────────────────────────────────┘

⚠️ 上下文检查要求（步骤 5）

必须使用工具检查，禁止凭记忆判定：

两项检查都必须执行：

1. 本文件检查：Read 读取发现所在文件，检查前后 10 行上下文
   - 判断是否仅导入语句
   - 判断是否在测试/辅助函数中
   - 判断是否有安全防护代码

2. 跨文件检查：Grep 搜索项目范围，检查实际调用
   - import pickle → 搜索 pickle.loads、pickle.load
   - import subprocess → 搜索 subprocess.run、subprocess.call
   - 函数定义 → 搜索函数调用点
   - 类定义 → 搜索类实例化

检查示例：

# 本文件上下文
Read file_path="发现所在文件" offset=行号-10 limit=20

# 跨文件调用检查
Grep pattern="pickle\.loads" path="项目目录"
Grep pattern="subprocess\.run" path="项目目录"

常见误报判定：
- 仅 import 无调用 → 误报
- 测试/辅助函数中且无实际风险 → 误报
- 有参数验证/白名单过滤 → 误报
- 实际危险调用且无防护 → 有效

⚠️ 质量判断要求（LLM 责任）

代码仅做基本格式验证，以下质量判断由 LLM 负责：

问题描述要求：
- 说明漏洞成因（如：用户输入未验证直接拼接到命令）
- 说明攻击方式（如：攻击者可注入恶意命令执行任意操作）
- 说明潜在风险（如：可能导致服务器被控制、数据泄露）

修复方案要求：
- 提供具体修复方法（如：使用 PreparedStatement 参数化查询）
- 说明修复原理（如：将用户输入作为参数而非 SQL 的一部分）
- 可提供代码示例或 API 建议

md 文件格式

baseline md 文件格式（快速扫描生成）：

编号: #001
严重等级: 严重
漏洞类型: COMMAND_INJECTION
文件路径: test-samples/java/VulnerableJava.java
行号: 31
CWE: CWE-78
国标映射: GB/T34944-6.2.3.3 命令注入；GB/T39412-6.1.1.6 命令行注入  ◀ 【双国标映射】
来源: quick_scan
语言: java
状态: 误报  ◀ 【默认】LLM 审计时判定为"有效"或保持"误报"
问题代码: Runtime.getRuntime().exec(command);
问题描述: 描述内容（2-3句话）

llm_audit md 文件格式（LLM 审计创建）：

编号: #001
严重等级: 严重
漏洞类型: COMMAND_INJECTION
文件路径: test-samples/java/VulnerableJava.java
行号: 31
CWE: CWE-78
国标映射: GB/T34944-6.2.3.3 命令注入；GB/T39412-6.1.1.6 命令行注入  ◀ 【双国标映射】
来源: llm_audit
语言: java
状态: 误报  ◀ 【默认】LLM 审计时判定为"有效"或保持"误报"
问题代码: Runtime.getRuntime().exec(command);
问题描述: 描述内容（2-3句话）
修复方案: 具体修复方法（≥20字）

> 状态字段规则：
> - 默认状态：所有 md 文件默认状态为"误报"
> - LLM 判定：LLM 审计时判定为"有效"或保持"误报"
> - 禁止写"待判定"：状态字段必须填写（有效/误报）

> 双国标映射规则：
> - Java: GB/T 34944-2017 + GB/T 39412-2020
> - C/C++: GB/T 34943-2017 + GB/T 39412-2020
> - C#: GB/T 34946-2017 + GB/T 39412-2020
> - Python: 仅 GB/T 39412-2020（单映射）
>
> 格式：语言专用标准；通用基线，用中文分号分隔

步骤 6：生成报告（去重 + 验证 + 生成）

⚠️ 此步骤自动完成，调用 finalize_report 命令：

处理流程

┌─────────────────────────────────────────────────────────────────────┐
│                    步骤 6 生成报告流程                               │
├─────────────────────────────────────────────────────────────────────┤
│  6a：加载所有 md 文件（baseline + llm_audit）                        │
│  6b：去重处理（按文件-行号-类型去重，被丢弃的 md 状态设为"重复"）     │
│  6c：验证状态为"误报"的发现（代码片段验证 + 行号修正）                │
│  6d：验证通过 → 状态设为"有效"；验证失败 → 记录幻觉                   │
│  6e：过滤状态不为"有效"的发现                                        │
│  6f：生成报告（只包含"有效"状态的发现）                              │
└─────────────────────────────────────────────────────────────────────┘

验证环节

报告内容

⚠️ 报告的明细和统计只针对状态为"有效"的 md 文件：

执行方式

finalize_report --output audit_report.md

输出信息

{
  "total_loaded": 加载的 md 文件总数,
  "after_dedup": 去重后的数量,
  "duplicates_count": 重复的数量,
  "after_validation": 验证后的数量,
  "hallucinations_count": 幻觉数量,
  "effective_count": 有效发现数量（报告中的数量）
}

步骤 7：审计完成

⚠️ 此步骤输出审计结果：

输出内容

审计完成确认

• [ ] 报告已生成
• [ ] 验证结果已确认
• [ ] 有效发现数量符合预期
• [ ] 幻觉和重复已处理

LLM 审计执行检查清单

⚠️ 强制要求：LLM 审计必须按照以下检查清单逐项执行，确保全面覆盖。

📋 审计前准备

• [ ] 已阅读并理解"LLM 审计漏洞类型检查清单"
• [ ] 已阅读并理解"LLM 审计分层策略"
• [ ] 已阅读并理解"语言特定审计指导"

🔄 第一轮：高风险函数扫描（由快速扫描负责）

⚠️ 重要说明：此轮审计由快速扫描自动执行，LLM审计不应重复这个工作。

快速扫描已覆盖的漏洞类型：
- 命令执行函数、SQL操作函数、文件操作函数
- 加密算法使用、反序列化函数
- 硬编码凭证、信息泄露等

LLM审计应跳过此轮，直接进入第二轮数据流分析。

🔄 第二轮：数据流分析（LLM审计负责）

必须完成的分析项：

• [ ] 用户输入追踪
• 识别所有用户输入点（HTTP参数、环境变量、配置文件）
• 追踪数据传递路径（变量赋值、函数调用、类属性传递）

• 定位危险使用场景（命令执行、SQL拼接、文件操作、输出操作）

• [ ] 敏感数据追踪

• 识别敏感数据存储位置（数据库、文件、内存）
• 追踪数据传递路径（从存储到展示）

• 检查是否有泄露风险（日志、错误消息、调试输出）

• [ ] 配置数据追踪

• 识别关键配置项（数据库连接、密钥、权限配置）
• 追踪配置使用位置

• 检查配置是否影响安全决策

• [ ] 输入验证问题审计

• 数据真实性验证不足：检查签名校验、完整性检查
• 绕过数据净化和验证：检查大小写绕过、编码绕过
• 边界值检查缺失：检查数组下标、循环次数、缓冲区大小
• 除零错误：检查所有除法和取模运算

• 信任边界违反：检查不可信数据混入可信数据结构

• [ ] 资源管理问题审计

• 重复释放资源：检查文件/连接重复关闭
• 资源不安全初始化：检查环境变量直接使用
• 内存泄漏：检查全局缓存不断增长
• 访问已释放内存：检查对象关闭后继续使用

• 临时文件暴露：检查临时文件权限和清理

• [ ] 并发安全问题审计

• 竞态条件：检查共享变量无同步保护
• 会话信息泄露：检查全局session_data跨会话访问
• 未加限制的外部可访问锁：检查锁无限制获取

• 线程资源泄露：检查threading.local未清理

• [ ] 内存安全问题审计

• 缓冲区溢出：检查bytearray/buffer越界操作
• 堆内存清理：检查敏感数据释放前未清零
• 指针问题（C扩展）：检查ctypes无效指针、不兼容类型转换

🔄 第三轮：业务逻辑审计

必须完成的审计项：

• [ ] 认证流程审计
• 登录流程：检查是否有绕过路径（skip_auth参数）
• 注销流程：检查session是否正确销毁
• 密码重置：检查是否有逻辑漏洞
• 会话管理：检查是否有会话固定风险
• 认证信息暴露：检查区分"用户名不存在"和"密码错误"
• 无频率限制：检查登录尝试无限制

• 单因素认证：检查仅依赖密码认证

• [ ] 授权检查审计

• 权限验证：检查是否在所有敏感操作前执行
• 访问控制：检查是否有水平/垂直越权风险
• 角色管理：检查角色分配是否安全

• Cookie认证绕过：检查依赖Cookie值进行身份验证

• [ ] 状态转换审计

• 订单状态：检查是否有不合理的状态跳转
• 支付流程：检查是否有流程篡改风险

• 审批流程：检查是否有条件竞争

• [ ] 密码安全审计

• 弱密码策略：检查仅验证长度≥4
• 密码明文显示：检查input未掩码

• 个人信息保护不当：检查身份证号、手机号未加密存储

• [ ] 异常处理审计

• 空catch块：检查except: pass静默忽略异常

• 初始化失败未退出：检查异常后继续执行

• [ ] 代码质量问题审计

• 死代码：检查if True/if False、return后继续执行
• 缺失默认情况：检查switch/if-else缺少default
• 条件比较不充分：检查仅检查一种情况
• 无限循环：检查while True无退出条件

• 未经控制的递归：检查递归无深度限制

• [ ] Web安全问题审计

• HTTP头注入：检查response.headers用户输入
• XSS：检查response.write未转义
• 开放重定向：检查response.redirect未验证URL
• CSRF：检查敏感操作缺少Token验证
• 格式化字符串：检查user_input.format()

🔄 第四轮：组合漏洞分析

必须完成的分析项：

• [ ] 识别单个漏洞的利用前提
• [ ] 分析漏洞之间的依赖关系
• [ ] 评估组合攻击的可行性和影响

🔄 第五轮：扩展漏洞类型审计（新增）

必须完成的审计项：

• [ ] 信息泄露问题审计
• 日志注入：检查logging.info用户输入
• 堆栈跟踪泄露：检查异常详情输出

• 调试信息泄露：检查print/debug输出敏感信息

• [ ] 初始化问题审计

• 发布未完成初始化的对象：检查register_callback未初始化对象

• 不安全初始化：检查os.environ.get直接使用

• [ ] 算法复杂度问题审计

• 算法复杂度攻击：检查sorted/data可能导致最坏情况

• 资源耗尽：检查range(10000000)等大循环

• [ ] 敏感操作审计

• 敏感操作无保护：检查do_sensitive_operation无权限验证
• 子进程敏感资源：检查文件打开后启动子进程

📊 覆盖度检查

必须达到的覆盖目标：

⚠️ 质量检查

> 🔴 使用时机：创建每个 md 文件时必须执行此检查
> 详细检查清单见 docs/workflow/quality_standards.md

🚫 禁止行为检查

> 详细禁止行为清单见 docs/workflow/quality_standards.md

✅ 审计完成确认

> 详细确认清单见 docs/workflow/quality_standards.md

工具列表

finalize_report 验证内容：
| 验证项 | 说明 |
|--------|------|
| 去重处理 | 按 file:line:type 去重，LLM 审计优先 |
| 代码片段验证 | 验证代码片段是否存在于文件中 |
| 行号修正 | 如果行号不准确，修正为正确行号 |
| 状态更新 | 验证通过 → 状态设为"有效" |
| 幻觉记录 | 验证失败的发现记录为幻觉 |
| 修复方案 | 字数≥20 |

> 质量判断由 LLM 负责：问题描述是否说明漏洞原因/风险、修复方案是否合理可行

Markdown 文件格式

编号: #001
严重等级: 严重
漏洞类型: 命令注入
文件路径: test-samples/java/VulnerableJava.java
行号: 31
CWE: CWE-78
国标映射: GB/T34944-6.2.3.3 命令注入；GB/T39412-6.1.1.6 命令行注入  ◀ 【双国标】
来源: llm_audit
语言: java
问题代码: Runtime.getRuntime().exec(command);
问题描述: 描述内容（2-3句话）
修复方案: 修复内容（≥30字，含具体代码/命令/API）

> 国标映射格式：
> - 有专用标准的语言（Java/C/C++/C#）：双映射，格式 {专用标准}；GB/T39412-{规则}
> - 无专用标准的语言（Python/Go/JS/PHP/Rust等）：单映射，格式 GB/T39412-{规则}
> - 分隔符使用中文分号 ；
> - GB/T 39412-2020 是通用标准，适用于所有语言

> 详细质量检查标准见 docs/workflow/quality_standards.md

🔴 禁止行为清单

> 详细禁止行为清单见 docs/workflow/quality_standards.md

> 详细流程和验证机制见 docs/workflow/audit_workflow.md

🔧 常见问题

> 详细问题解决方案见 docs/workflow/troubleshooting.md

🔧 外部工具集成

⚠️ 说明：外部工具集成仅用于快速扫描阶段，LLM审计不应依赖外部工具结果。

> 外部工具在快速扫描阶段自动调用，LLM审计应专注于语义分析和业务逻辑漏洞检测。

路线图

• Q2 2026: 支持更多语言（Go/PHP/JavaScript）
• Q3 2026: CI/CD 集成、Web UI
• Q4 2026: 多 LLM 模型支持