文章总结： 本文介绍了一个基于ClaudeCode的代码审计Skill的设计思路与实战效果。该系统采用五阶段审计模型（侦察、自由审计、覆盖率自检、深度验证、报告生成），通过多智能体并行执行、防幻觉规则和增量补漏策略，在20万行Java项目中发现63个漏洞。关键机制包括攻击链思维、跨轮传递结构和Agent合约约束，强调宁可漏报不可误报的原则。 综合评分： 92 文章分类： 代码审计,漏洞分析,安全工具,安全开发,AI安全

---

我用 Claude Code 造了一个代码审计 Skill，它在 20 万行项目中找到了 63 个漏洞

三石随笔录

2026年2月10日 17:53 北京

在小说阅读器读本章

去阅读

——code-audit skill 的设计思路、核心架构与实战验证

这不是一篇 prompt 教程，而是一个完整的「AI 安全审计系统」的设计复盘。 从防幻觉到多智能体协作，从覆盖率矩阵到增量补漏，每一个机制都来自真实项目中踩过的坑。

---

一、背景：为什么要做一个审计 Skill？

用大模型做代码审计，最直觉的方式是：

"帮我审计这个项目的安全漏洞"

这在小项目上偶尔有效，但在真实的工程项目中几乎不可用。原因很简单：

代码审计不是搜索，而是决策。

一个 20 万行的 Java 项目，有上百个 Controller、几十个数据源、复杂的认证链路。模型不知道该先看什么，不知道该看多深，不知道什么时候该停。更致命的是——它会「幻觉」：报告一个根本不存在的文件中的漏洞，或者编造一段从未出现过的代码。

过去一年多，我一直在用 Claude Code 做安全审计，从单轮对话到多轮追踪，从手动引导到半自动化。过程中积累了大量关于「模型在审计场景下如何出错」和「如何让模型不出错」的经验。

最终，我把这些经验沉淀为一个 Claude Code Skill——code-audit。

它不是一个简单的 prompt 模板，而是一套包含执行状态机、多智能体协作、防幻觉规则、增量补漏策略、覆盖率自检的完整审计系统。

当前版本 v4.5.3，经过某大型开源 Java 项目（20 万行 BI 数据平台）的实战验证：2 轮 8 个智能体、165 次工具调用，发现 63 个独立漏洞（12 Critical、19 High），10 个安全维度全覆盖。

这篇文章完整介绍这个 Skill 的设计思路和核心机制。

---

二、核心设计哲学

在写第一行 Skill 指令之前，我花了很多时间思考一个问题：

AI 做代码审计，最容易犯什么错？

答案是两个字：幻觉。

2.1 防幻觉：宁可漏报，不可误报

这是整个 Skill 的第一原则。具体体现为三条硬性规则：

✗ 禁止猜测文件路径——必须用 Glob/Read 验证文件存在
✗ 禁止编造代码片段——必须引用 Read 工具实际输出的代码
✗ 禁止报告未读文件中的漏洞——没有读过的代码不能出现在报告中

这三条规则看起来很基础，但在没有约束的情况下，模型犯这类错误的频率远超想象。特别是在多智能体场景下，一个 Agent 可能基于另一个 Agent 的摘要去「推断」某个文件的内容——这是幻觉的温床。

核心原则：宁可漏掉一个真实漏洞，也不报告一个虚假漏洞。

误报对安全审计的伤害远大于漏报。一份充满误报的报告会让开发团队丧失信任，而漏报可以通过多轮审计逐步弥补。

2.2 反确认偏见：方法论驱动，而非经验驱动

另一个容易出现的问题是确认偏见。模型读了几个文件后，会倾向于「证实」自己已有的判断，而不是系统性地检查所有可能。

✗ 禁止 "基于之前的审计经验，我将重点关注..."
✗ 禁止因为某个漏洞类型"看起来不太可能"就跳过检查
✓ 必须枚举所有敏感操作，然后逐一验证
✓ 必须完成完整的检查清单，对每个维度一视同仁

2.3 攻击链思维：漏洞不是孤岛

单个 Medium 级别的漏洞可能无关紧要，但当它与另一个 Medium 组合时，可能变成 Critical。

认证绕过(H) + 需认证的 SSRF(M) = 未认证 SSRF(C)
信息泄露(L) + 密码重置逻辑缺陷(M) = 账户接管(C)

Skill 要求每发现一个漏洞，都要评估它与已有发现的组合可能性。最终报告中会专门有一个「攻击链分析」章节，展示多漏洞串联的端到端攻击路径。

---

三、审计架构：五阶段模型

整个审计流程分为五个阶段：

Phase 1: Reconnaissance（侦察）
    ↓
Phase 2A: Vulnerability Hunt（自由审计）
    ↓
Phase 2B: Coverage Verification（覆盖率自检）
    ↓
Phase 3: Deep Dive（深度验证）
    ↓
Phase 4: Report（报告生成）

Phase 1：侦察

不急着找漏洞，先画地图。

这个阶段做的事情非常明确：

1. 1. 识别技术栈 — 语言、框架版本、数据库、中间件
2. 2. 枚举攻击面 — 有多少 API 端点？有哪些数据源？认证链路怎么走？
3. 3. 发现功能模块 — 文件上传、数据导出、数据源管理、用户管理…
4. 4. 确定审计维度 — 哪些安全维度需要重点关注？

以某 Java BI 平台项目为例，Phase 1 识别出：

| 发现 | 详情 | | — | — | | 技术栈 | Spring Boot 3.x + Java 21 + MyBatis-Plus + 嵌入式数据库 | | 入口点 | 40+ API Controllers, 分布在 core/sdk/extensions 三层 | | 高风险模块 | 数据源管理（JDBC URL 可控）、文件上传、JWT 认证 | | 激活维度 | D1-D10 全部激活（数据平台 → D1 SQL 注入权重 ++，D6 SSRF 权重 ++） |

Phase 1 的输出直接决定后续 Agent 的数量和方向划分。攻击面决定 Agent 结构，不是模板决定。

Phase 2A：自由审计 + 多智能体并行

这是核心阶段。多个 Agent 并行执行，每个 Agent 负责 1-3 个安全维度。

Skill 不预设固定的 Agent 模板，而是根据 Phase 1 的攻击面分析动态决定：

该项目的 R1 Agent 划分（基于攻击面分析动态生成）:
Agent 1: SQL/SpEL 注入 (D1) — 追踪用户输入到 SQL Sink
Agent 2: 认证+授权+业务逻辑 (D2+D3+D9) — JWT/Filter/权限/IDOR
Agent 3: 文件操作+SSRF (D5+D6) — 上传下载/路径遍历/JDBC URL
Agent 4: 反序列化+RCE (D4) — JAR 上传/类加载/反射调用
Agent 5: 配置+加密+依赖 (D7+D8+D10) — 硬编码密钥/暴露端点/CVE

5 个 Agent 并行执行，每个最多 25 个 turn，总共 125 个 turn 的搜索+分析能力。

Phase 2B：覆盖率自检

这是区别于其他 AI 审计工具的关键机制。

Phase 2A 完成后，不是直接出报告，而是用一个 10 维度覆盖率矩阵 做自检：

| # | 维度 | 关键问题 | | — | — | — | | D1 | 注入 | 用户输入是否能到达 SQL/Cmd/LDAP/SSTI 执行点？ | | D2 | 认证 | Token 生成、验证、过期是否完整？ | | D3 | 授权 | 每个敏感操作是否验证用户归属？ | | D4 | 反序列化 | 是否存在不受信数据的反序列化？ | | D5 | 文件操作 | 上传/下载路径是否可控？ | | D6 | SSRF | 服务端 HTTP 请求的 URL 是否用户可控？ | | D7 | 加密 | 硬编码密钥？弱算法？ | | D8 | 配置 | 调试接口暴露？CORS 过宽？ | | D9 | 业务逻辑 | 竞态条件？流程可跳过？ | | D10 | 供应链 | 依赖是否有已知 CVE？ |

每个维度标记为三种状态：

• • ✅ 已覆盖 — 有深度分析（读代码 + 追数据流）
• • ⚠️ 浅覆盖 — 仅 Grep 搜索过，未深入
• • ❌ 未覆盖 — 完全没有涉及

终止条件：覆盖率 ≥ 8/10 且 D1-D3 全部覆盖才能出报告。否则必须补充审计。

该项目 R1 的覆盖情况：8/10（D4 和 D9 未覆盖）→ 触发 R2。

---

四、增量补漏：R2 不重复 R1

这是 Skill 中我花了最多时间优化的部分。

4.1 问题：多轮审计的 Token 浪费

早期的多轮审计策略很粗暴——R2 重新来一遍，只是换个方向。结果：

• • R2 重复搜索 R1 已确认干净的方向（~30% 浪费）
• • R2 重复读取 R1 已读过的文件（~20% 浪费）
• • R2 Agent 数量不随缺口递减（~15% 浪费）

2.5 倍的 Token 消耗，只多发现了 46% 的漏洞。

4.2 解决方案：跨轮传递结构

R1 完成后，主线程会产出一个结构化的「跨轮传递结构」：

COVERED:  D1(✅ 10个发现), D2(✅ 6个), D3(✅ 14个), D5(✅ 4个), ...
GAPS:     D4(❌ 未覆盖), D9(❌ 未覆盖), D1(⚠️ SQL查询构建层未深入)
CLEAN:    [JNDI/XXE/Fastjson — 已搜索确认不存在的攻击面]
HOTSPOTS: [QueryBuilder.java:135 — 字符替换未追踪, PermissionManager.java — 鉴权逻辑待验证]
FILES_READ: [TokenUtils.java:JWT decode无verify, CryptoUtils.java:硬编码AES密钥, ...]
GREP_DONE: [JWT.decode, @Permission, CREATE ALIAS, loadRemoteFile, ...]

这个结构被注入到每个 R2 Agent 的 prompt 中，带有明确的约束：

• • 禁止重读 FILES_READ 中已分析过的文件
• • 禁止重复 GREP_DONE 中已执行过的搜索模式
• • 直接跳过 CLEAN 中已确认不存在的攻击面
• • 优先深入 HOTSPOTS 中 R1 发现但未展开的高风险点

4.3 R2 Agent 数量自适应

R2 不再固定数量，而是由缺口数精确计算：

| 缺口状态 | R2 Agent 数量 | | — | — | | ❌ 未覆盖 0-1 个 | 1 Agent (20 turns) | | ❌ 未覆盖 2-3 个 | 2 Agent (2×20 turns) | | ❌ 未覆盖 4+ 个 | 3 Agent (3×20 turns) |

该项目 R2：D4 和 D9 未覆盖 + SQL 查询构建层浅覆盖 → 3 个 Agent，总共 60 turns。

效果：R1 的 1.5 倍 Token 成本（而非 2.5 倍），覆盖率从 8/10 提升到 10/10，新增发现 12 个（含 4 个 Critical）。

---

五、Agent 合约：让每个智能体可控

多智能体最大的挑战不是「如何启动」，而是「如何约束」。

没有约束的 Agent 会做各种低效的事情：用 Bash 里的 grep 替代 Grep 工具（性能退化 10-100 倍）、一次性读取整个 3000 行的文件、在最后几个 turn 还在开启新的搜索方向导致输出被截断…

Skill 定义了一套 Agent 合约（Agent Contract），每个 Agent 启动前自动注入：

---Agent Contract---
1. 搜索路径: {paths}。排除: node_modules, .git, build, test, frontend
2. 必须使用 Grep/Glob/Read 工具。禁止 Bash 中 grep/find/cat。
3. 工具调用 ≤50 次，Bash ≤10 次。max_turns: {N}。
4. ★ Turn 预留: turns_used ≥ max_turns-3 时立即停止探索，产出结构化输出。
5. 搜索策略: Grep 定位行号 → Read offset/limit 读上下文（±20行）。
6. 输出: 按结构化模板返回。禁止返回大段原始代码（>3行）。
7. 同类漏洞 ≥5 个合并报告。同 pattern 多文件列清单不逐个深挖。
8. Sink 类别上界: 每维度最多 8 个 Sink 类别，每类最多深追 3 个实例。
9. 数据转换管道追踪: Source → [Transform₁ → ... → Transformₙ] → Sink。
10. ★ 截断防御: HEADER 在最前（≤400字），AGENT_OUTPUT_END 在最后。
---End Contract---

几个关键设计：

5.1 Turn 预留规则

Agent 必须在倒数第 3 个 turn 停止探索，开始输出结构化结果。这个规则看起来简单，但解决了一个非常痛苦的问题：

Agent 在最后一个 turn 还在 Grep 新方向 → turn 耗尽 → 输出被截断 → 整个 Agent 的发现丢失。

5.2 截断防御

输出格式强制要求 HEADER 放在最前面（包含覆盖率、统计信息、传递数据），SENTINEL 哨兵放在最后。

如果主线程检测到哨兵丢失 → 说明输出被截断 → 但 HEADER 大概率还在 → 至少 R2 决策所需的元数据不会丢失。

5.3 数据转换管道追踪

这是我在实际审计中学到的重要经验。很多注入漏洞不是 Controller → DAO 的直线传播，而是经过了 Builder、Provider、Manager 等中间层：

Controller.bindData()
  → DataService.buildQuery()
    → QueryProvider.buildSQL()
      → String.format("SELECT %s FROM %s", fields, tableName)  // SQL 注入！

如果只看 Controller 和 DAO，会漏掉中间层的注入点。合约要求 Agent 对每个 Sink 至少追踪 3 层调用链。

---

六、两层检查清单：Checklist 不驱动审计

很多安全工具的做法是：给一个检查清单，逐项执行。

我的设计理念正好相反：Checklist 不驱动审计，而是验证覆盖。

LLM 先自由审计（Phase 2A）→ 再用矩阵查漏（Phase 2B）

为什么？

因为 LLM 的优势在于联想和推理。一个训练良好的模型看到 JWT.decode() 时，不需要 checklist 告诉它这是个问题。过度依赖 checklist 反而会限制模型的探索能力，把它降级成一个模式匹配引擎。

所以 Skill 采用两层设计：

Layer 1：覆盖率矩阵（Phase 2B 加载）

• • 10 个安全维度的覆盖率检查
• • 用于验证 Phase 2A 是否有遗漏
• • 不含具体检测规则

Layer 2：语言语义提示（仅对未覆盖维度按需加载）

• • 9 种语言各自独立的语义提示文件
• • 每个维度的关键问题和搜索模式
• • 只有 Phase 2B 发现某维度未覆盖时才加载对应段落

这样做的好处：

1. 1. 不浪费 Token — 已覆盖的维度不加载 checklist
2. 2. 不限制模型 — 自由审计阶段不受 checklist 束缚
3. 3. 不遗漏维度 — 覆盖率矩阵确保每个方向都被检查过

---

七、实战案例：某大型 Java BI 平台审计全记录

以下案例来自对某开源 BI 数据可视化平台的真实审计，项目名称和部分细节已脱敏。

7.1 项目概况

| 指标 | 数据 | | — | — | | 项目 | 某开源 BI 数据可视化平台 | | 代码量 | ~200K 行 Java | | 技术栈 | Spring Boot 3.x + Java 21 + MyBatis-Plus + 嵌入式数据库 | | 模块结构 | core-backend + sdk-common + extensions (多数据源插件) | | 审计模式 | Standard（2 轮） |

7.2 审计执行过程

Round 1（侦察 + 广度扫描）

| Agent | 方向 | max_turns | 发现数 | | — | — | — | — | | Agent 1 | SQL/SpEL 注入 (D1) | 25 | 8 | | Agent 2 | 认证+授权 (D2+D3) | 25 | 16 | | Agent 3 | 文件+SSRF (D5+D6) | 25 | 6 | | Agent 4 | 反序列化+RCE (D4+D5) | 25 | 10 | | Agent 5 | 配置+加密+依赖 (D7+D8+D10) | 25 | 11 | | R1 合计 | | 125 turns | 51 findings |

R1 覆盖率评估：8/10（D4 反序列化 ❌、D9 业务逻辑 ❌）

Round 2（增量补漏 + 深度追踪）

| Agent | 方向 | max_turns | 新发现 | | — | — | — | — | | R2-Agent 1 | D4+D9（未覆盖维度） | 20 | 4 | | R2-Agent 2 | 权限注解 AOP + SQL 查询构建层（浅覆盖加深） | 20 | 5 | | R2-Agent 3 | 跨模块攻击链验证 | 20 | 3 | | R2 合计 | | 60 turns | 12 findings |

R2 覆盖率：10/10 ✅

审计总计：2 轮 × 8 个 Agent = 63 个漏洞，165 个 turns。

7.3 关键发现一览

12 个 Critical 漏洞：

| # | 漏洞类型 | CVSS | 核心问题 | | — | — | — | — | | C-01 | JWT 签名验证完全缺失 | 9.1 | JWT.decode() 无 verify()，可伪造任意用户 | | C-02 | 权限注解无 AOP 实现 | 9.8 | 社区版鉴权函数永远返回 true | | C-03 | 嵌入式数据库存储过程 RCE | 9.0 | JDBC URL 注入 → 执行任意 Java 代码 | | C-04 | SQL 查询构建层 9+ 注入点 | 8.8 | String.format() 拼接表名/字段名 | | C-05 | JDBC 连接参数反序列化 | 8.6 | 连接参数绕过黑名单触发反序列化 | | … | (共 12 个 Critical) | | |

Top 3 攻击链：

Chain 1: JWT Forge → 数据源注入 → RCE (CVSS 9.8, 无需认证)
  伪造管理员 JWT → 添加恶意数据源 → 通过存储过程执行系统命令

Chain 2: JWT Forge → IDOR → 全库数据泄露 (CVSS 9.1, 无需认证)
  伪造任意用户 JWT → 枚举资源 ID → 导出所有业务数据

Chain 3: SSRF → Cloud Metadata → IAM 凭证窃取 (CVSS 8.6)
  通过外部数据导入 URL → 请求云元数据服务 → 获取云平台凭证

7.4 R2 的关键贡献

如果只做 R1，会漏掉什么？

R2 发现了 4 个 Critical 级别的漏洞，这些漏洞是 R1 完全没有触及的：

1. 1. 权限注解无 AOP 实现 — R1 看到了自定义权限注解被广泛使用，但没有追踪其实现。R2 深入发现社区版的鉴权函数永远返回 true，意味着所有标注了该注解的端点实际上没有任何权限控制。这是一个典型的「代码缺失」型漏洞——不是代码写错了，而是关键实现根本不存在。
2. 2. SQL 查询构建层注入 — R1 扫描了常见的 MyBatis SQL 注入模式（${} 等），但该项目的查询构建层使用的是 String.format() 拼接，不在 MyBatis 的 Sink 模式中。R2 追踪了数据转换管道：Controller → Service → QueryProvider.buildSQL() → 发现 9+ 个注入点。
3. 3. HashMap 并发竞态 — R1 没有覆盖 D9 业务逻辑维度。R2 发现导出任务使用非线程安全的 HashMap 存储状态，存在 TOCTOU 竞态。
4. 4. Mass Assignment — R2 追踪用户资料编辑 API，发现直接将请求体绑定到实体对象，无字段白名单，可修改 roleId 等敏感字段。

这证明了增量补漏策略的价值：R2 的 60 个 turns（不到 R1 的一半）产出了 4 个 R1 完全遗漏的 Critical 漏洞。

---

八、四个扫描模式

Skill 支持四种模式，适应不同场景：

| 模式 | 适用场景 | 轮次 | Agent 数 | 特点 | | — | — | — | — | — | | Quick | CI/CD 集成、小项目 | 1 轮 | 2-3 | 高风险漏洞 + 密钥泄露 + 依赖 CVE | | Quick-Diff | PR 审查、增量提交 | 1 轮 | 1-2 | 只审计 git diff 变更的文件 | | Standard | 常规安全审计 | 1-2 轮 | 3-9 | OWASP Top 10 完整覆盖 | | Deep | 关键系统、渗透测试前 | 2-4 轮 | 5-15 | 全量覆盖 + 攻击链 + 业务逻辑 |

Quick-Diff 模式特别适合集成到开发流程中。它只读取 git diff 涉及的文件，追踪变更代码的安全影响，通常在几分钟内完成。

---

九、模块化知识库

Skill 的知识不是全部写在一个文件里的。它采用模块化设计，按需加载：

核心模块（始终可用）

| 模块 | 功能 | | — | — | | Anti-Hallucination | 防幻觉规则和验证流程 | | Taint Analysis | 污点分析和数据流追踪模板 | | PoC Generation | 验证模板生成 | | Capability Baseline | 防止能力退化的回归测试框架 |

语言模块（按技术栈加载）

9 种语言各有独立的检测规则文件：Java、Python、Go、PHP、JavaScript/Node.js、C/C++、.NET/C#、Ruby、Rust。

每个语言模块包含 D1-D10 十个维度的语义提示，不是通用的检测规则，而是该语言特有的危险模式。比如 Java 的 Runtime.exec() vs Python 的 subprocess.Popen() vs Go 的 os/exec.Command()。

安全域模块（按需加载）

| 模块 | 加载时机 | | — | — | | API Security | 项目有 REST/GraphQL API | | LLM Security | 项目集成了 AI/ML | | Race Conditions | 有并发操作场景 | | Cryptography | 有加密/签名/JWT 操作 |

---

十、置信度分级：Critical/High 必须有数据流

Skill 对发现的置信度有严格的分级标准：

| 等级 | 条件 | 可报告的最高严重度 | | — | — | — | | 已验证 | 完整数据流 + 无有效防护 + 可构造 PoC | Critical | | 高置信 | 完整数据流 + 无有效防护，但 PoC 需特定环境 | Critical/High | | 中置信 | 数据流不完整，或防护可绕过性不确定 | Medium | | 需验证 | 仅 Grep 命中模式，未追踪数据流 | Low/Info |

硬性规则：Critical 和 High 级别的漏洞必须达到「高置信」或「已验证」。

这意味着每个高危漏洞都要追踪完整的数据流：Source → [Transform₁ → ... → Transformₙ] → Sink，确认传播路径上没有有效的净化或过滤。

---

十一、执行状态机：从侦察到报告的完整流转

整个审计过程由一个四状态执行状态机驱动：

PHASE_1_RECON
    │ Phase 1 完成
    ▼
ROUND_N_RUNNING    ◄──────────────────────────┐
    │ 所有 Agent 完成                          │
    ▼                                         │
ROUND_N_EVALUATION                            │
    │                                         │
    ├── 覆盖率不足 → NEXT_ROUND ─────────────►│
    │
    └── 覆盖率达标 + 弹性终止条件满足
            │
            ▼
         REPORT

弹性终止条件（三问法则）：

1. 1. 是否还有 Critical/High 维度未覆盖？ → 有则继续
2. 2. 下一轮预期能发现什么？ → 仅 Low/Info 则可停止
3. 3. Token 效率如何？ → 预期发现/turn < 0.1 则停止

这个状态机确保审计不会因为「看起来差不多了」而过早终止，也不会因为「也许还能找到更多」而无限循环。

---

十二、Skill 迭代中踩过的坑

坑 1：Agent 输出被截断，发现全部丢失

早期没有截断防御机制，Agent 在最后一个 turn 还在做 Grep → 输出超长 → 被截断 → HEADER 和发现表格全部丢失 → 主线程拿到空结果。

修复：Turn 预留规则 + HEADER 前置 + SENTINEL 哨兵 + 截断检测与恢复流程。

坑 2：R2 重复 R1 的工作

R2 Agent 不知道 R1 做了什么，重新搜索相同的模式、重读相同的文件。

修复：跨轮传递结构（COVERED/GAPS/CLEAN/HOTSPOTS/FILES_READ/GREP_DONE）。

坑 3：幻觉漏洞

Agent 报告了一个文件中的漏洞，但那个文件路径是错的（基于「典型 Spring Boot 项目结构」猜测的）。

修复：三条防幻觉硬规则 + 每个发现必须有 Read 工具实际输出的代码作为证据。

坑 4：确认偏见

模型在 D1（注入）维度找到了很多发现后，倾向于把更多精力投入 D1，而忽略其他维度。

修复：覆盖率矩阵强制自检 + Sink 类别上界（每维度最多 8 个 Sink 类别）。

坑 5：Skill 文档本身的冗余和矛盾

随着功能迭代，agent.md 出现了同一规则在两处完整定义、被废弃的决策树没有删除等问题。

修复：制定了 Skill 文档编写防坑指南（单一权威来源、环境感知、异常路径完整性、层级标注、模板即合约）。

---

十三、与传统 SAST 工具的对比

| 维度 | 传统 SAST (Semgrep/SonarQube) | code-audit Skill | | — | — | — | | 检测方式 | 固定规则模式匹配 | LLM 语义理解 + 数据流追踪 | | 数据流追踪 | 有限（通常 1-2 跳） | 深度（3+ 跳，含中间转换层） | | 业务逻辑漏洞 | 几乎无法检测 | 可检测（D9 维度） | | 误报率 | 较高（20-40%） | 较低（防幻觉规则约束） | | 攻击链分析 | 无 | 支持多漏洞串联分析 | | 上下文理解 | 无（逐文件扫描） | 有（跨文件、跨模块推理） | | 可解释性 | 规则 ID + 代码位置 | 完整数据流 + 利用路径 + PoC | | 运行成本 | 低（本地执行） | 较高（LLM API 调用） | | 新漏洞模式 | 需手动添加规则 | 可基于代码上下文推理发现 |

两者不是替代关系，而是互补。Skill 在 Phase 1 如果检测到 Semgrep 可用，会先跑一遍 Semgrep 作为基线，然后在此基础上做深度分析。

---

十四、总结与展望

code-audit Skill 不是一个 prompt template，而是一个完整的审计系统。它的核心创新在于：

1. 1. 防幻觉优先 — 宁可漏报不可误报，每个发现必须有代码证据
2. 2. 覆盖率驱动 — 10 维度矩阵确保不遗漏任何安全方向
3. 3. 增量补漏 — R2 只补缺口不重复，Token 效率提升 40%+
4. 4. Agent 合约 — 结构化约束让多智能体行为可控可预测
5. 5. 截断防御 — HEADER 前置 + 哨兵机制确保关键数据不丢失
6. 6. 攻击链思维 — 不只找单点漏洞，还分析多漏洞组合的端到端攻击路径

在 20 万行 Java 项目上的实战验证了这套系统的有效性：63 个漏洞、10/10 维度覆盖、5 条端到端攻击链。其中 R2 以不到 R1 一半的 Token 成本，发现了 4 个 R1 完全遗漏的 Critical 漏洞。

下一步计划：

• • Docker 沙箱验证 — 对高危漏洞自动生成 PoC 并在隔离环境中验证（v4.5.0 已支持框架）
• • Quick-Diff 集成 — 接入 CI/CD 流水线，每次 PR 自动做增量安全审查
• • 能力回归测试 — 用历史审计结果作为 benchmark，确保 Skill 迭代不退化

工具在进化，但安全审计的本质没有变：系统性地发现所有可能的攻击路径，并证明它们是否可被利用。 code-audit Skill 做的事情，是让 AI 不只是「看代码」，而是参与这个决策过程。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：三石随笔录 《我用 Claude Code 造了一个代码审计 Skill，它在 20 万行项目中找到了 63 个漏洞》