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 标准

🔧 三层审计分工明确

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

| 分工 | 负责方 | 发现的漏洞类型 | 检出率 | |------|--------|---------------|--------| | 快速扫描 | 代码（正则表达式） | 高风险函数调用 | ~64% | | LLM审计 | LLM（语义分析） | 需要上下文分析的漏洞 | ~61% | | LLM审查 | LLM（深入分析） | 复杂业务逻辑、漏洞验证 | 最高 |

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

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

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

特点：

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

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

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

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

特点：

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

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

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

特点：

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

代码负责（格式验证）

| 验证项 | 说明 | 工具函数 | |--------|------|---------| | 必填字段完整性 | baseline检查12个字段，LLM审计检查13个字段（含修复方案） | validate_required_fields() + LLM_REQUIRED_FIELDS | | 国标映射格式 | 检查国标映射格式是否正确 | validate_gbt_mapping() | | 代码片段/行号 | 验证代码片段和行号准确性，含自动修正 | validate_code_snippet() | | 问题描述格式 | 检查字数≥20，不重复代码片段 | validate_description_format() | | 修复方案格式 | 检查字数≥20 | validate_fix_format() |

代码特点：

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

LLM负责（语义质量）

| 质量项 | LLM判断要点 | 重要性 | |--------|------------|--------| | 问题描述内容 | 是否说明了漏洞原因、攻击方式、潜在风险 | 🔴 高 | | 修复方案内容 | 是否具体、合理、可行；是否包含代码示例或API建议 | 🔴 高 | | 严重等级 | 是否符合漏洞实际危害（考虑上下文、可利用性、影响范围） | 🟠 中 | | 误报判定 | 是否有安全防护、是否仅导入无调用、是否测试代码 | 🟠 中 |

LLM质量判断要求：

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

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

LLM责任：

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

代码辅助功能：

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

工作流程：

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

违反后果：

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

🚀 LLM 审计优势发挥

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

| 优势 | 说明 | 检查方法 | |------|------|----------| | 语义理解 | 理解代码意图，不只是模式匹配 | 分析变量用途、函数语义 | | 跨文件调用链 | 追踪数据流和控制流跨多个文件 | Grep 搜索调用点，Read 查看上下文 | | 业务逻辑漏洞 | 理解业务场景发现逻辑缺陷 | 分析认证流程、权限判断、状态转换 | | 上下文关联 | 关联变量、函数、类之间的关系 | 分析数据来源、传递路径、使用场景 | | 组合漏洞 | 发现多个弱点组合形成攻击链 | 分析：注入 + 权限绕过 + 信息泄露 | | 定制风险 | 根据项目特点发现特定安全问题 | 分析框架特性、API 设计、配置风险 |

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

业务逻辑缺陷
- 认证绕过：密码重置流程漏洞、会话管理缺陷
- 权限问题：水平/垂直越权、缺失权限检查
- 状态篡改：订单状态绕过、支付流程漏洞
数据流安全问题
- 用户输入从 A 文件传递到 B 文件的危险函数
- 敏感数据从存储到展示的泄露路径
- 配置数据影响多个模块的安全风险
组合攻击链
- 信息泄露 + 身份伪造 → 账户接管
- SSRF + 内网访问 → 权限提升
- 路径遍历 + 文件上传 → RCE

审计检查技巧：

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

⚠️ LLM 审计强制要求

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

LLM 审计执行指南 - 包含：
- 漏洞类型检查清单（严重/高危/中危）
- 分层审计策略（四轮审计流程）
- 语言特定审计指导（Python/Java/C++/C#）
- 审计执行检查清单（逐项确认）
- 行号验证流程和防幻觉机制
输出质量检查标准 - 包含：
- 🔴 质量检查清单（创建 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 返回的精确行号
禁止凭记忆填写
禁止根据函数名推断行号

❌ 常见错误示例

| 错误类型 | 错误示例 | 正确做法 | |---------|---------|---------| | 凭记忆填写 | 行号: 164（实际在185） | 使用 Grep 验证后填写 | | 关键词推断 | 根据函数名推断位置 | 使用 Grep 精确搜索 | | 注释行号 | 行号指向注释而非代码 | 确认行号对应实际代码 |

⚠️ 验证逻辑的局限性

finalize_report 的验证逻辑使用关键词匹配：

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

错误修正示例：

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

✅ 正确流程

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

�📋 执行前必知

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

语言与标准对应关系

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

| 语言类型 | 适用标准 | 映射格式 | |----------|----------|----------| | 有专用标准（双映射） | 专用标准 + GB/T 39412-2020 | GB/T349XX-规则；GB/T39412-规则 | | Java | GB/T 34944-2017 + GB/T 39412-2020 | GB/T34944-6.2.3.3；GB/T39412-6.1.1.6 | | C/C++ | GB/T 34943-2017 + GB/T 39412-2020 | GB/T34943-6.2.3.6；GB/T39412-8.2.6 | | C# | GB/T 34946-2017 + GB/T 39412-2020 | GB/T34946-6.2.3.3；GB/T39412-6.1.1.6 | | 无专用标准（单映射） | 仅 GB/T 39412-2020 | GB/T39412-规则 | | 其他语言 | GB/T 39412-2020 | GB/T39412-{适用规则} |

详细规则见国标文件：

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 - 创建目录

学习内容

| 文档 | 学习要点 | |------|---------| | audit_workflow.md | 四轮审计流程、漏洞类型清单、行号验证方法 | | quality_standards.md | 质量检查清单、修复方案要求、禁止行为 | | 国标规则文件 | 根据语言选择对应国标，学习规则编号和描述 |

审计流程

┌─────────────────────────────────────────────────────────────────────┐
│                        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

分批策略：

| 策略 | 说明 | 适用场景 | |------|------|----------| | 按数量分批 | 每批 20-30 个文件 | 通用场景 | | 按语言分批 | 每个 agent 处理一种语言 | 多语言项目 | | 按漏洞类型分批 | 每个 agent 处理一类漏洞 | 漏洞类型集中 |

并行处理要求：

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

状态判定规则

| 判定规则 | 特征 | 状态 | 示例 | |---------|------|------|------| | 仅导入语句 | 只有 import/using，无实际调用 | 误报 | import subprocess 但未使用 | | 测试/演示代码 | 位于 test/demo 目录或含测试注解 | 误报 | @Test, def test_xxx() | | 安全的使用方式 | 有 sanitization/白名单校验 | 误报 | 参数经白名单过滤后的 exec | | 实际危险调用 | 直接使用危险 API 无防护 | 有效 | Runtime.exec(userInput) | | 硬编码密码 | 密码/密钥直接写在代码中 | 有效 | password = "admin123" | | 弱加密算法 | 使用 DES/MD5/SHA1 等 | 有效 | Cipher.getInstance("DES") |

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

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

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

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

| 检查项 | 工具 | 说明 | |--------|------|------| | 本文件上下文 | Read | 读取发现行前后 10 行 | | 跨文件调用 | Grep | 搜索项目范围内的实际调用 |

两项检查都必须执行：

本文件检查：Read 读取发现所在文件，检查前后 10 行上下文
- 判断是否仅导入语句
- 判断是否在测试/辅助函数中
- 判断是否有安全防护代码
跨文件检查：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 负责：

| 质量项 | LLM 判断要点 | |--------|--------------| | 问题描述 | 是否说明了漏洞原因、攻击方式、潜在风险 | | 修复方案 | 是否具体、合理、可行；是否包含代码示例或 API 建议 | | 严重等级 | 是否符合漏洞实际危害（考虑上下文、可利用性、影响范围） | | 误报判定 | 是否有安全防护、是否仅导入无调用、是否测试代码 |

问题描述要求：

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

修复方案要求：

提供具体修复方法（如：使用 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：生成报告（只包含"有效"状态的发现）                              │
└─────────────────────────────────────────────────────────────────────┘

验证环节

| 验证项 | 说明 | 结果 | |--------|------|------| | 去重处理 | 按 file:line:type 去重，LLM 审计优先 | 去重后的发现列表 | | 重复标记 | 被丢弃的 md 文件状态设为"重复" | 重复列表 | | 验证范围 | 只验证状态为"误报"的发现 | 待验证列表 | | 代码片段验证 | 验证代码片段是否存在于文件中 | 通过/失败 | | 行号修正 | 如果行号不准确，修正为正确行号 | 修正后的行号 | | 状态更新 | 验证通过 → 状态设为"有效" | 有效/幻觉 | | 幻觉记录 | 验证失败的发现记录为幻觉 | 幻觉列表 |

报告内容

⚠️ 报告的明细和统计只针对状态为"有效"的 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无权限验证
- 子进程敏感资源：检查文件打开后启动子进程

📊 覆盖度检查

必须达到的覆盖目标：

| 漏洞类型 | 目标覆盖 | 检查方法 | |---------|---------|---------| | 严重漏洞 | 100% | 检查清单中所有严重漏洞类型都已审计 | | 高危漏洞 | 100% | 检查清单中所有高危漏洞类型都已审计 | | 语言覆盖 | 100% | 所有检测到的语言都已审计 | | 文件覆盖 | 100% | 必须审计全部代码文件，不得遗漏任何文件 |

⚠️ 质量检查

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

🚫 禁止行为检查

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

✅ 审计完成确认

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

工具列表

| 工具 | 描述 | 命令 | |------|------|------| | quick_scan | 快速扫描：正则 + Bandit/Semgrep/Gitleaks | python scripts/skill.py quick_scan --target <target> | | finalize_report | 收尾报告：去重 + 验证 + 生成 | python scripts/skill.py finalize_report [--output=...] |

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

🔧 常见问题

| 问题 | 解决方案 | |------|----------| | md 文件无法解析 | 使用英文冒号 : | | 多值参数解析错误 | 多值参数用空格分隔 --languages java python | | LLM 审计发现被过滤 | 使用 Grep 工具验证行号 |

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

🔧 外部工具集成

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

| 工具 | 用途 | 集成方式 | |------|------|----------| | Gitleaks | 密钥/凭证检测 | 自动调用 | | Bandit | Python 安全分析 | 自动调用 | | Semgrep | 多语言模式匹配 | 自动调用 |

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

路线图

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

gbt-code-audit

代码安全审计技能

📋 概述

🎯 审计原则

🔧 三层审计分工明确

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

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

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

代码负责（格式验证）

LLM负责（语义质量）

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

🚀 LLM 审计优势发挥

⚠️ LLM 审计强制要求

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

必须执行的验证步骤

❌ 常见错误示例

⚠️ 验证逻辑的局限性

✅ 正确流程

�📋 执行前必知

语言与标准对应关系

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

确认输出格式

学习内容

审计流程

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

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

步骤 5 流程

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

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

状态判定规则

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

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

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

md 文件格式

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

处理流程

验证环节

报告内容

执行方式

输出信息

步骤 7：审计完成

输出内容

审计完成确认

LLM 审计执行检查清单

📋 审计前准备

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

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

🔄 第三轮：业务逻辑审计

🔄 第四轮：组合漏洞分析

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

📊 覆盖度检查

⚠️ 质量检查

🚫 禁止行为检查

✅ 审计完成确认

工具列表

Markdown 文件格式

🔴 禁止行为清单

🔧 常见问题

🔧 外部工具集成

路线图