如果你以为“用 Claude Code 挖漏洞”就是给 AI 一个域名、让它自动打点、然后坐等漏洞报告那这个预期大概率会落空。真正把 AI 辅助安全测试用起来的人都在做另一件事让 Claude Code 帮自己读代码、理接口、查逻辑、写报告把漏洞挖掘中最消耗精力的上下文整理工作接过去。本文不讨论“AI 能不能完全代替人挖洞”这没有意义。我想给你一条可以直接落地的实战路线从安装 Claude Code 开始到用它对一份源码做代码审计、排查逻辑漏洞、整理 SRC 报告每一步都有可复制的命令和提问模板。读完你会明白Claude Code 在漏洞挖掘里真正的定位是什么以及为什么它改变的不是“能不能挖到洞”而是“多久挖到洞、一个人能同时盯几条测试线”。1. 先想清楚Claude Code 在漏洞挖掘里能做哪一层很多安全初学者第一次接触 AI 辅助挖洞脑子里想的是“自动化攻击”。这个方向从一开始就走偏了。当前主流的 AI 编程助手包括 Claude Code本质上是终端里的编码代理它能读项目文件、执行命令、维护上下文、按你的指令修改代码但它没有“人类的攻击思路”更不应该被用来直接对线上目标发起未授权测试。那么在漏洞挖掘场景里Claude Code 真正能承担的工作是什么我的判断很明确它是一个带上下文的审计助理不是一个自动攻击器。比较实际的分工是这样的环节人工负责Claude Code 负责确定测试范围确认授权、划定资产边界不决定范围理解业务逻辑设计攻击思路协助梳理接口调用链代码审计判断漏洞可利用性定位可疑代码、生成分析报告生成测试用例决定在什么环境验证提供参数构造和边界条件整理报告审核结论、确认影响按模板输出复现步骤和修复建议这张表的意思是Claude Code 更适合做“需要大量文本阅读、跨文件比对、格式整理”的工作而这些工作恰恰是人工漏洞挖掘中最耗时、最影响效率的部分。举个例子。人工代码审计一份上万行的 Java 项目真正花时间的不是“看出 SQL 拼接有风险”而是从几个 Controller 一路追到 Mapper、再把调用链上每个参数来源看清楚。这个过程需要频繁切文件、保持上下文、做对比体力消耗远大于脑力消耗。Claude Code 的终端工作模式刚好擅长这个它能直接落在项目根目录里读取文件树沿着调用关系追问你只需要把问题问得足够具体。所以这篇文章的核心观点可以提前给你在漏洞挖掘中使用 Claude Code正确的姿势是“定向排查 人工复核”而不是“全面扫荡 坐等结果”。下面所有实战步骤都是围绕这个判断展开的。2. 漏洞挖掘的基本盘合法授权与 OWASP Top 10在进入实操之前必须先说清楚漏洞挖掘的合法边界。不是所有“找到一个漏洞”都是可以做的行为。正经的漏洞挖掘场景基本只有三类企业授权的渗透测试或红队评估测试范围、时间、方式都有书面约定漏洞赏金平台上的 SRC 项目平台或厂商明确授予测试权限并指定资产范围自建靶场或本地源码审计目标是你自己搭建的环境。这三类场景之外任何针对他人系统的“漏洞探测”都可能涉及违法问题。本文所有内容都默认你在授权范围内进行测试。这也是 Claude Code 这类工具使用的安全前提你让它分析的工作区必须是你有权读写的代码。有了授权之后漏洞挖掘还需要一个知识框架。最常用的是 OWASP Top 10它基本概括了 Web 安全里最常见的漏洞类型注入类最典型的是 SQL 注入、命令注入XSS 跨站脚本认证失效和会话管理问题越权访问包括水平越权和垂直越权安全配置错误敏感数据泄露文件上传与任意文件读取不安全的反序列化使用存在已知漏洞的组件日志与监控不足。有人问既然这些漏洞类型是公开的AI 能不能直接帮我把目标打一遍答案是AI 可以帮你“按这些类型去代码里找证据”但不能替你确认业务逻辑层面的可利用性。一个漏洞是不是真的成立取决于参数是否可控、数据流是否可达、影响是否真实这些都需要代码证据和业务上下文支撑。Claude Code 在其中的价值就是你把这些漏洞类型写进它的工作规则让它按框架去审计代码。它帮你把“埋雷点”标出来你再逐一判断。这种工作方式下OWASP Top 10 不再是一份需要背诵的清单而是一个可以变成提示词的审计过滤器。3. 环境准备安装 Claude Code 并初始化工作区这一节直接进入实操。先说明环境以下步骤适用于 Linux、macOS 或 Windows 上安装了 Node.js 的环境。如果你在 Windows 上使用建议搭配 WSL2 使用终端体验更接近 LinuxClaude Code 对文件路径的处理也会更自然。3.1 安装 Node.js 与 npmClaude Code 官方推荐的安装方式是通过 npm。所以第一步是确认你的机器上有 Node.js 环境。node --version npm --version如果你的环境还没有 Node.js可以到官网下载 LTS 版本安装。安装完成后重新打开终端确认node --version能正常输出。3.2 通过 npm 安装 Claude Code确认 Node.js 环境后执行全局安装npm install -g anthropic-ai/claude-code安装完成后验证版本claude --version这里有一个容易踩的坑npm 全局安装的包其可执行文件目录可能不在系统的 PATH 中。如果你在 macOS 或 Linux 上遇到“claude: command not found”一般是因为 npm 的全局 bin 目录没有被加入 PATH。可以先执行npm bin -g找到全局 bin 路径再按自己 shell 的语法把它加入 PATH。Windows 上如果使用 WSL2同一个问题也适用。3.3 登录与初始化安装完成后在终端进入你的工作区目录执行cd ~/workspace/security-lab claude第一次启动时Claude Code 会引导你完成登录授权。不同版本的引导流程可能有差异但整体路径是在终端里确认登录方式完成账号授权后进入交互式对话界面。进入后可以输入/help查看当前版本支持的斜杠命令。如果你所在的地理位置或网络环境无法直接访问服务提供方的官网、npm 仓库或 API请使用符合当地法律法规的方式解决网络环境问题不要采用任何绕过网络限制的非法手段。安装完成后请确认你的使用方式符合服务条款和数据合规要求。3.4 初始化安全审计工作区我建议你为漏洞挖掘单独建一个工作区不要直接用生产项目目录。比如mkdir ~/workspace/sec-audit-lab cd ~/workspace/sec-audit-lab claude这样做的原因有两个一是 Claude Code 会把工作区内的文件作为上下文范围越小、干扰越少二是安全问题往往涉及敏感代码单独隔离有利于控制访问边界。4. 核心用法让 Claude Code 读懂目标代码很多新手用 Claude Code 做审计上来就问“这段代码有漏洞吗”这种问法太宽泛拿到的答案也比较泛。正确做法是先把工具“喂”到项目上下文里再让它按指定规则输出。4.1 让它先理解项目结构启动对话后可以先用一条简洁的指令让它梳理项目请浏览当前工作区的项目结构阅读 README 和构建配置 说明这是一个什么类型的 Web 项目技术栈是什么 并列出所有 Controller 或路由入口文件。这一步的目的是让 AI 建立全局认知。如果项目太大你可以指定目录而不是让它一次读完全部文件。4.2 使用 语法引用文件Claude Code 支持在对话中引用具体文件。审计时最基础的操作就是把可疑文件拖进上下文请审计 src/main/java/com/example/demo/AuthController.java 重点检查认证和鉴权逻辑是否存在缺陷。引用文件之后AI 不需要你复制粘贴代码它会自己读取文件内容。当你需要对比多个文件时可以一次性引用请对比 UserController.java 和 AdminController.java 中 对 userId 的参数处理逻辑指出是否存在越权风险。4.3 用 CLAUDE.md 固化审计规则Claude Code 会读取工作区中的CLAUDE.md文件作为项目级上下文。这意味着你可以把审计规范写进去让它每次回答都遵守。先建一个审计规则文件# 安全审计工作区规则 ## 工作目标 对当前代码库进行授权范围内的安全审计不访问外部系统。 ## 审计重点 - SQL 注入检查参数拼接、JPA/MyBatis 动态 SQL、存储过程。 - 越权检查按 userId/订单号/文件路径查询的接口是否校验归属。 - 文件上传检查文件名拼接、后缀校验、存储路径是否可预测。 - 认证与会话检查登录逻辑、Token 校验、会话固定问题。 ## 输出格式 对每个发现按以下结构输出 风险等级 | 漏洞类型 | 代码位置 | 触发条件 | 影响范围 | 修复建议 ## 禁止事项 - 不生成可用于攻击线上系统的自动化指令。 - 不模拟绕过认证后的数据获取。 - 不确定的影响范围必须标注“需人工复核”。保存后在同一个工作区启动 Claude Code它就会自动参考这份规则。你可以理解为这相当于给审计助理下发了一份“工作手册”它会让输出结果稳定、规范减少漫天发挥。5. 实战路线一代码审计辅助第一条路线从代码审计开始。这是 Claude Code 在漏洞挖掘中最容易上手的场景因为代码是文本而 AI 最擅长的就是文本理解。假设你在授权测试项目中拿到了一份源代码里面有这样一个登录接口。// 文件路径src/main/java/com/example/demo/controller/AuthController.java PostMapping(/login) public ResponseEntity? login(RequestBody LoginRequest req) { String username req.getUsername(); String password req.getPassword(); String sql SELECT * FROM user WHERE username username AND password password ; JdbcTemplate jdbc new JdbcTemplate(dataSource); ListMapString, Object rows jdbc.queryForList(sql); if (!rows.isEmpty()) { return ResponseEntity.ok(login success); } return ResponseEntity.status(401).body(login failed); }如果让 Claude Code 直接看这段代码你可以这样问请审计 AuthController.java 的 login 方法。 说明这是一个登录接口username 和 password 都来自用户请求体。 请检查是否存在注入类风险并结合代码说明触发条件和影响。 如果存在漏洞请给出修复后的写法保留原有代码风格。得到的回答通常会包含几个部分风险定位SQL 语句中直接拼接了请求参数攻击者可以构造恶意用户名改变查询条件触发条件接口对外可达、参数可控、未使用预编译语句影响范围可能导致数据库数据被越权读取、绕过登录验证严重时可能通过堆叠查询能力影响数据库实例注意影响是否扩大取决于数据库配置和驱动这一点需要人工复核修复建议改用PreparedStatement或参数化查询不要手动拼接 SQL。这个流程的价值在于人工只需要复核 AI 的结论是否正确而不需要从头阅读整条调用链。即使你后续还要自己验证定位的时间也会大幅缩短。这里要特别提醒AI 输出“有漏洞”不等于真的有漏洞AI 输出“没有漏洞”也不等于安全。代码审计的结论必须满足两个条件才算可信一是代码位置和调用链清晰可追踪二是你能在自己的授权环境中验证。Claude Code 在这个环节是“效率加速器”不是“最终裁决者”。6. 实战路线二接口与逻辑漏洞排查代码审计解决的是“单点问题”接口与逻辑漏洞排查则更考验对全局业务的理解。这类漏洞往往不在某一行代码里而是藏在多个接口之间的关系中。典型场景是水平越权系统里用户 A 和用户 B 都能调用同一个“查询订单详情”接口但接口只根据前端传入的 orderId 查询数据没有校验这个订单是否属于当前登录用户。人工排查时你需要把接口清单、参数传递、鉴权中间件全部串起来才能确认问题是否存在。Claude Code 可以帮你做前半段工作。你可以在工作区中指定请分析当前项目中所有带 userId、orderId、id、path 参数的接口。 对每个接口先说明它是否从当前登录用户对象中获取身份信息 还是直接从请求参数中获取目标对象 ID。 输出格式 接口路径 | 参数来源 | 是否校验对象归属 | 风险判断这种排查方式适合有明确业务含义的项目。AI 会把所有接口的参数来源和校验逻辑列出来你再根据业务知识做判断。注意AI 判断“未校验归属”只是代码层面的线索是否真的能利用还需要看整个请求链路里有没有全局鉴权、有没有 WAF 或其他限制。除了越权接口排查还可以关注这几类问题批量导出接口是否限制数量文件下载接口是否校验文件路径状态变更接口是否校验状态机流转密码修改/重置接口是否存在逻辑绕过。这些场景的提示词写法有一个共同点先给 AI 一个明确的检查维度再让它按维度输出结果。就像面试官出题题目越具体候选人的回答越可用。7. 实战路线三SRC 报告整理与攻击链梳理很多初学者在 SRC 项目里第一个洞不是“挖出来”的而是“没提交好”被忽略的。漏洞发现之后需要一份能帮助审核人员快速复现的报告。Claude Code 很擅长把无序的分析整理成结构化内容。假设你发现了一个逻辑漏洞某接口在修改收货地址时只校验了登录状态没有校验地址归属。你可以让 Claude Code 基于一段代码或一次对话整理报告把前面的分析整理成一份 SRC 漏洞报告草稿。 包含以下小节 1. 漏洞标题 2. 漏洞类型与风险等级 3. 漏洞详细描述 4. 复现步骤 5. 影响范围 6. 修复建议 语气保持中文步骤清晰不添加臆测内容。AI 整理报告时要特别注意两点。一是复现步骤必须可执行每一步都要精确到接口、参数、请求方式二是影响说明必须克制没有验证过的危害不要写。AI 可能会倾向于补充一个“可能造成严重危害”的险恶描述这种地方需要人工删掉。另一种用法是攻击链梳理。单个漏洞的等级可能很低但组合起来就可能变成高危链路。你可以把多个线索交给 Claude Code让它辅助枚举组合方式在刚才的分析中已经发现三个线索 1. 用户接口存在 IDOR可以根据用户ID查看他人订单 2. 部分订单明细接口返回了完整的手机号和地址 3. 管理后台登录接口没有锁定失败次数。 请把这三个线索组合起来推测可能的攻击链路 并指出每条链路中缺少的验证条件。这种追问方式不会直接给出“稳了”的结论而是把不确定环节明确出来剩下的验证工作由你完成。对 SRC 测试来说攻击链梳理的价值不亚于漏洞本身因为厂商评估漏洞等级时会特别看重实际影响链路。8. 运行结果与效果验证如何判断 AI 的输出可信AI 输出的安全结论必须经过一套人工验证流程。我在实际使用中的判断标准如下。第一步看代码位置。如果 AI 指出的问题没有精确到文件和行号而是泛泛而谈“存在安全风险”这个结论先放一边。真正的审计结论要能回溯风险出现在哪个文件、哪一行、哪条调用链上。第二步看触发条件。一个漏洞成立必须具备触发条件。AI 指出“用户输入未过滤”你就追问“这个接口是否真的公网可达”“参数是否真的从 HTTP 请求进来”。如果触发条件不成立代码层面的问题可能只是理论风险。第三步小范围验证。所有验证操作都应该在被授权的靶场环境或测试用例中执行绝不要直接对生产系统发起测试。验证时可以使用安全的思路比如观察错误响应差异、比较正常参数和异常参数的处理分支、查看日志输出。如果你不确定某个操作是否越界宁可不验证也不要冒险。第四步换角度交叉验证。同一个问题换一种问法再问一次。第一次问“这段代码有没有注入风险”第二次问“如果我传入的参数是 abc 会发生什么”。两种问法得到一致结论时可信度会明显提高。第五步把 AI 当“初筛器”不当“结论器”。它的价值是帮你圈定可疑范围最终负责的是人。尤其是漏洞定级、影响评估、修复方案上线这类环节AI 不能替你拍板。下面给出一个简洁的验证检查清单- 该问题是否有可定位的代码位置 - 接口触发条件是否在授权测试范围内 - 是否区分了代码风险和实际可利用风险 - 是否在靶场或测试接口中做过非破坏性验证 - 修复建议是否能直接落到代码层面检查清单里有任意一项“否”结论就不能直接进入 SRC 报告。9. 常见问题与排查思路在安装和使用 Claude Code 做漏洞挖掘时你大概率会遇到下面这些问题。问题现象可能原因排查方式解决方案安装后提示claude: command not foundnpm 的全局 bin 目录不在 PATH 中执行npm bin -g查看全局路径将全局 bin 目录加入 shell PATH 配置启动后一直停留在初始化界面首次登录授权未完成查看终端引导提示确认账号授权状态按引导完成账号授权重启终端引用的文件读取为空工作区路径不对或文件权限不足检查当前工作目录ls确认文件存在进入项目根目录启动 claudeAI 输出的漏洞位置不精确上下文过少或项目过大缩小范围只引用关键文件将项目拆分成模块逐次审计生成的测试用例过于激进没有在工作规则中约束行为在 CLAUDE.md 中补充“禁止生成攻击线上系统的指令”明确测试边界和输出格式不同问法得到矛盾结论上下文缺失或提示词不具体把调用链完整喂给模型补充代码路径和业务场景重新提问回答内容有幻觉超出上下文范围、模型自行补全交叉验证关键事实要求 AI 标注“不确定”项如果你为了控制成本使用了社区中的第三方模型接入 Claude Code 的方案请务必确认接入方式是否合法合规并充分考虑模型稳定性对安全审计的影响。第三方接入改变了模型本身的推理能力审计结论需要额外的交叉验证不要因为同一次回答质量高就完全信任。另外卸载 Claude Code 的方式很简单npm uninstall -g anthropic-ai/claude-code如果你需要临时清理配置可以删除用户目录下由工具生成的配置目录。具体路径因版本而异卸载前建议先备份工作区中的CLAUDE.md和审计记录。10. 最佳实践与安全边界经过前面几条路线你应该已经意识到Claude Code 在漏洞挖掘里不是“外挂”而是一个需要调教的工作伙伴。下面几条最佳实践是我认为最有价值的经验。第一授权优先。任何一次 AI 辅助漏洞挖掘都必须以合法授权为前提。授权范围要具体到域名、接口、测试时间段。测试过程中涉及的数据不要下载到本地长期保存更不要作为技术分享的素材传播。第二最小权限。给 Claude Code 的工作区只放授权测试需要的代码和配置文件。不要把整个内网资产、生产服务器凭据、数据库连接串放在同一个目录里。AI 工具在读取代码时你无法完全控制它“看到什么”所以最好的方式是从源头上控制它“能看到什么”。第三上下文隔离。一个工作区只做一类测试。测 A 项目的代码审计时不要把 B 项目的文件放进来。否则 AI 会混淆资产边界输出的结论可能跨越授权范围。第四记录过程。每次审计的提问、输出、结论、人工验证动作建议用笔记软件或仓库记录下来。这不仅方便复现问题也能让你逐渐沉淀出一套属于自己的“提示词模板”。下次遇到同类项目直接把模板套上去效率会更高。第五不要全自动化攻击。不要写脚本让 AI 自动对资产发起批量请求这是合规风险极高的行为。Claude Code 可以自动执行命令但你应该让它执行的只是读文件、跑测试脚本、整理报告这类无害操作。所有涉及网络请求、数据修改的动作必须由人确认后手动触发。第六谨慎看待“AI 找到的洞”。无论是 AI 分析的任意文件读取、反序列化、还是命令执行都属于高影响漏洞类型。这类结论一定要通过最小化验证比如在靶场环境构造对应请求观察响应差异确认影响真实存在后再进入报告流程。在团队协作场景中还可以让 Claude Code 输出审计记录方便安全负责人复核。建议每次审计结束前向 Claude Code 发出这样一个指令请根据本次会话中对 src/main/java 的审计过程 生成一份审计工作记录包含已检查的接口、发现的问题、 未完成复核的项、以及下一步建议。 输出保留在 audit-notes.md 中。这个习惯会让你的漏洞挖掘工作具备可追溯性而不是靠聊天记录碰运气。11. 总结这条实战路线该怎么用最后把整套路线串一遍。你用 Claude Code 辅助挖漏洞真正应该建立的是一条这样的工作流安装并配置好 Claude Code为每个授权测试项目建立独立工作区写好CLAUDE.md审计规则在拿到源码后先让它梳理项目结构、接口清单再结合 OWASP Top 10 重点审查代码中的参数拼接、对象归属和上传下载逻辑发现可疑点后要求它按“问题位置、触发条件、影响范围、修复建议”的格式输出最后由人工交叉验证、小范围测试、整理成 SRC 报告。这条路线里没有任何一步是“全自动挖洞”。但它确实能把漏洞挖掘中最吃力的部分解放出来你不再需要把几个小时的注意力全部投在反复翻文件和比对接口上而是把精力留给真正需要人类经验和判断力的环节比如漏洞是否真的可以利用、业务逻辑里藏着什么默认假设、报告如何写得让厂商愿意处理。如果你是第一次接触 AI 辅助漏洞挖掘建议不要直接上手 SRC 项目。先找一个带公开漏洞的靶场源码或自己写的项目按第 5 节的提问方式做一次完整审计跑通流程之后再去 SRC 项目实战。到那时你会发现Claude Code 的正确用法不是替你“挖洞”而是帮你把每一个洞看得更清楚、验证得更快、提交得更专业。