Claude Code 最近成了 AI 编程工具里讨论度很高的话题但很多人还停留在“让 AI 帮我写函数、补单测”的阶段。如果你是一名安全测试工程师、甲方安全工程师或者平时要负责代码审计的开发者可能会遇到另一个更实际的问题漏洞挖掘的很多步骤其实非常机械比如拉取依赖清单、对比公开漏洞库、搜索硬编码密钥、追踪危险函数调用链这些工作重复且耗时。过去我们需要组合使用 SAST、DAST、SCA 等一堆工具再人工核对产出能不能让一个能理解上下文的 AI 智能体来承担其中一部分这篇文章要讨论的就是把 Claude Code 和 Custom Skills 组合起来打造一个面向授权范围内的自动化漏洞挖掘助手。我的观点很明确Claude Code 真正改变的不是“自动发现漏洞”这件事而是把安全审计的方法论从“人肉执行”变成了“可复用、可版本化、可批量执行的工程资产”。它降低的不是安全知识的门槛而是重复执行审计流程的成本。读完这篇文章你会理解 Custom Skills 的执行机制学会编写一个用于漏洞挖掘的 Skill并能在真实项目中配置、运行和验证它。1. 为什么需要 AI 自动化漏洞挖掘先看清当前漏洞挖掘工作流的真实状态。很多团队做安全测试时并不是缺少漏洞扫描器而是缺少一个能理解业务逻辑、能跨文件追踪数据流、能自动整理证据的分析层。以代码审计为例传统 SAST 工具擅长发现 SQL 注入、XSS、命令注入等模式化问题但误报率常年偏高安全工程师把大量时间花在“判断这个告警是不是真的”上。而人工审计虽然准确率高却受限于个人精力无法覆盖大型项目的每一个模块。这时Claude Code 这类终端智能体提供了一个新的工程位置。它不是扫描器而是一个能读取项目结构、理解代码语义、调用外部命令、自主规划执行步骤的 Agent。它可以替工程师完成以下工作读取项目依赖清单提取组件名和版本号。调用 OSV-Scanner、Trivy 等漏洞库工具比对已知漏洞。在仓库中搜索 API Key、密码、Token 等敏感信息。追踪用户输入到危险函数之间的调用链判断是否存在真实可利用路径。生成带证据路径、修复建议和严重级别标记的报告。这些步骤都有一个共性它们可以被拆成明确的规则和流程。Custom Skills 的价值就在这里——把上述每一个流程封装成可复用的技能模块让 Claude Code 在执行任务时自动调用或由用户主动触发。安全团队的资深成员可以把审计经验写成 Skill团队其他人甚至非安全背景的开发者也能受益。当然这里有一个必须遵守的前提所有自动化扫描和分析只能在合法授权的范围内进行。对未授权系统、未授权源码进行挖掘无论使用什么工具都存在合规风险。本文所有示例都以授权测试、自建项目或开源项目为对象。2. Claude Code 与 Custom Skills 的核心概念2.1 Claude Code 是什么Claude Code 是 Anthropic 推出的命令行编程智能体开发者可以在终端中启动它以自然语言描述任务由它自动完成代码阅读、编辑、命令执行、测试运行等操作。它并不仅仅是一个“聊天机器人”而是一个具备工具调用能力的 Agent它能查看文件、搜索代码、执行 Shell 命令、根据执行结果决定下一步动作。Claude Code 有多种使用形态。最基础的是 CLI 终端模式在项目目录下运行claude命令即可交互也可以作为 VSCode 插件使用在编辑器内选择代码片段交给它分析桌面端则提供了更完整的项目和对话管理界面。许多团队还把它接入 CI/CD 流程用于代码审查、修复建议等自动化任务。从工程视角看Claude Code 的核心是“上下文管理”。它会加载项目目录下的 CLAUDE.md、代码索引、当前对话记录等作为决策依据。这决定了它比传统静态扫描器更擅长处理“需要理解项目约定”的任务也意味着我们需要为它限定工作范围和权限。2.2 Custom Skills 的机制Custom Skills 是 Claude Code 中的一种可扩展能力机制本质上是“结构化的 Prompt 和工具定义包”。一个 Skill 通常包含SKILL.md文件包含该技能的描述、触发条件、执行步骤、输入输出要求。可选的脚本或工具文件例如 Python 脚本、Shell 脚本用于辅助完成具体操作。元信息例如技能名称、适用场景、作者等。Skill 的存放位置决定了它的作用域。项目级 Skill 通常放在.claude/skills/目录下团队可以通过 Git 共享用户级 Skill 则放在个人配置目录中适用于跨项目使用的通用能力。Claude Code 会在合适的时候根据SKILL.md中的描述自动匹配并加载对应技能也可以由用户显式指定。2.3 Skill 与普通 Prompt 的区别有读者可能会问我直接写一段很长的 Prompt让 Claude 去做审计不也是同样的效果吗为什么还要维护一个 Skill区别在于工程化对比维度普通 PromptCustom Skill复用方式每次复制粘贴容易遗漏或改坏目录化、版本化随项目共享触发机制依赖用户完整描述任务通过描述自动匹配或显式调用执行细节每次都可能偏离流程固化步骤减少行为漂移团队协作个人经验组织知识资产测试与迭代难以做回归验证可以针对 Skill 输出做效果验证安全审计尤其适合这种结构化方式。审计流程要求步骤清晰、证据可回溯、输出格式一致这正好是 Skill 的强项。当团队总结出一个可靠的审计方法后把它沉淀成 Skill实际上是在把个人经验转化为团队的标准化能力。3. 自动化漏洞挖掘的 Skill 设计思路在动手写SKILL.md之前先想清楚一个问题漏洞挖掘不是一个“单一动作”而是一条流水线。完整的流程通常包括信息收集、依赖审计、代码审计、敏感信息检查、利用验证、报告生成六个阶段。如果只写一个巨大的 Skill期望它在一个会话里完成所有事情往往会出现执行混乱、上下文超限、漏步骤等问题。更稳妥的设计是拆分成多个职责单一的 Skill每个 Skill 负责流水线中的一个环节dependency-audit提取依赖清单调用漏洞库比对生成依赖风险清单。code-audit针对指定目录进行源码级审计追踪危险函数和输入源。secret-scan在仓库历史与当前代码中搜索硬编码密钥、Token、私钥。report-generator汇总各流程结果按资产、严重级别、修复建议生成结构化报告。每个 Skill 需要明确的输入、输出和边界。例如dependency-audit的输入是项目依赖文件路径比如pom.xml、package-lock.json、requirements.txt输出是一份包含 CVE 编号、影响版本、修复版本的清单。边界则是它不应该尝试修改代码只做审计和报告。Skill 设计还有一条重要原则所有自动化结果都必须支持人工复核。Skill 输出报告时应包含“证据路径”和“置信度说明”方便安全工程师判断这个告警是否真实。AI 的定位是“快速扩大排查面”而不是“代做最终判断”。下面的章节我会从环境准备开始带你把整套流程跑通。4. 环境准备与前置配置4.1 安装 Claude Code 命令工具Claude Code 的安装方式以官方文档为准当前常见的方式是通过 npm 全局安装npm install -g anthropic-ai/claude-code安装完成后在任意项目目录下运行claude命令即可启动交互终端。如果你的网络环境无法直接访问官方服务也可以参考社区实践将 Claude Code 接入兼容的 API 网关或替代模型但需要特别注意模型名称、API 格式的兼容性。网络上常见的报错例如xxx is not a model this version of claude code recognizes通常就是因为模型标识与当前 CLI 版本不匹配后面会专门说明排查方法。4.2 认证与权限配置首次启动 Claude Code 时需要完成认证。官方支持两种方式使用 Claude 账号登录并授权。配置环境变量ANTHROPIC_API_KEY指向有效 API Key。例如在 Linux/macOS 下export ANTHROPIC_API_KEY你的API KeyWindows PowerShell 下使用$env:ANTHROPIC_API_KEY你的API Key这一环节要特别注意不要把 API Key 写入项目代码或提交到 Git 仓库。更稳妥的做法是在个人环境变量、CI 密钥管理或本地.env文件中维护并把.env加入.gitignore。4.3 项目级安全边界声明Claude Code 会读取项目根目录下的CLAUDE.md作为长期上下文。我们在设计安全审计项目时可以在CLAUDE.md中明确 Agent 的职责边界例如## 安全审计注意事项 - 本项目的审计目标均为已获得授权的代码和系统。 - 只允许执行读取、搜索、分析操作禁止修改代码、禁止向外部发送数据。 - 禁止在未授权环境中运行任何扫描命令。 - 所有报告输出到 reports/ 目录报告必须附带证据路径。这样做的意义在于当编排管道访问项目时它会优先读取该文件并受到约束。权限声明是安全测试自动化的第一道防线。4.4 准备辅助工具dependency-auditSkill 需要调用现成的漏洞库比对工具。常见开源工具包括 Google 的 OSV-Scanner、Aqua 的 Trivy、GitHub 的 Dependabot 等。以 OSV-Scanner 为例安装后可以用它本地扫描依赖文件osv-scanner --lockfile pom.xml这类工具的详细参数以官方文档为准Skill 里只需要封装调用逻辑不需要重复实现漏洞库匹配算法。5. 完整示例编写一个依赖漏洞审计 Skill下面我们编写一个可执行的 Custom Skill。假设你正在审计一个 Java Maven 项目需要自动扫描pom.xml中的依赖并与公开漏洞库比对。5.1 Skill 文件结构在项目根目录下创建如下目录结构project-root/ ├── .claude/ │ └── skills/ │ └── dependency-audit/ │ ├── SKILL.md │ └── scripts/ │ └── generate_report.py ├── pom.xml └── CLAUDE.md5.2 编写 SKILL.mdSKILL.md是这个 Skill 的入口描述Claude Code 通过它来理解技能用途、触发条件和执行步骤--- name: dependency-audit description: 审计项目依赖清单比对公开漏洞库生成依赖风险报告。适用于 pom.xml、package-lock.json、requirements.txt 等依赖文件。 --- # Dependency Audit Skill ## 目标 提取项目的第三方依赖清单调用 OSV-Scanner 等工具比对已知漏洞并输出结构化报告。 ## 输入 - 依赖文件路径默认自动查找项目根目录下的 pom.xml。 - 如需指定其他文件由用户显式提供。 ## 执行步骤 1. 确认依赖文件存在读取其中声明的组件 groupId、artifactId、version。 2. 检查 OSV-Scanner 是否已安装如果未安装提示用户安装不尝试绕过系统权限。 3. 运行 OSV-Scanner 扫描命令并保存原始输出 bash osv-scanner --lockfile dependency-file --format json reports/dependency-scan-raw.json使用 Python 脚本 scripts/generate_report.py 解析扫描结果生成 Markdown 报告。将报告写入 reports/dependency-audit-report.md并列出证据路径。输出格式报告必须包含以下字段组件名称当前版本漏洞编号如 CVE/OSV ID影响版本区间建议修复版本证据链接禁止事项本 Skill 只做审计不修改 pom.xml。未经用户明确授权不执行任何可能改变项目状态的命令。这里的关键是通过 YAML frontmatter 提供 name 和 description让 Claude Code 能理解何时使用该技能正文则用清晰的步骤约束 Agent 的行为。 ### 5.3 编写报告生成脚本 为了让输出更稳定我们提供一个辅助脚本把 OSV-Scanner 的结果转换成 Markdown 报告。以下是简化的 Python 示例 python # 文件路径.claude/skills/dependency-audit/scripts/generate_report.py import json import sys from datetime import datetime def main(raw_file, output_file): with open(raw_file, r, encodingutf-8) as f: data json.load(f) lines [ # 依赖漏洞审计报告, , f- 生成时间{datetime.now().isoformat()}, , | 组件 | 当前版本 | 漏洞编号 | 建议修复版本 |, | --- | --- | --- | --- |, ] for result in data.get(results, []): package result.get(package, {}) name package.get(name, unknown) version package.get(version, unknown) for vuln in result.get(vulnerabilities, []): vuln_id vuln.get(id, unknown) fixed 见漏洞库建议 lines.append(f| {name} | {version} | {vuln_id} | {fixed} |) with open(output_file, w, encodingutf-8) as f: f.write(\n.join(lines)) print(freport written to {output_file}) if __name__ __main__: if len(sys.argv) ! 3: print(usage: python generate_report.py raw.json output.md) sys.exit(1) main(sys.argv[1], sys.argv[2])这个脚本做了最小限度的解析实际项目中可以根据需要增加漏洞说明链接、严重级别分级等内容。它的作用是让 Skill 每次输出统一格式便于团队后续处理。5.4 编写 Secret 扫描 Skill除了依赖审计硬编码密钥也是最常见的高危问题。再写一个简单但实用的secret-scanSkill--- name: secret-scan description: 在项目源码和 Git 历史中搜索硬编码 API Key、Token、密码等敏感信息。适用于代码审计前期的信息暴露排查。 --- # Secret Scan Skill ## 执行步骤 1. 先以当前工作区为目标使用 ripgrep 或 grep 搜索常见敏感信息模式 bash rg -n (api[_-]?key|secret|token|password|passwd)[\]?\s*[:]\s*[\][A-Za-z0-9_\-]{16,} --glob !reports/** --glob !.git/** .如果项目包含 Git 历史可使用 git log 检查历史提交中是否出现过敏感信息。对匹配结果做人工可读的排序按文件路径分组。标记疑似真实密钥和测试密钥。输出 reports/secret-scan-report.md每个条目包含文件路径、行号、匹配片段和修复建议。禁止事项禁止将扫描到的密钥打印到非授权终端以外的位置。禁止尝试使用密钥登录任何系统。这里用 rg 作为搜索工具是因为它在大型仓库中速度更快、输出更友好。如果本地没有安装 ripgrep也可以更换为 grep 变体。 ## 6. 在真实项目中运行 Skill 并验证效果 Skill 写好后下面把它接入工作流并验证。 ### 6.1 启动会话并触发 Skill 在项目根目录启动 Claude Code bash claude然后在交互界面中可以显式告诉它要执行的技能请运行 dependency-audit Skill审计当前项目的依赖文件。此时 Claude Code 会读取.claude/skills/dependency-audit/SKILL.md按照其中的步骤开始执行。它会自动查找pom.xml检查 OSV-Scanner 是否可用运行扫描命令再调用generate_report.py生成报告。6.2 预期输出如果一切正常你会在reports/目录下看到reports/ ├── dependency-scan-raw.json └── dependency-audit-report.mddependency-audit-report.md的内容大致如下# 依赖漏洞审计报告 - 生成时间2025-01-15T10:30:00 | 组件 | 当前版本 | 漏洞编号 | 建议修复版本 | | --- | --- | --- | --- | | org.apache.logging.log4j:log4j-core | 2.14.1 | CVE-2021-44228 | 2.17.0 |6.3 如何判断运行成功成功标准不只是“命令没有报错”而是以下三点都满足原始扫描数据存在且能被解析。报告中每个条目都能通过某种方式回溯到证据比如依赖文件中的坐标和 CVE 信息。报告格式与 Skill 定义的输出格式一致团队成员能用同样的方式消费。如果报告为空先检查两个方向一是依赖文件路径是否被正确识别二是扫描工具是否真的产生了results数据而不是因为网络等原因静默失败。可以先用下面的命令在终端里手动验证osv-scanner --lockfile pom.xml --format json | head -50注意这里只是验证工具链路不是要求读者执行某个危险操作。真正的漏洞比对工具不会修改项目本身。7. 常见问题与排查思路实践过程中你可能会遇到下面这些问题。我把高频现象、原因和排查方式整理成一张表问题现象可能原因排查方式解决方案Claude Code 提示模型名无法识别API 网关或第三方模型标识与当前 CLI 版本不匹配检查claude --version和 API 配置的模型名升级 CLI 版本核对模型名是否在该版本支持列表中使用兼容网关的模型映射配置Skill 没有触发Agent 只按普通对话处理description描述不清晰或目录位置不对检查 Skill 是否放在.claude/skills/确认名称是否被正确引用缩短描述中的关键词显式请求“运行 xxx Skill”扫描命令执行失败依赖工具未安装或网络无法访问漏洞库手动运行osv-scanner --version查看错误输出安装工具配置代理使用离线漏洞库报告生成后字段缺失原始 JSON 结构变化查看dependency-scan-raw.json的字段调整脚本解析逻辑增加字段兼容性Agent 执行了看似越权的命令权限边界配置不足查看运行日志和权限配置在CLAUDE.md和工具权限中限制高风险命令设置 Permission Mode 为询问模式上下文过长导致任务中断项目文件太多上下文窗口被占满拆分任务范围先指定子目录或单文件使用更小的输入范围分批审计依靠 Skill 隔离上下文其中“模型名无法识别”是接第三方模型时非常高频的问题。它的常见原因不是 Skill 写错而是 Claude Code 版本内置的模型列表不包含你传入的标识。遇到时不要急着改代码先确认版本和模型名称的匹配关系再决定升级 CLI 还是调整 API 映射。这提醒我们任何 AI 工具链都依赖底层模型调用的稳定性排查时应该从“最小链路”入手即先确认模型能正常对话再叠加 Skill。另一个容易被忽视的问题是Claude Code 在自动执行多步操作时可能因为权限配置过宽而执行非预期命令。安全审计场景尤其危险——一个用于漏洞挖掘的 Agent 如果权限过大理论上也可能误改代码或访问未授权路径。所以权限配置不是“能不用就不用”而是安全自动化的必要组成部分。8. 最佳实践与安全边界8.1 合法授权与最小权限无论 Skill 写得多完善都必须坚持几个底线只审计你拥有、或已获得明确书面授权的代码和系统。扫描和分析命令只在测试环境、独立容器或本地沙箱中运行。不把生产环境的源码库直接暴露给未经验证的自动化流程。所有需要修改操作的任务默认关闭改为人工确认模式。Claude Code 提供了权限管理模式建议在首次运行时以“询问模式”执行确保每一条写操作或命令执行前都经过人工确认。不要图省事直接放开全部权限。8.2 Skill 的版本化与评审Skill 本质上是团队的安全知识资产应该像代码一样管理把.claude/skills/目录纳入 Git 版本控制提交信息写清楚变更内容。每个 Skill 至少经过一名有安全审计经验的人评审。当出现误报或漏报时先修订 Skill 的规则和描述再考虑替换工具。这会让团队在长期维护中感受到明显收益新成员不需要重新发明轮子资深成员的经验可以沉淀为标准化流程。8.3 结果必须人工复核自动化漏洞挖掘能帮你扩大排查面但 AI 生成的审计结论、CVE 影响判断和修复建议都不应该直接作为最终结论。建议建立这样的复核流程AI Skill 生成初步报告。安全工程师对高危条目做二次分析确认攻击路径是否真实存在。修复完成后再运行相关 Skill 做回归验证。把确认误报的样本反馈给 Skill 的维护者用于改进描述和过滤规则。这套机制的核心是把 AI 当作“扩大排查面的实习生”而不是“做最终裁决的安全负责人”。8.4 日志留痕与合规安全测试过程中会产生大量敏感信息包括漏洞详情、密钥片段、扫描命令。在输出日志时要注意脱敏避免把完整密钥写入普通日志。报告中的漏洞信息按需分享不要公开发布未授权系统的漏洞细节。对审计过程留痕是为了事后追溯和复盘也是合规的常见要求。9. 总结与后续学习方向通过前面的内容你实际建立了这样一套能力安装了 Claude Code理解了 Custom Skills 的结构和执行机制编写了依赖审计 Skill 和密钥扫描 Skill并把它们接入真实项目验证了结果。这套组合真正改变的地方在于它把安全审计从“依赖个人执行力和记忆”变成了“依赖工程化流程和版本化知识”。如果你想继续深入有几个方向值得探索把code-auditSkill 做成更精细的源码审计工具让它专注于追踪危险函数调用链并输出可复现的 PoC 分析。把dependency-audit接入 CI/CD在每次合并请求时自动生成依赖风险报告实现持续安全测试。给 Skill 增加更丰富的输出模板比如按 CVSS 严重级别排序并联动企业内部的漏洞管理平台。探索 Claude Code 桌面端和 VSCode 插件的不同工作流找到最适合团队协作的交互方式。最后再提醒一句AI 自动化漏洞挖掘是效率放大器不是安全免责牌。它能在几分钟内完成过去需要几小时的机械排查但最终的漏洞判断、修复决策和合规责任仍然在工程师自己身上。建议你先把这套流程用在一个自建项目或开源项目上跑通链路、验证产出的可信度再逐步推广到团队工作中。这样踩过的坑会成为你后续维护 Skill 最有价值的经验。