用 Claude Code 做实用安全审计

不要把安全审计完全交给 AI

Claude Code 很适合加速安全审计。它可以阅读路由、检查 PR 差异、整理依赖风险、搜索危险日志、发现环境变量使用点，并把重复的审查习惯变成清单。真正的风险通常不在一个文件里，而是散落在认证中间件、权限判断、账单任务、Webhook、CI 和日志中。

但安全审计不能只问一句“帮我检查安全”。这样得到的回答往往像通用建议，看起来完整，却不能支持发布决策。审计需要明确范围、资产、威胁、控制措施、证据和剩余风险。Claude Code 是调查员和整理者，不是业务风险的最终负责人。

本文介绍一套适合初学者的实务流程：如何用 Claude Code 做范围定义、资产清单、威胁模型、依赖审查、认证和会话审查、密钥审查、输入验证、日志和 PII 检查、CI 门禁，以及证据回执。外部基线可以参考 OWASP Top 10、OWASP ASVS、NIST SSDF 和 GitHub 的 secret scanning。

先固定审计范围

第一步不是让 Claude Code 直接修代码，而是写清楚审计简报。范围会告诉它要看什么、不要改什么、允许运行哪些命令、完成标准是什么。没有范围时，AI 很容易只评论显眼的代码，却漏掉管理后台、账单、后台任务、部署脚本或 CI secrets。

可以直接复制下面的模板。实际项目中，再补上目标 URL、PR 链接、发布时间和命令权限。

# 安全审计简报

## 目标
- 在发布前发现认证、授权、密钥、输入验证、日志和依赖中的高风险问题
- 不只给修复建议，还要留下证据和剩余风险

## 范围
- 仓库:
- 分支或 PR:
- 功能或业务流程:
- 可以检查的目录:
- 不允许修改的目录:
- 可以运行的命令:

## 重点
- 认证和会话
- 授权和角色
- 输入验证和输出编码
- 密钥和环境变量
- 依赖和许可证
- 日志、PII 和审计事件
- 应该阻止发布的 CI 条件

## 完成标准
- 把发现项写入风险登记表
- 只记录必要的复现背景
- 不记录真实密钥、客户数据或危险攻击步骤
- 在证据回执中记录命令、结果、跳过范围和需要人工判断的事项

简报写好后，先要求 Claude Code 做地图，而不是修复：“列出路由、认证中间件、外部 API、环境变量、日志点、CI job 和高风险文件；暂时不要修改代码。”这样人类审查者可以先确认有没有漏掉关键区域。

建立资产清单和威胁模型

安全审计的起点是“要保护什么”。资产包括用户资料、账单状态、API key、管理后台、审计日志、上传文件、客服消息和分析数据。威胁模型就是一张小地图：谁可能从哪个入口进入，想影响什么，应该由哪个控制措施拦住。

| 资产 | 存放位置 | 入口 | 可能威胁 | 必要防护 | 负责人 |
| --- | --- | --- | --- | --- | --- |
| 用户邮箱 | users table | signup, admin | 未授权读取、日志泄露 | 授权检查、PII 脱敏、审计日志 | backend |
| 账单状态 | billing table, Stripe | webhook, admin | 篡改、重复处理 | 签名验证、幂等性、角色检查 | backend |
| API key | env, secret manager | CI, runtime | 仓库泄露、日志暴露 | secret scanning、轮换、最小权限 | platform |
| 管理后台 | /admin | browser | 权限提升 | MFA、admin role、操作日志 | product |

把这张表交给 Claude Code 后，可以继续要求它补充信任边界和测试。信任边界是可信区域和不可信输入之间的分界线。浏览器输入、Webhook、上传 CSV、Markdown、文件名、第三方 API 响应，都应该先视为不可信，再进行验证、标准化或转义。

给 Claude Code 明确审查通道

依赖审查要看 package.json、lockfile、Docker 镜像、GitHub Actions、运行时版本和传递依赖。npm audit 只是入口，不是完整结论。让 Claude Code 区分生产可达风险和开发依赖噪声，说明升级是否有破坏性变更，并列出升级后需要通过的测试。

认证和会话审查要看登录、退出、密码重置、MFA、OAuth、cookie 属性、会话过期、CSRF 保护和服务端授权。“用户已登录”和“用户有权做这个操作”是两个问题。管理 API、账单操作、文件下载、路径中的 user id、可重放的 webhook，都容易出现授权缺口。

密钥审查要覆盖 .env、CI secrets、示例配置、README、日志、截图和测试 fixture。不要让 Claude Code 把真实密钥贴到对话中。发现疑似密钥时，只记录文件位置、类型、轮换建议和负责人，值必须打码。使用 GitHub 时，也要确认 secret scanning 和 push protection 的状态。

输入验证审查要追踪数据从哪里进入，又在哪里保存、渲染或转发。不要要求 Claude Code 生成危险 payload。更好的要求是：检查边界验证、类型检查、标准化、输出转义和测试用例。对初学者来说，按数据流追踪比背漏洞名称更可靠。

日志和 PII 审查要检查邮箱、姓名、地址、token、cookie、认证 header、支付 ID 和自由文本是否进入日志。开发期的 console.log 如果进入生产日志，就会成为保留和泄露风险。日志应只保留排障和审计需要的最少字段。

四个常见使用场景

第一个场景是 SaaS 发布前审计。新增账单、邀请、组织设置或管理后台前，让 Claude Code 阅读 PR diff、migration、路由、webhook、测试和 CI。目标不是得到“完全安全”的承诺，而是生成发布会议可以讨论的风险登记表。

第二个场景是 GitHub 仓库交接审计。接手仓库时，风险常藏在部署脚本、CI secrets、环境变量命名、手工 runbook 和无人负责的目录里。让 Claude Code 输出第一周交接清单：哪些 key 要轮换，哪些流程要文档化，缺少哪些 CI 门禁，哪些部分需要原负责人确认。

第三个场景是事故后的跟进审计。出现故障或疑似泄露后，不要只修触发事故的一行代码。让 Claude Code 搜索相似模式、检查日志中的 PII、提出回归测试、更新 CI 门禁，并整理内部复盘。公开说明要强调影响和修复，避免传播可直接复用的攻击细节。

第四个场景是 AI 生成 PR 的安全审查。AI 写出的代码常常格式整齐，但可能漏掉授权、错误处理、审计日志或测试。可以让 Claude Code 只审查差异的安全影响：攻击面、权限、密钥、个人数据、依赖变更和 CI 覆盖。范围越窄，结论通常越有用。

留下风险登记表和证据回执

发现项要有证据。仅写“High”或“Medium”不够，必须说明影响、观察位置、建议修复、负责人和未确认事项。

| ID | 风险 | 影响 | 证据 | 建议措施 | 优先级 | 状态 | 负责人 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SEC-001 | 管理 API 缺少授权检查 | 可能修改其他用户数据 | routes/admin.ts 未检查角色 | 添加中间件和回归测试 | High | Open | backend |
| SEC-002 | Webhook 日志包含邮箱 | 不必要保存 PII | logs/webhook-sample.txt | 邮箱脱敏并缩短保留期 | Medium | Open | platform |

证据回执可以避免审计变成散落的聊天记录。它不需要很长，但要能说明审计确实做过。

# 安全审计证据回执

- 目标:
- 日期:
- 审查人:
- 交给 Claude Code 的范围:
- 执行的命令:
- 检查的文件或目录:
- 高风险发现:
- 已修复项目:
- 跳过或范围外项目:
- 需要人工判断的事项:
- 发布建议:

PR 审查清单

团队可以把下面的清单贴进 PR 审查提示。对于 AI 生成的改动，它能把讨论拉回风险，而不是只看代码风格。

## Security PR Review

- [ ] Scope is clear and no unrelated files are changed
- [ ] Authenticated users cannot access another user's data
- [ ] Admin or billing actions require explicit authorization
- [ ] Inputs are validated at the boundary
- [ ] Outputs are escaped or rendered safely
- [ ] No secrets, tokens, cookies, or PII are printed to logs
- [ ] Dependency changes have a reason and test evidence
- [ ] Errors do not reveal internals
- [ ] CI includes lint, tests, typecheck, and security-relevant checks
- [ ] Risk register and evidence receipt are updated

命令检查清单

不同项目命令不同，但 Node 或 TypeScript 项目可以从下面开始。让 Claude Code 在执行前说明命令目的，失败时停止并总结风险变化。

git status --short
npm ci
npm audit --audit-level=moderate
npm run lint
npm run typecheck
npm test
rg -n "TODO|FIXME|console\\.log|process\\.env|localStorage|innerHTML|dangerouslySetInnerHTML" src
git diff --check

rg 的结果只是线索，不是判决。process.env 可能是正确用法，innerHTML 如果经过安全处理也可能被允许。要求 Claude Code 区分证据、假设和确认方法，而不是把每个匹配都说成漏洞。

常见失败和陷阱

最大的失败是提示太模糊。只写“检查安全”会得到浅层回答。更好的提示要说明范围、资产、发布日期、允许命令、高风险流程和输出格式。明确写出“未审查”的报告，比没有证据的自信结论更有价值。

第二个失败是没有证据。没人知道执行过哪些命令、检查过哪些文件、哪些范围被跳过时，审计就无法支撑发布决策。要回到 CI 输出、测试、diff、日志和配置文件来确认 Claude Code 的说法。

危险的失败是公开太多细节。不要在公开 Issue、文章或评论里放真实 URL、token、客户数据或逐步攻击说明。公开内容应聚焦影响和修复，敏感复现信息放到受限系统中。

还要特别重视密钥和日志。应用代码看起来安全，也可能通过 CI 日志、调试截图、示例 .env 或详细错误泄露信息。认证、支付、个人数据和管理后台这类高风险变更，不能只靠 AI 审查，必须有人类负责人确认。

放进 CI 和团队习惯

一次性的审计很快会失效。至少把 lint、typecheck、test、dependency audit、secret scanning、危险 API 搜索和日志规则放进 CI。不是所有警告都要阻塞构建。实务上可以让 High 风险阻塞，Medium 进入带期限的 ticket，Low 放入定期维护。

Claude Code 本身的权限和工具访问也要管理。可以结合 Claude Code 权限指南、密钥管理、安全失败案例 和 代码审查工作流 一起阅读。如果团队想把审计简报、CI 门禁和审查标准落到真实仓库里，可以从 Claude Code 培训与导入咨询 开始。

总结

Claude Code 在安全审计中的价值，不是替人类负责，而是把调查、整理和重复检查做得更快。只要先定义范围、资产、威胁模型、审查通道、风险登记表、证据回执和 CI 门禁，它就能成为可靠的审计助手。没有范围、没有证据、没有人工复核的审计，即使报告写得漂亮，也很难解释系统是否可以发布。

Masa 把这套流程用于 ClaudeCodeLab 的发布前检查后，最有用的是风险登记表和证据回执。先让 Claude Code 棚卸路由、日志、环境变量和 CI，再由人类确认，能更快看见未确认事项。结果不是“绝对安全”的保证，而是一个更清楚、能被团队讨论的发布判断。