又一个顶级 skill：让 Claude 帮你做 Java 代码安全审计，效果很强！

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/java-audit-skills-claude-code-codex/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

先说一个扎心的现实

手工审一个老 Java 项目，第一步永远是梳理路由。Controller 散落在十几个包里，有的还在 Struts 2，有的混着自定义 Servlet，光把接口捋全就得花不少时间，还容易漏。

漏洞分析更麻烦。一个参数传进去，你不知道它最后流向哪层 DAO，也不知道中间有没有 SQL 拼接，只能一层层手动追。三层跟下来脑子就乱了，换个人接手更难。

于是很多人转身去问 AI。可它给的答案常常看着像那么回事，你却没法确认那个漏洞到底能不能真打。直接让 Claude 扫一个 Java 项目，往往是一堆笼统建议，中间没有一道可验证的关口。

这个项目叫 audit-skills，在 GitHub 上攒了一千来个 Star，走的是另一条路。它不打算让 AI 去学安全，重点是把审计拆成一个个具体动作，并且给每个结论定死了证据标准。

仓库首页，右上角就能看到实时 Star 数

它其实只做五件事，但件件要做实

仓库的自我介绍写得很克制，一句话是「最小化轻量化 skill，只负责安全边界」。

翻到 README，它把自己限定在五件事上。一是默认输出目录约定，二是组件漏洞扫描，三是 Java 与 .NET 的语言参考加反编译反混淆，四是确定漏洞有效性，五是安全边界。

五件事里没有一件是「帮你批量找漏洞」，全都在给「让结论站得住」打地基。覆盖 Java、.NET 和 PHP 三种语言。

它到底帮你干什么，先说最实用的两件

第一件是把路由地图画出来。它能识别 Spring MVC、Servlet、JAX-RS、Struts 2、CXF 这几类主流框架，扫出来的结果除了路径，还有 HTTP 方法、参数结构（Path 变量、Query、Body、Header、Cookie 分得清清楚楚），并且直接生成 Burp Suite 的请求模板。

对没有 API 文档的老项目，这东西的价值一下就出来了。不用自己翻注解，跑一遍，清单就在眼前。

=== [1] 用户登录 ===
位置: UserController.login (UserController.java:45)
HTTP 方法: POST
URL 路径: /api/auth/login
参数结构: Body: LoginRequest (username, password)
Burp Suite 请求模板:
POST /api/auth/login HTTP/1.1
Host: {{host}}
Content-Type: application/json
{"username": "{{username}}", "password": "{{password}}"}

第二件更关键，是把调用链追到底。给它一条路由，它会把从 Controller 一路到 DAO 的调用链摊开，标出参数在每一层叫什么名字，最终流进了什么操作，是 SQL 查询、文件操作还是命令执行。

最有用的一个结论是参数可控性。它会明确告诉你这个参数是完全可控、条件可控还是不可控，而这直接决定漏洞能不能被实际利用。

除了这两件基础活，专项审计覆盖六类问题。SQL 注入看 JDBC、MyBatis、Hibernate 三种写法并给 PoC；鉴权分析 Spring Security、Shiro、JWT、Session，找绕过与越权；文件上传看类型校验缺失与路径穿越；文件读取看路径遍历；XXE 检查 XML 解析器有没有禁用外部实体；第三方依赖走组件扫描，Log4Shell、Spring4Shell、Shiro、Fastjson 都在规则里。

什么才算「确认漏洞」，它给了六条硬标准

这是整套东西最值钱的部分。

一个发现要写成「确认漏洞」，必须同时满足六条。可达，存在真实外部入口，比如 HTTP 路由、Servlet、Filter、RPC 或上传处理入口。可控，能指出用户可控参数、来源、绑定方式，以及它进入代码的准确位置。可传播，存在清晰的 source-to-sink 调用链，中途没被鉴权、校验、编码、白名单或类型约束挡住。可利用，这个 sink 在当前项目上下文里真能造成安全影响。可复现，必须有构造好的安全 Payload 和能直接粘进 BurpSuite Repeater 的原始请求包。影响成立，能说清触发之后到底产生越权、泄露还是绕过。

六条缺任何一条，都只能写成「高风险线索 / 待人工验证」。这条规矩看起来严，但它解决的就是开头那个问题，把「AI 觉得像」和「我能证明它是」分开。

每个确认漏洞还要把十几项写全，从标题、严重等级、受影响入口、鉴权要求，一直到用户可控输入、调用链、Sink、同源相似受影响路由、防护判断、安全 Payload、原始请求包、影响、证据文件与行号，最后还要写限制说明。

六条标准构成的一道闸门

组件漏洞先扫一遍，但命中只算线索

第三方组件是 Java 项目最容易出事的地方，这个技能把它做成了独立的一步。

规则集是一份 YAML，按严重等级分组维护组件名和版本正则，一共一百三十五条。Log4Shell 那条就在里面，匹配 log4j-core 2.0 到 2.14.1 这一段。扫描脚本会解析 Maven 与 Gradle 依赖文件、JAR 与 WAR 包、部署目录，再用这些正则匹配实际用到的版本。

用法有几种。想先确认规则文件没坏，跑 --validate-rules；日常直接对工作目录扫；指定扫描源就加 --source，源码目录、依赖目录、单个 jar 或 war、WEB-INF/lib 都能传，还能同时传多个；想换自己的规则，用 --rules 指过去。

但这里有一条限定必须记住。组件命中只能作为线索，不能仅凭组件名、版本或者 CVE 编号就把漏洞写成确认。你还得回去把入口、可控参数、传播链、可利用性、Payload 和请求包补齐，六条标准一条都不能省。

没有源码也能审

实战里经常拿不到源码，手上只有 .class 文件或者一个打好的 .jar。这个技能把反编译也纳入了流程。

Java 侧默认用 CFR 0.152。用法很直接，java -jar cfr-0.152.jar <目标> 加输出目录；WAR 包多给一个 --analyseas WAR；只想看某个包或类，用 --jarfilter 传正则聚焦。

策略写得很清楚，有源码就优先审源码，只有在只有 JAR、WAR、class 或关键代码缺失时才反编译。失败、部分成功或被跳过，都要记进 manifest。

纯 jar 包有一套推荐顺序，先用组件扫描把有问题的依赖列出来，再对这些组件相关的路由追调用链，流程照样跑得通。

.NET 那边给了单独一份参考，讲混淆识别、用 de4dot 反混淆、用 ilspycmd 反编译。PHP 没有专用参考文件，按同一套漏洞有效性和安全边界执行。

装它，Claude Code 和 Codex 各走各的门

前置只有两样。Java 运行环境，java -version 能跑就行；CFR 反编译器可以自己下，也可以不管，技能需要时会按需拉取。

安装就是把 skills/audit-skills/ 整个目录拷进宿主能识别的技能目录。Claude Code 的个人目录是 ~/.claude/skills/，项目级是 .claude/skills/；Codex 的个人目录是 ~/.agents/skills/，项目级是 .agents/skills/。注意 Codex 读的是 .agents，不是 .codex。

mkdir -p ~/.claude/skills ~/.agents/skills
cp -R skills/audit-skills ~/.claude/skills/
cp -R skills/audit-skills ~/.agents/skills/

调用方式也不一样。Claude Code 走斜杠，/audit-skills；Codex 走美元符号显式点名，$audit-skills，也可以用 /skills 看它当前发现了哪些技能。提问要给强指向性，直接说清要梳理路由还是要查 SQL 注入。

两种宿主的安装与调用对照

产出都放在一个工作目录里

跑起来之后，它会在目标目录下建一个 audit-workspace/。

临时脚本和中间结果进 script-output/，工具进 tools/，反编译和反混淆产物分别进 decompiled/ 与 deobfuscated/，证据进 evidence/。最终可交付的东西只写进 reports/，默认文件名是 audit-report.md。

这个约定看着琐碎，用处是复查时不用满仓库找证据。

想让多个 agent 一起干，两边的路子不一样

一次审计要覆盖路由、鉴权、组件、调用链、各类漏洞，单线程跑下来又慢又容易漏，所以两边都支持把活拆开并行。

Claude Code 这一侧可以直接用它的 Agent Teams。按审计阶段拆成几个 agent 并行跑，信息收集阶段三个 agent 同时开工，分别做路由分析、鉴权分析和组件扫描；后续阶段再依次做高危路由筛选、调用链追踪、漏洞深度分析和输出质量检查。每个阶段跑完还有一道质量校验，不合格就重做。这个能力目前还是实验性功能，用之前留意一下自己的版本。

Codex 这一侧走另一条路，官方 README 专门写了一节推荐用法。把 Codex 当编排器，先让它完整读一遍 SKILL.md、遵守其中对 claude CLI 的调用方式，再按漏洞类型把审计拆开，每一轮只让 claude 审一种，不许泛化到别的漏洞。每轮结果都要带上漏洞类型、风险等级、文件路径与行号、可达路径、触发条件、攻击方式、影响、证据、修复建议、置信度和是否需要动态验证。最后由主审计员复核，去重降噪、排除误报，合并成按严重程度排序的总报告，并明确列出确认漏洞、疑似漏洞、已覆盖项和盲区。

这条路还有一层权限设计。默认只允许只读审计，不允许改代码、删文件、提交 git、装依赖、联网下载或执行破坏性命令；必要时也只允许读项目信息、搜代码、跑只读测试或静态分析。

两条路的机制不一样，不能互相替换。Claude Code 的多 agent 并行是平台能力，Codex 这边靠的是编排器加 CLI 的分工。

多 Agent 审计编排的实况画面

它不能替你做什么

先说工具自己的边界。这套流程明确不准输出破坏性 Payload，删文件、改配置、删库清表、写后门、反弹 shell、窃取数据、横向移动一律不许；只允许无害的证明手法，比如只读验证、布尔差异、受控回显标记，或针对非敏感测试记录的越权证明。Host、Cookie、凭据、ID 默认用占位符，除非你给出授权测试值。非得靠破坏性操作才能证明的漏洞，只能写进高风险线索，并说明缺了哪条非破坏性验证路径。

再说能力边界。多 agent 那套目前还是实验性功能，不是所有情况都稳定。逻辑复杂的项目，调用链追踪可能出现断链。业务层面的越权能识别到入口，但深层的业务逻辑漏洞还是得人来判断，工具给不了结论。

所以它的合理定位是快速摸底，而不是替代人工的银弹。用它把攻击面梳理清楚、把高危路由筛出来，然后人聚焦在真正关键的地方。

这个思路还留了继续走的空间。报告字段里要求写「同源或相似的受影响路由」，编排流程也要求明确列出审计盲区，这其实就是为了把单点发现往复合利用链上推。

仓库地址是 https://github.com/RuoJi6/audit-skills