干这行时间长了你会发现代码审计里最难的不是发现漏洞而是每天跟一模一样的机械活较劲查入口、翻配置、找硬编码密钥、挨个接口看参数拼接最后还要憋一份既严谨又看得懂的审计报告。老手干这些事浪费时间新手干又容易漏。AI编程大热之后我一直在琢磨怎么让大模型把这一整套流程接过去。试了不少方案折腾到最后发现把审计经验固化成 skill 才是最靠谱的路线。这篇文章就讲讲我是怎么基于 Claude 和 Cursor 的 skill 机制搭了一套 AI 代码审计工作流跑了大几百个 Java 接口之后沉淀下来的东西。适合谁看想用 AI 给代码审计提效的开发者、安全工程师、测试开发以及被“AI 写代码”和“AI 审代码”之间差距困扰过的人。能解决什么问题把审计流程从“完全靠人肉翻代码”变成“AI 按固定流程先扫一遍人只做确认和深挖”尤其适合 Java Web 项目。文章的深度会从 skill 的设计原理讲到具体规则怎么写再到实测中的误报、幻觉、上下文爆炸这些坑最后给出一套可以直接抄走的目录结构和提示词框架。1. 先想清楚为什么要用 skill 做代码审计而不是直接丢给 AI1.1 传统人工审计的三个老大难第一个是重复劳动。任何一次 Web 应用审计开头都是固定动作找入口点、梳理鉴权、翻配置文件、看有没有硬编码密钥、查第三方组件版本。这套动作占掉审计周期大概一半的时间但产出的是“过程资产”不是“审计结论”。第二个是经验断层。一个审计老手看到String sql select * from user where id id会瞬间警觉但新手不会因为新手脑子里没有“污点追踪”和“隐式类型转换绕过”这些上下文。团队里最容易出现的情况是老手忙不过来新手不敢下手审计质量全靠个人水平。第三个是报告成本高。发现漏洞只是第一步写复现步骤、给修复代码、标 CWE 编号、评估风险等级这些工作量和发现漏洞本身差不多。我以前统计过一个中危漏洞从确认到写进报告最少要 40 分钟其中一大半是在组织语言和查资料。1.2 AI skill 的边界它能干重活不能背锅把项目直接丢给 ChatGPT 说“帮我审这个代码”得到的往往是一堆正确的废话。原因很简单没有约束流程的审计不算审计只是“代码讲解”。而 skill 恰好补上这一环—它本质上是一份“操作手册 领域提示词 规则库”的打包体让 AI 按照你预设的流程、标准和输出格式去执行。用我这个code-audit-proskill 实测下来它能把审计效率提升一个数量级原来一个 200 个接口的 Java 项目纯人审要 5 到 7 个工作日现在 AI 先做两轮流程化扫描人在第三、四轮做重点确认两个工作日基本能出初稿。但也要泼盆冷水。skill 解决不了“业务逻辑漏洞”比如优惠券能否叠加使用、订单状态机是否存在越权分支这类问题需要理解业务意图AI 只能给线索不能给结论。skill 也替代不了渗透测试它做的是静态的代码层面检查不是运行时的攻击验证。所以定位应该是一个永不疲倦的初级审计员负责把所有脏活累活机械化地做掉把结果整理得明明白白交给人类专家来定夺。2. 搭一套代码审计 skill工具选型和文件结构2.1 模型与工具选型不是所有大模型都适合跑代码审计。我先后试过 ChatGPT、Claude、通义千问和本地部署的 Qwen最后留在了 Claude 系模型 Cursor 的组合上原因有三需求点推荐方案原因长上下文理解Claude Sonnet / Opus审计要求跨文件追踪数据流上下文窗口小了根本跑不动IDE 内操作Cursor可以直接把整个仓库交给 AI还能在对话中引用具体文件规则配置Skill 机制SKILL.mdAnthropic 系模型对 skill 这种结构化指令的遵循度明显更高免费平替方案DeepSeek 自建知识库对规则遵循稍弱但性价比极高这里提一句 Cursor 里其实已经有不少现成的 code review 类 skill但它们大多停留在“找 bug”层面不适合做安全审计。我在自己的 skill 里特别加了安全规则引擎、数据流追踪、误报过滤三层结构和普通的代码检查完全不是一个定位。2.2 skill 目录结构设计一个完整的审计 skill 应该长这样code-audit-pro/ ├── SKILL.md # skill 主入口AI 首先读取 ├── rules/ │ ├── java_owasp.yaml # Java 漏洞模式规则库 │ ├── web_generic.yaml # 通用 Web 漏洞规则 │ └── sensitive_info.yaml # 硬编码密钥/敏感信息规则 ├── workflows/ │ ├── 01_recon.md # 第一步资产与入口盘点 │ ├── 02_taint.md # 第二步污点追踪 │ ├── 03_verify.md # 第三步验证与去误报 │ └── 04_report.md # 第四步报告生成 ├── references/ │ ├── cwe_top25.md # CWE 编号速查表 │ ├── cvss_v3_calc.md # 风险评分说明 │ └── fix_patterns.md # 常见修复代码模板 └── scripts/ └── sensitive_scan.py # 本地敏感信息辅助扫描你要理解这个结构的用意rules/给 AI 提供“判断标准”workflows/给它“执行步骤”references/给它“背景知识”scripts/给它“外部工具能力”。一个 SKILL.md 写再多字也顶不过一套完整的分层结构。2.3 SKILL.md 主文件的写法写 SKILL.md 有个核心原则开头要用可触发的描述中间要用不可违背的步骤结尾要用明确的输出约束。我最早写的 skill 就吃了描述太模糊的亏—“当用户要求审计代码时执行”这种话AI 经常不认后来改成了带示例的触发描述才稳定。一个可以作为模板的 SKILL.md 头部--- name: code-audit-pro description: 对 Web 应用代码执行安全审计覆盖 OWASP Top 10 漏洞模式 输出带 CWE 编号、风险等级和修复建议的报告。 当用户提到审计、审一下、检查安全、看漏洞时激活。 --- ## 核心流程必须按序执行禁止跳过 1. 调用 workflows/01_recon.md 盘点入口与敏感信息 2. 调用 workflows/02_taint.md 追踪输入数据流 3. 调用 workflows/03_verify.md 过滤误报 4. 调用 workflows/04_report.md 生成报告 ## 硬性规则 - 没有确认数据流完整链路之前禁止直接判定漏洞 - 所有漏洞必须标注 CWE 编号 - 当证据不足时输出存疑而不是确认这里最重要的不是描述是“硬性规则”。AI 默认倾向是“顺着用户说”你给它一个代码片段它很容易顺着你的暗示说出“这里有漏洞”。硬性规则会强制它先走流程、再下结论这就是 skill 和普通 prompt 的本质区别。3. 把审计流程拆成 skill 的四大工作流3.1 第一轮资产与入口盘点为什么要先做资产盘点因为审计最怕“漏”而 AI 最容易“漏”。一个项目有 30 个 Controller、80 个 Service、200 个接口如果你直接让 AI“找漏洞”它大概率只盯着前几个文件后面的全被注意力机制忽略掉。所以第一轮必须强制产出资产清单让 AI 把所有可访问的入口点列出来。具体指令我给是这样的一段扫描整个仓库完成以下任务 1. 找出所有 Web 入口类Controller / RestController列出每个类的 RequestMapping 路径 2. 找出所有参数接收点RequestParam / RequestBody / PathVariable 3. 找出配置文件中的数据库连接、第三方密钥、Token、AK/SK 4. 输出为 markdown 表格类名 / 方法名 / URL路径 / 参数 / 是否需登录这一轮跑完你会得到一个完整的攻击面表格。我曾经用它在一个人的外包系统里直接翻出了 14 处硬编码密钥和 3 个没有鉴权的管理接口这些都是后续漏洞分析的重要线索。3.2 第二轮数据流追踪与污点分析资产盘点解决“在哪找”数据流追踪解决“怎么找”。这是整个 skill 里技术含量最高的一步。原理上就是经典的污点追踪模型输入源Source→ 传播路径Propagation→ 危险操作Sink。规则库里定义了这三类# java_owasp.yaml 片段 sources: - RequestParam - RequestBody - PathVariable - request.getParameter - HttpServletRequest sinks: - executeQuery - executeUpdate - Runtime.exec - ProcessBuilder - Files.readAllBytes sanitizers: - PreparedStatement - SecureRandom - HtmlUtils.htmlEscape - URLEncoder.encode为什么这步必须在前两步之后因为如果 AI 没有全局资产表它做污点追踪时只能看到片段request.getParameter传了三层函数之后的executeQuery它根本追不到。我实际测试过跳过第一步直接让 AI 追踪数据流有效发现量直接降了 60%。AI 在这轮的表现会明显分化。Claude 系模型对“我给你的就这一个函数往上往下都要找”这种指令执行力很强能自动展开调用链而一些小模型只会盯着当前文件里的局部变量看追不了跨类调用。这也是我最后选择 Claude 的原因之一。3.3 第三轮验证与误报过滤这轮是整个 skill 的灵魂也是我和普通 AI 编程插件拉开距离的关键。AI 在第二轮里会产出大量“疑似漏洞”但里面夹杂着大量误报。典型例子把ORDER BY ${sort}当成 SQL 注入实际上排序字段做了白名单校验看到password明文存储就报敏感信息泄露没发现上游已经做了 BCrypt 加密把Integer.parseInt的参数当作 XSS 入口但页面模板已经做了默认转义所以 verify 工作流的指令必须是“质疑一切”对以下每个疑似漏洞按顺序执行 1. 重新追踪完整数据流确认输入源未经过滤 2. 检查 Sink 位置是否存在安全函数调用 3. 检查污点变量在传递过程中是否被类型转换阻断了 4. 若无法确认将状态改为存疑并说明缺少的关键证据这个环节我一直诟病很多“AI 安全扫描器”不做直接把 AI 的第一次输出端给用户导致一个项目 200 个“漏洞”一半是噪音信任感瞬间就没了。你要记住一套好的审计 skill误报过滤能力比发现能力重要十倍因为没人愿意给 50 个误报逐一下判断。3.4 报告生成与修复建议报告这一步AI 天然占优势因为它善于组织和归纳。但我发现直接让它“写报告”会跑偏容易写成空洞的“建议修复”。我这边对报告工作流做了严格约束输出格式要求 - 每个漏洞包含漏洞类型 / CWE编号 / 风险等级 / 文件位置(行号) / 触发链路 / 修复建议 / 修复代码示例 - 风险等级用 CVSS v3.0 评估说明评分依据 - 最终报告必须按风险等级从高到低排序 - 如果漏洞数量大于 10额外生成一个高危优先处理清单这里我踩过一个坑如果不说“行号”和“触发链路”AI 会偷懒只告诉你“LoginController 中存在 SQL 注入”让人还得回代码里找人肉定位。加了约束之后输出直接变成可以直接贴进 Wiki 和工单系统的格式。4. 实操实录用 skill 跑一遍 Java 登录接口4.1 测试目标代码为了演示我准备了一个典型的脆弱登录接口把 SQL 注入、硬编码密钥、明文传输三个问题全塞进去RestController RequestMapping(/api) public class LoginController { private static final String AES_KEY a1b2c3d4e5f6g7h8; // 硬编码密钥 PostMapping(/login) public String login(RequestParam String username, RequestParam String password) { // 直接拼接 SQL存在注入 String sql SELECT * FROM users WHERE username username AND password password ; Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(sql); if (rs.next()) { return login success; } return login failed; } }用地道的说法这段代码就是“教科书级别的反面样本”每一行都在踩 OWASP 的雷。我把整个项目放进 Cursor然后输入“用 code-audit-pro 审计这个项目”。4.2 skill 实际执行过程第一轮 recon 只跑了两分钟。AI 列出了登录接口的完整入口信息URL 是POST /api/login两个RequestParam参数直接绑定到方法签名类里还有硬编码的 AES 密钥常量。注意它做对了一件细节事把AES_KEY标记为“疑似硬编码密钥”。这一步如果不上规则库很多 AI 根本不会注意常量池里的密钥。第二轮 taint 是重头戏。AI 的追踪路径是这样的source: username, password (RequestParam来自HTTP请求) propagation: 直接拼接到 sql 字符串 sink: Statement.executeQuery(sql) sanitizer: 未检测到 PreparedStatement / 参数化查询 结论: 污点未经过滤直接进入 SQL 执行它甚至补了一句“密码字段也可能触发注入且密码明文参与 SQL 拼接属于附加风险”这个分析已经超过大部分初级审计员的水平。第三轮 verifyAI 尝试了反驳自己它先问“有没有可能在 Controller 之前存在全局过滤器拦截”接着扫描了拦截器配置确认没有全局的 SQL 注入防护最终才把这条判定为“确认漏洞”。这个过程不是我预设的流程在跑而是模型自己在推理说明规则库给了它足够多的知识背景。这也是我强调 skill 里必须放 references 的原因没有 CWE 和修复模式库AI 根本不会自我质疑。最终报告长这样### 漏洞 1SQL 注入 - CWECWE-89 - 风险等级高危CVSS 9.8攻击复杂度低无需认证 - 位置LoginController.java:12-18 - 触发链路POST /api/login → username/password → 字符串拼接 → executeQuery() - 修复建议使用 PreparedStatement 参数化查询 - 修复示例 PreparedStatement pstmt conn.prepareStatement( SELECT * FROM users WHERE username ? AND password ?); pstmt.setString(1, username); pstmt.setString(2, password);从输入指令到产出完整报告全程 4 分钟。对比人工审计这个接口的常规时间——含写报告 1 到 2 小时这里面的提升不是一点点而是量级上的变化。4.3 实测效果评估哪些靠得住哪些要留个心眼靠得住的部分常规 Web 漏洞模式注入、XSS、SSRF、路径遍历查得很全基本等于一个合格的自动扫描器。敏感信息扫描硬编码密钥、Token、AK/SK极其好用我测试时它把.env文件、配置文件里的测试密钥全翻了出来。修复代码质量高直接复制就能用。留个心眼的业务逻辑漏洞越权、竞态条件、验证码绕过基本发现不了或者说它给出的都是泛泛而谈的“建议加强校验”没有实际价值。对使用了大量框架和 ORM 的现代化项目数据流追踪会失效。它看不到 MyBatis 的动态 SQL 在 XML 里的拼接也追踪不了 Spring Data JPA 的 Specification 查询条件。这类问题目前无解只能靠人工补充。5. 踩坑记录skill 实战中的高频问题与排查技巧5.1 模型幻觉AI 自己编漏洞你怎么拦这是用 AI 做审计最让人头疼的事。最初一版 skill 跑完一个项目报告里列了 22 个“漏洞”我人工复核发现其中 7 个压根不存在——AI 把正常的配置项硬说成信息泄露把安全写法硬理解成危险函数。排查下来原因集中在两点一是规则库里“sink”定义太宽比如把logger.info也当成了敏感信息输出点二是没有强制要求“证据链”AI 在没有完整数据流证据的情况下习惯性顺着用户猜。解决办法两方面规则收紧把高危误报率高的 sink 模式从“自动确认”改成“存疑需人工确认”。指令约束在 SKILL.md 硬性规则里加一条“没有 100% 的数据流证据禁止判定为已确认漏洞只能标存疑”。改完之后误报率从 30% 降到了 8% 左右这个水平我觉得可以接受了。毕竟安全审计的基操就是疑罪从无这个原则必须写进 skill 里。5.2 大仓库上下文爆炸一个项目 500 个文件怎么跑AI 上下文窗口再大也有限一个真实项目塞进去几百个文件是常事。一开始我试图让 AI 一次读完整个仓库结果 Claude 直接罢工输出质量断崖式下跌。后来我的方案是“分层裁剪”用脚本先生成仓库文件树让 AI 只读目录结构。让它根据路径和命名规则挑出安全性最高的候选文件Controller、Service、Mapper XML、配置文件。分批处理每批控制在 20 到 30 个文件。每批结果自动累积到一份共享备忘录里最后统一生成报告。这套操作下来AI 的注意力集中多了漏检率明显下降。说白了人看代码也讲究“先看目录再深入”AI 也一样。5.3 代码截断与文件拼接AI 被笨问题坑了还有一个特别不起眼但杀伤力巨大的问题当单个文件内容过长或者多个文件被拼接到一段 context 里时模型可能把两个文件的边界搞混导致“漏洞位置定位错误”。我遇到过最离谱的一次AI 把 A 文件的Connection对象和 B 文件的executeQuery拼在一条链路上得出了一个根本不存在的跨类注入漏洞。排查之后发现是因为我在工作流指令里写了“把相关文件内容合并分析”模型真的把内容拼起来了却没有保留文件边界。修复方案也不复杂在 prompt 里明确规定“每次分析只针对单个文件跨文件追踪时先说明被追踪变量在文件 A 的身份再说明文件 B 中对应变量的身份”强制它建立命名空间意识。5.4 多语言项目怎么办规则库是核心痛我一开始只做了 Java 规则库后来接了个老 PHP 项目直接抓瞎。PHP 的$_GET、mysqli_query和 Java 完全两码事规则库不匹配时 AI 就会变成“只有描述没有依据”的废物。现在我的做法是每个语言建独立规则库。PHP 加$_GET、$_POST作为 sourcemysql_query、eval、system作为 sinkPython 加flask.request.args作为 sourceos.system、pickle.loads作为 sink。说白了这就是把人的语言知识提前喂给 AI让它不用现场猜。Java 项目写PHP 项目也可以写Python 项目一样只要规则库够用。好在 YAML 格式的规则库维护成本不高新接一种语言半天就能初始化。5.5 接入 CI/CD 的坑幂等和噪音最后说一下把 skill 接入流水线时踩的坑。最初直接在 CI 里用每天跑一次结果开发一看到几十条告警就直接“关闭所有”再也没人看。后来加了两个关键策略增量扫描只审计本次提交引入的代码变更不重复全量。存量漏洞单独维护一个已知问题清单避免每天都在刷同样的告警。分级告警高危走即时通知中低危则合并到日报。保证高危信息不被噪音淹没。再加上 skill 的“存疑”机制让不确定的问题先进待定区而不是直接打给团队整体的信任度才慢慢养回来。经验就是工具再准如果惹人心烦一样会被放弃。最后聊点实在的这套 skill 我前后迭代了三个多月最大体会是AI 代码审计的价值不在“替你思考”而在“替你跑腿”。它把入口盘点、数据流追踪、规则匹配、报告格式化这些纯体力活做到了 90 分让我能专心做机器做不了的事——确认业务逻辑漏洞、复测高危链路、评估真实可利用性。如果你也想搞一套建议从一个小项目开始先只做 Java 规则库和 recon taint 两条流程跑通了再往上加。skill 这个东西不需要一步到位它是迭代出来的。等你在自己的项目里跑出来第一个有价值的漏洞自然就知道下一版该加什么规则了。这套流程我现在还在用每次接新项目第一天晚上提交第二天早上就有完整初稿放在以前是不敢想的事。