Security Audit Skill 保姆级教程：让 Claude Code 变成 AI 安全审计员，从代码扫描到漏洞报告完整实战

代码扫描有命中，却说不清它是不是漏洞，也不知道怎样写成能复核的报告。

最快解法：用 Security Audit Skill 把 Claude Code 设为按范围检查、调用已配置扫描工具、逐项核验证据并整理报告的辅助审计员；如果没有明确授权、可靠工具输出和人工复核，就不要把它的结论当成安全认证。

正在用 Claude Code、想把重复代码审查步骤标准化的开发者，可以按本文搭建工作流。
需要把扫描发现变成可追溯报告的安全工程师，可以重点看核验与报告格式。
评估 AI Agent 代码审计流程的技术负责人，可以据此检查权限边界和复测要求。

先明确 Security Audit Skill 能做什么、不能保证什么

Security Audit Skill 的作用，是保存一套可复用的指令和工作步骤；它不是新的扫描引擎，也不会自动证明某个命中可利用。Claude Code 可以理解项目上下文、阅读代码、按指令调用已有工具并归纳证据，但扫描工具只报告其规则或分析能力覆盖到的内容，人工审计负责判断上下文、影响和风险。

参与者	负责的工作	不应被默认承担的工作
Security Audit Skill	规定范围、检查顺序、证据标准和报告格式	自动保证指令每次都被严格执行
Claude Code	阅读授权代码、关联上下文、解释工具输出、起草报告	独立证明漏洞可被利用或确认不存在漏洞
已配置的扫描工具	按其规则和能力分析代码并输出发现	覆盖所有语言、业务逻辑和运行时条件
人工审计者	核对可达性、保护措施、影响和修复结果	仅凭模型总结跳过原始证据

因此，工作流的胜负手不是“让模型找出所有漏洞”，而是让每个结论都能回到代码位置、数据路径和工具输出。技能文件格式与手动调用方式以官方 Skills 配置说明为准；安全使用时还要对照权限规则文档和安全说明。

第一步：限定仓库、路径和审计目标

先把任务写成可检查的边界，而不是一句“把项目全部审一遍”。范围至少要说清楚：仓库是否获准、分支或工作区、允许读取的目录、使用的语言、重点风险，以及是否允许执行测试或扫描命令。对含真实凭据、用户数据或生产配置的仓库，先确认代码是否允许送入当前运行环境处理，并删除或替换不需要的敏感内容。

范围写法	示例	可能产生的结果
过宽	检查整个仓库的所有安全问题	任务边界不清，模型容易漏掉关键入口，或把无关文件中的模式当作风险
信息不足	检查登录功能	缺少入口文件、认证流程和预期检查类型，发现难以复核
可操作	只读检查授权仓库的 src/auth/ 与会话处理代码；优先核对认证绕过、权限校验和敏感数据暴露；只调用仓库中已配置的本地扫描命令	目标、路径、检查方向与工具边界明确，结果更容易回查

风险分类可以借助常见 Web 应用风险清单建立检查词汇，但它不是所有项目或漏洞类型的完整清单。软件弱点与具体漏洞也不能混为一谈；弱点与漏洞的定义说明强调，弱点是可能导致漏洞的条件，而漏洞是特定情境下可被利用并产生负面影响的实例。

如果团队要把审计纳入开发流程，可参考安全软件开发框架中的实践分组，将检查、修复和残余风险响应连起来；它提供的是框架，不会替项目决定具体规则。

第二步：创建可复用的审计技能文件

当前官方约定支持把项目级技能放在 .claude/skills/<技能名>/SKILL.md，以 YAML frontmatter 配合 Markdown 指令；技能可通过 /技能名 调用，也可能在描述匹配任务时被 Claude Code 加载。具体 frontmatter 字段应以官方文档为准，下面的模板只使用常见字段，团队应在自己的已安装版本上验证调用结果。

在已获授权的演示仓库中，可创建 .claude/skills/security-audit/SKILL.md：

---
name: security-audit
description: 对已授权仓库执行只读代码安全审查，核对扫描发现并生成证据化报告。
disable-model-invocation: true
---

# 审计边界
- 只检查用户明确授权的仓库与路径。
- 不读取或复制无关的密钥、令牌、个人信息和生产数据。
- 未获单独批准时，不修改文件，不执行会连接生产系统的命令。

# 执行顺序
- 确认仓库、目标目录、主要语言和审计目标；信息不足时先提问。
- 总结项目结构和相关入口，不猜测未读取的代码。
- 仅调用仓库已配置且经批准的本地扫描命令；保留原始输出。
- 对每个命中检查代码上下文、输入来源、数据流、权限条件和防护措施。
- 将发现区分为已确认风险、待核查项和误报，并说明依据。
- 输出带代码位置、证据、影响判断、修复建议和复测状态的报告。

# 不得作出的结论
- 不得声称扫描覆盖所有漏洞或保证代码安全。
- 没有可复核证据时，不得将推测写成已确认漏洞。

这里设置 disable-model-invocation: true，是为了让审计流程由操作者明确触发，而不是让模型自行决定何时开始；官方说明指出，该字段会阻止模型自动调用技能，但仍可由用户手动调用。完成文件后，在 Claude Code 会话中使用 /security-audit，再提供授权范围和审计目标。

扫描命令应由团队事先配置，不能靠技能文本临时臆造。示例中的 ./tools/security-scan 仅代表项目自有的包装脚本；先在隔离的演示仓库确认其参数、输出、网络行为和文件写入范围。需要把访问规则落实为机器可执行的限制时，应查看权限与设置文件说明；技能中的“不要读取某文件”是指令，不等同于操作系统级隔离。

⚠️ 不要为了让演示更顺畅而启用绕过权限提示的模式。Claude Code 的安全文档说明，权限模式会影响命令和文件操作的审批；扫描所需的最小权限应先验证，超出范围的调用则应停下来由操作者决定。

第三步：执行扫描，再逐项核对发现

建议在自建、无真实凭据的演示仓库中试跑。启动前确认当前目录确实是目标仓库，查看待审查分支和未提交变更；随后调用技能，明确哪些路径获准读取，并让 Claude Code 先复述审计范围。范围复述有遗漏时先纠正，再开始分析。

执行时分开保存两类材料：一类是扫描工具的原始输出，另一类是 Claude Code 对代码上下文的解释。模型摘要不能替代原始输出。若工具仅报告某行出现危险调用，而代码实际包含参数绑定、权限校验或可信来源约束，就要把这些上下文一并纳入判断。

以演示代码为例，扫描命中一处由请求参数拼接数据库查询的代码。核验时要检查请求参数是否可由外部控制、该函数是否进入实际调用路径、查询是否另有参数化处理，以及测试或调用者是否改变了风险条件。只看到字符串拼接不足以确认可利用性；反过来，代码附近没有明显防护也不足以证明没有其他层的约束。

核验状态	需要记录的依据	报告中的表述
已确认风险	代码位置、可控输入到敏感操作的路径、缺少有效防护及影响条件	“已确认”；列明证据和修复方向
待核查项	命中位置明确，但调用路径、输入控制或防护措施仍未查清	“待核查”；列出需要补充的代码、测试或配置
误报	存在可验证的参数化、不可控输入或其他有效控制	“误报”；说明具体保护机制，保留复核依据

扫描工具可能只检查特定语言、规则或代码形态；例如，规则匹配适合发现已定义模式，却不能因此推断业务权限逻辑、部署配置或所有跨文件数据流都已检查。若输出有规则名称、文件位置和片段，保留这些字段；如果工具没有报告某类信息，不要让 Claude Code自行补写成“工具已确认”。

第四步：把发现写成能复核的漏洞报告

报告的目标不是写得像结论，而是让另一位工程师能够从结论返回证据，并复现修复后的验证。建议每条发现采用固定字段：标题、弱点类型、受影响位置、证据、触发条件、影响判断、严重性依据、修复建议、验证状态和复测结果。严重性不能只复制工具标签；应结合受影响资产、权限条件、输入可控性和实际影响解释。

例如，将“模型认为这里可能有 SQL 注入”改写为：“待核查：请求参数被拼接进查询构造；受影响位置为会话查询处理函数。当前记录尚未证明该参数可由外部控制，也未确认调用路径。下一步检查请求入口和数据库调用，并验证是否存在参数化处理；确认前不标为已确认漏洞。”如果这些条件经代码与测试验证，再将状态改为已确认，并附上可定位的证据和修复后的复测记录。

分类时可以使用通用弱点词汇，但标签不能代替论证。比如，常见风险分类用于帮助团队统一沟通；弱点编号用于描述问题类型；漏洞报告仍须说明该问题在当前项目中的实际影响。只要路径、调用者或运行时保护尚未查清，就保留待核查状态，不要把“可能造成”写成已经发生。

FAQ：把配置和人工复核边界说清楚

Security Audit Skill 应该怎样设置，才能让 Claude Code 检查代码安全问题？

在项目的 .claude/skills/security-audit/SKILL.md 中写清授权仓库、目标目录、语言、重点风险、只读要求和证据格式；再让 Claude Code 读取结构并调用团队已经安装、配置和批准的扫描命令。先限定小范围验证结果，再逐步扩大范围，不要把模糊的“检查全部安全问题”当作审计标准。

怎样把 Claude Code 的代码扫描发现整理成可复核的漏洞报告？

每条记录都应包含问题类型、文件与代码位置、相关代码上下文、工具输出或数据流证据、影响条件、修复建议及复测状态。先把扫描命中写成“待核查”，确认输入可控、路径可达且缺少有效防护后，才标为已确认风险；无法验证的影响要明确写成假设。

Claude Code 应该如何验证并分级 Security Audit Skill 扫描出的漏洞？

先回到命中位置检查上下文，再从输入来源追踪到敏感操作，确认实际调用路径、权限条件、过滤或参数化措施，并与已配置扫描工具的原始输出对照。分级要依据可利用条件、数据敏感度和业务影响，而不是只看模型措辞或工具严重性标签；缺少证据时保留待核查状态。

使用 Security Audit Skill 审计代码时，哪些内容不能省略人工复核？

人工复核授权范围、凭据与个人信息暴露、访问控制和业务逻辑、跨文件数据流、误报判断、风险等级、修复是否破坏功能，以及复测结果。还要确认工具实际扫描了哪些路径和规则；未覆盖的语言、依赖、运行时配置或部署环境不能被报告成“已审计通过”。

最后按清单验收，并决定是否升级人工评估

• [ ] 已确认仓库、分支和目标目录均获授权，且技能没有扩大审计范围。
• [ ] 已确认敏感信息处理方式；报告与会话中没有不必要的真实密钥、令牌或用户数据。
• [ ] 原始扫描输出与 Claude Code 的解释分开保存，结论能回溯到具体代码位置。
• [ ] 每个高影响或涉及身份验证、访问控制、敏感数据的发现都由安全人员复核。
• [ ] 未覆盖的语言、规则、依赖、运行时配置和部署环境已明确标注，而不是默认视为无风险。
• [ ] 修复后重新运行相关检查，并记录验证状态；未复测的发现不得写成已解决。

只要审计涉及真实凭据、跨服务授权、复杂业务规则，或模型与工具对同一发现给出相互矛盾的解释，就应让安全工程师进一步评估。即使所有已知命中都被处理，也只能说明这些检查项的状态发生了变化，不能据此宣称整个系统没有漏洞。

如果当前流程依赖开发者个人电脑，常见代价是审计与日常开发共用工作环境、权限边界不易统一、长时间运行的检查会与本地任务争用资源；换成远程环境，则需要额外核对仓库访问、数据留存和网络权限。当团队需要远程 Mac 开发环境，或需要在相对独立的机器上运行审计流程时，Zutcloud 的云端 Mac 可作为一种环境选择；它不会替代扫描配置、权限治理或人工复核。可先查看云端 Mac 租用信息，再通过帮助中心核对服务与操作细节。若代码不能离开本地、工作负载长期稳定且需要物理接口，自有设备可能更合适；若要试用远程环境，则从已获授权的演示仓库和上述清单开始。