claude code 输出代码中敏感信息泄露的检测方法

去年冬天，我在一个凌晨两点被 PagerDuty 叫醒。安全团队在公司的公共 GitHub 仓库里扫到了一组有效的 AWS Access Key，来源是一次看似无害的代码提交，那段代码是我让 Claude Code 帮忙写的。我没有检查输出，直接复制粘贴，然后 git push。8 小时后，那个密钥被用于在 us-east-1 启动了 47 台 EC2 竞价实例，全部在挖 Monero。

这件事之后，我花了整整两周时间，只做一件事：搞清楚 Claude Code 输出的代码中，到底藏着哪些我们肉眼容易忽略的敏感信息，以及如何在它们进入任何远端仓库之前被捕获。

这篇文章就是那次事故的完整复盘和方法总结。不讲百科知识，不复制别人的工具列表，只讲我亲手验证过的检测逻辑、工具选择策略和在真实 CI/CD 流水线里踩过的坑。

一、先给结论：Claude Code 敏感信息泄露的核心问题不在代码里，在“信任转移”上

大多数开发者对 Claude Code 安全性的传统认知是：“它不会主动泄露我的密钥吧？” 这句话只对了一半。Claude 确实没有主动窃取你的 .env 文件并塞进输出里，但问题在于：当你把一段代码任务的上下文交给它时，它会从上下文中推断并“好心”补全那些看起来像配置项的字符串。

我做了 300 次对照实验：给定相同的 Prompt 但不同的上下文环境，统计 Claude Code 输出中包含敏感信息的频率。结果如下：

• 上下文中有 API 文档链接：输出中出现格式正确的 API Key 占位符（如 sk-xxxxxxxxxxxxxxxxxxxx）的概率为 23%。注意，这里是“格式正确”，意味着它遵循了真实密钥的正则模式，某些情况下甚至能通过基础校验。
• 上下文中有数据库 Schema：输出中包含 jdbc:mysql://internal-db.prod:3306/userdb 这类连接字符串的概率高达 41%。
• Prompt 中明确写了“请参考我之前用的配置”：输出中直接复用之前对话中硬编码密码的概率为 17%。

Claude Code 的“智能”在于它会努力让代码“能跑起来”。为了让代码看起来完整可用，它会倾向于填补那些看起来像占位符但实际上可能是真实信息的空白。这个行为本身不是 Bug，但开发者在快速迭代时形成的“信任惯性”会让我们忽略这件事：我们默认 AI 输出的代码是“干净的”，不再像审查同事 PR 那样去审查 AI 的输出。

这就是信任转移的问题：我们把对代码质量的信任，无意识地从“人工审查”转移到了“AI 已审查”，但 AI 并没有审查过自己输出的内容是否包含敏感信息。

二、我只认一个检测原则：分层拦截，而不是事后扫描

那次凌晨事故之后，安全团队的建议是“在 CI/CD 中加一个扫描步骤”。听起来很合理，对吧？但这是我犯的第二个错误。

事后扫描的问题是延迟。从代码 push 到仓库、到扫描任务触发、再到告警发出，中间有 3 到 15 分钟的窗口。如果攻击者的脚本在监听公开仓库的变更事件，这个窗口足够他们抢在安全团队前面行动。

我当时查了那 47 台 EC2 实例的启动时间：最早一台在代码提交后 4 分 12 秒就启动了。而安全团队的扫描告警在 8 分钟后才发到我手机上。

所以我现在的检测策略完全变了：我不再依靠单一工具或单一步骤，而是把检测拆成三层，Prompt 层、Pre-commit 层、CI/CD 层。每一层的目标不同，检测精度不同，但合在一起形成一个闭环。

下面是我现在在项目里强制执行的检测架构：

第一层是源头控制，第二层是最后一道人为防线，第三层是审计兜底。 顺序不能乱。如果你只在 CI/CD 里扫描，等于把炸弹先扔到公共区域再去拆。

三、把 Claude Code 的 Prompt 变成第一道防火墙，这招大多数人没用

讲一个你可能没想过的角度：Claude Code 本身就可以成为你的安全检测工具。 关键不在于让它“不要泄露密钥”，而在于改变它的输出行为模式。

直接说“不要输出密钥”效果很差。我测试过三种 Prompt 策略：

策略 A（无效）：“请不要在生成的代码中包含任何 API 密钥或密码。”

• 结果：Claude 会照做，但它会用 your-api-key-here 这种占位符，这在很多自动化脚本里直接被当作合法字符串处理，不会触发任何检测。

策略 B（部分有效）：“请使用 <YOUR_API_KEY> 格式的占位符，并在代码注释中说明需要替换。”

• 结果：占位符变得容易被 grep 搜索到，但如果开发者忘记全局替换，代码依然能编译通过，问题会延迟到运行时才暴露。

策略 C（我目前使用的）：在 System Prompt 中加入三层约束，

1. 占位符规范：所有密钥、密码、Token 必须使用 __CONFIG_REQUIRED__ 作为占位符，这个字符串会在 Pre-commit 钩子中被自动检测并拦截。
2. 运行时校验注入：在每个需要密钥的函数入口，自动插入断言逻辑，检查密钥是否为占位符，如果是则抛出明确错误。
3. 禁止输出任何符合 Base64 模式的字符串：JWT Token 通常以 eyJ 开头，Claude 生成测试数据时很容易无意中构造出合法的 JWT 格式。

我在 .claude.yaml 中的配置是这样的：

system_prompt: |
安全约束规则：

所有认证凭证使用 "__CONFIG_REQUIRED__" 作为占位符。
在函数入口添加 assert api_key != "__CONFIG_REQUIRED__", "请替换为真实密钥"。
禁止生成以 eyJ 开头且长度超过 100 字符的连续字符串。
如果上下文中包含任何疑似真实密钥的模式（如 sk- 开头），请直接忽略并以占位符替换。

这套策略实施后，Claude 输出中包含可被正则匹配的密钥模式的概率从 23% 降到了 2%。更重要的是，剩下的 2% 会因为 __CONFIG_REQUIRED__ 这个占位符在第层被直接拦截，不会进入 commit。

四、Pre-commit 钩子不是“加了就行”，我踩过的两个大坑

Pre-commit 是我最看重的防线，因为它是人为操作的最后一个阻断点。一旦 commit 成功，控制权就交给了自动化流程，而自动化流程总是有窗口期的。

我使用 TruffleHog 作为 Pre-commit 扫描引擎，原因是它专门针对“高熵字符串”做了优化，不像通用正则那样容易遗漏变体密钥。但在实际配置中，我踩了两个坑，几乎让这层防线形同虚设。

4.1 坑一：熵阈值设置不当导致误报海啸

TruffleHog 的默认熵阈值是 3，这个值对于 JavaScript 项目来说太低了。一个稍微复杂的 Webpack 打包后的 chunk 文件名就可能触发误报。我第一次部署时，团队一个上午收到了 200 多条 TruffleHog 告警，其中 98% 是误报。结果是所有人都在 .trufflehog-ignore 里加了全局排除规则，真正的告警反而被漏掉了。

我的调整策略：

• 对于前端项目（React/Vue）：熵阈值提高到 5.5，同时缩小扫描范围到 src/ 和 config/ 目录。
• 对于后端项目（Node/Python）：熵阈值保持在 4.5，但排除 node_modules/、__tests__/ 和 .log 文件。
• 对所有项目：强制启用 TruffleHog 的“验证模式”，即发现疑似密钥后尝试调用 API 验证其有效性。这一步会显著降低误报，但会增加 2-3 秒的扫描时间。

4.2 坑二：Pre-commit 钩子被开发者静默跳过的情况

git commit --no-verify 是一个合法的 Git 命令，并且在 CI 压力大的时候经常被使用。如果你只在 .git/hooks/pre-commit 里配置了扫描，这个钩子随时可以被绕过。

我的补救措施：在 CI/CD 阶段的第一步强制做 Pre-commit 等效扫描，并且这个扫描不允许被跳过。 如果 CI/CD 的等效扫描发现任何密钥，即使 Pre-commit 被跳过了，构建也会直接失败并将开发者信息记录到安全审计日志中。这样做的目的不是惩罚，而是确保“跳过 Pre-commit”这个行为必须承担后果，从而形成行为规范。

五、Claude Code 输出的“非标准敏感信息”，正则表达式抓不到的东西

在我参与的两个实际项目中，真正造成安全事件的信息有两种：

1. 一个 AWS Account ID（12 位数字），本身不是密钥，但它和 IAM 角色名组合后，可以直接被用于跨账户攻击。
2. 一个内部服务完整的 gRPC 端点地址，格式是 grpc://internal-service.prod.svc.cluster.local:50051/AdminService。这串信息里没有密钥，也没有密码，但任何能访问 K8s 集群内网的攻击者都能直接 RCE。

标准检测工具（TruffleHog、GitLeaks、Semgrep）都抓不到这些。 因为它们不符合任何已知密钥模式，熵值也不高。

我发现这个问题后，开始在 ClCode 输出检测中加入项目级自定义规则。这些规则不是通用的，而是根据每个项目实际的敏感字符串特征来定制的。

以我曾经负责的一个微服务项目为例，我定义了三类非标准敏感信息规则：

• 内部服务发现地址：匹配 svc.cluster.local 或公司内部域名后缀 .internal.xxx.com。
• 基础设施标识符：匹配 AWS Account ID 模式（12 位纯数字，后接 IAM 角色名）。
• 调试端点：匹配 /debug/、/actuator/、/admin/console 等路径。

这些规则以简单的 grep 正则形式写进了 Pre-commit 钩子和 CI/CD 扫描步骤。它们不会精确定位“密钥”，但它们能标记出“不应该出现在公开代码中的内部信息”。

关键点：这些规则必须由项目负责人和安全工程师共同维护，不能由开发者自行添加或删除。 因为开发者可能为了绕过某些告警而修改规则，这会让整个检测系统形同虚设。我当时是让安全团队维护一个中央化的规则仓库，各项目通过 .sensitive-rules 文件引入，这个文件每次修改都需要安全团队 PR 审批。

六、双引擎扫描策略：为什么我用 GitLeaks + Semgrep，而不是二选一

很多文章会告诉你“用 GitLeaks 就够了”或者“Semgrep 是更好的选择”。我两个都部署过，可以很明确地说：它们是互补的，不是替代关系。

6.1 GitLeaks 擅长什么

GitLeaks 的核心优势是针对 Git 历史的全量扫描。如果你把 Claude Code 的输出嵌入到代码中，然后提交，GitLeaks 不仅扫描当前 commit，还会回溯整个 commit 历史中的每一个版本。这意味着即使你后续删除了敏感信息并重新提交，原始的泄露依然会被检测到。

另外，GitLeaks 对“熵+模式”的组合判断做得很好。它不会因为一长串随机字符就告警，而是会检查这个字符串是否同时满足“高熵 + 已知密钥格式前缀（如 AIza、ghp_、xoxb-）”。这大大降低了误报率。

我在 CI/CD 中的 GitLeaks 配置：

# .github/workflows/security.yml
name: Secret Scan

on: [pull_request]

jobs:

gitleaks:

runs-on: ubuntu-latest

steps:

uses: actions/checkout@v3

with:

fetch-depth: 0  # 必须拉取全部历史，否则只能扫当前commit

name: Run GitLeaks

uses: gitleaks/gitleaks-action@v2

env:

GITLEAKS_CONFIG: .gitleaks.toml

6.2 Semgrep 擅长什么

Semgrep 的优势是结构化语义分析。它可以“理解”代码的语义，而不仅仅是文本匹配。举个例子：Claude Code 可能生成一个 Python 函数，参数名是 password，但值从一个配置文件读取。GitLeaks 会错过这个，因为代码中没有明文密码。但 Semgrep 可以通过模式匹配识别出“一个名为 password 的参数被直接赋值给了某个变量，而这个变量随后被用于构建 HTTP 请求”。

这是我写的一条 Semgrep 规则，用来检测 Claude Code 输出中常见的“硬编码密码传入 requests 库”的模式：

rules:

id: hardcoded-password-in-requests

patterns:

pattern: |

requests.$METHOD(..., auth=($USERNAME, $PASSWORD), ...)

metavariable-regex:

metavariable: $PASSWORD

regex: '["\'].*["\']'

message: "检测到硬编码密码直接传入 requests 调用，可能来自 AI 生成代码未审查。"

languages: [python]

severity: ERROR

6.3 双引擎的协作模式

我在 CI/CD 流水线中并行运行这两个引擎。原因是它们扫描的维度不同：

• GitLeaks 负责“横向覆盖”：扫描所有文件、所有历史、所有分支。
• Semgrep 负责“纵向深入”：对特定语言、特定模式做语义级分析。

如果一个 PR 同时触发 GitLeaks 和 Semgrep 的告警，那么必须两个引擎都通过才能合并。任何一方告警都会将 PR 标记为“Blocked”，并要求开发者提供解释。

并行运行带来的另一个好处是时间优化。GitLeaks 全量扫描需要 30-45 秒，Semgrep 需要 20-30 秒，并行后总耗时约 50 秒，完全可以接受。

七、Claude Code 输出的 JWT Token 问题，一个被严重低估的风险

在测试 Claude Code 的过程中，我发现一个特别隐蔽但危险的行为：当 Prompt 中要求生成包含认证逻辑的示例代码时，Claude 会以一定概率生成格式完全合法、内容为虚构但结构真实的 JWT Token。 这些 Token 不包含真实用户数据，header 和 payload 都是示例，但它们的签名部分是不合法的（因为 Claude 不知道签名密钥）。

问题出在哪里？很多开发者在测试环境中会直接复制这段代码，并且仅仅替换 payload 中的内容，而忘记重新生成签名。如果这个行为发生在生产环境的前置测试阶段，就会导致一个奇怪的状态：认证中间件可能会因为签名验证失败而吃掉异常，从而在某些边界条件下错误放行请求。

我亲眼见过一个案例：团队用 Claude 生成的 JWT 认证中间件代码作为模板，修改了 payload 但保留了原始的签名验证逻辑（使用了 verify_signature=False 的调试参数）。代码通过了 CI/CD 的安全扫描（因为没有明文密钥），上了生产，导致一个未授权访问漏洞存活了 11 天。

针对这个问题，我在检测体系中加入了一条专门针对 JWT 的规则：

1. Pre-commit 阶段：使用自定义脚本扫描代码中所有以 eyJ 开头的字符串，提取出来并尝试 base64 解码 header 和 payload。如果解码成功且 payload 中包含 "sub"、"iat"、"exp" 等标准 JWT 字段，则标记为“疑似 JWT Token”。
2. CI/CD 阶段：使用 Semgrep 规则检测是否显式设置了 verify_signature=False 或 verify=False 这类关闭签名验证的参数。
3. 代码审查强制要求：任何包含 JWT 逻辑的 PR，必须附带 Reviewer 对签名验证逻辑的确认。

这个规则上线后，我们在三个不同的服务中发现了以这种方式残留的调试代码。其中一个服务已经上线 4 个月，从未有人注意到那个 verify=False 的参数。

八、我在四个真实项目中落地这套检测方案的复盘数据

下面是我在四个不同规模的项目中实施上述检测方案后，记录的 6 个月数据。通过这些数据，可以很直观地看到检测流程的实际效果和成本。

项目 A：SaaS 后端（Python/Go 混合，12 人团队）

• 6 个月内总 commit 数：3,842
• Pre-commit 钩子拦截的含密钥 commit：47 次（1.2%）
• 其中确认为真实密钥的：11 次（23.4%）
• CI/CD 补拦的漏网密钥：3 次
• 平均修复时间：从发布前的 18 分钟缩短到 4 分钟

项目 B：移动端 API 网关（Node.js，5 人团队）

• 6 个月内总 commit 数：1,560
• Pre-commit 拦截：23 次（1.5%）
• 真实密钥确认：8 次（34.8%）
• 最严重的一次：拦截了一个硬编码的 Stripe Secret Key，该密钥有权限退款和创建支付。如果泄露，损失上限为账户余额。
• CI/CD 补拦：0 次（因为 Pre-commit 覆盖了所有泄露类型）

项目 C：数据分析平台（Python，3 人团队，大量使用 Claude Code）

• 6 个月内总 commit 数：2,180
• Pre-commit 拦截：61 次（2.8%）
• 真实密钥确认：19 次（31.1%）
• 自定义规则捕获的非标准敏感信息：7 次（全部为内部数据库连接字符串）
• CI/CD 补拦：1 次
• 特殊发现：该团队使用 Claude Code 的比例最高，拦截率也最高，证实了 AI 生成代码与敏感信息泄露的正相关性。

项目 D：内部运维脚本库（Shell/Python，2 人团队）

• 6 个月内总 commit 数：970
• Pre-commit 拦截：9 次（0.9%）
• 真实密钥确认：6 次（66.7%）
• 最严重的一次：拦截了一个包含生产环境 K8s 集群 kubeconfig 的 commit。
• CI/CD 补拦：0 次

九、三个行动方案：根据你的团队规模和风险承受力选择

我不建议所有团队都实施完整的“三层检测+双引擎扫描”。这需要投入时间维护规则、处理误报、培训团队。我根据实践经验，整理了三套方案，分别对应不同的团队规模和风险承受力。

9.1 轻量方案：单引擎 + 基础 Prompt 策略

适用场景：5 人以下团队、项目处于早期阶段、无专职安全人员。

配置清单：

1. Prompt 层：在 Claude Code 的 System Prompt 中加入策略 C（三层约束）。
2. Pre-commit 层：安装 TruffleHog Pre-commit 钩子，使用默认配置但启用验证模式。
3. CI/CD 层：在 GitHub Actions 或 GitLab CI 中运行 GitLeaks，扫描当前 PR 的 diff（不扫描全量历史以降低时间成本）。
4. 自定义规则：暂不部署，但要求 Code Review 时人工检查内部地址和调试端点。

优点：部署时间 < 2 小时，维护成本低，误报率可接受。

缺点：历史泄露无法追溯，非标准敏感信息无法检测。

9.2 标准方案：双引擎 + 分层检测

适用场景：10-30 人团队、有核心业务数据、有兼职安全负责人。

配置清单：

1. Prompt 层：策略 C + 上下文净化脚本（在调用 Claude API 前自动移除 .env、credentials.json 等文件引用）。
2. Pre-commit 层：TruffleHog + 分项目熵阈值调整 + 自定义 JWT 检测脚本。
3. CI/CD 层：GitLeaks 和 Semgrep 并行扫描，任一告警阻断合并。
4. 自定义规则：由安全负责人维护项目级自定义规则，存储在中央仓库，通过 .sensitive-rules 引入。
5. 审计日志：记录所有 Pre-commit 拦截和 CI/CD 阻断事件，每月 Review 一次。

优点：覆盖标准和非标准敏感信息，历史扫描完整，阻断及时。

缺点：初期误报需要 1-2 周调优，需要有人持续维护自定义规则。

9.3 严格方案：全链路 + 自动化响应

适用场景：30 人以上团队、处理金融/医疗等强合规数据、有专职安全团队。

配置清单：

1. Prompt 层：策略 C + 上下文净化 + 企业级 Prompt 网关（所有对 Claude API 的请求都经过安全审查）。
2. Pre-commit 层：同标准方案 + 强制 commit 消息模板（要求开发者在消息中声明“已检查 AI 生成代码的安全性问题”）。
3. CI/CD 层：GitLeaks + Semgrep + 第三方商业扫描工具（如 GitGuardian），三引擎并行，形成“投票机制”，三个引擎中两个同时告警才阻断，减少单一引擎的误报影响。
4. 自定义规则：安全团队每季度更新一次规则库，并基于历史事件进行回归测试。
5. 自动化响应：一旦检测到特定级别的密钥泄露（如 AWS Root Key），自动触发密钥轮换脚本，并向安全团队发送即时告警。

优点：几乎消除泄露进入生产环境的可能性，合规审计友好。

缺点：初始部署周期 2-4 周，需要专职安全工程师 0.5 FTE 维护。

十、Claude Code 敏感信息泄露的“长尾问题”，模型更新导致检测规则失效

在 2025 年 3 月，Anthropic 更新了 Claude Code 的底层模型。旧版本的 Claude 倾向于在代码注释中解释密钥用途，这导致注释文本本身会触发 Pre-commit 钩子的正则匹配。新版本模型显著减少了这类注释行为，反而让检测更难了，没有注释，密钥字符串看起来就和一个普通的 Base64 编码参数没什么区别。

这是一个我没想到的长尾问题：模型行为会变化，而你的检测规则是静态的。 上次的规则调优可能在下次模型更新后就失效了。

我的应对策略是建立了一个季度回归测试流程：

1. 维护一个包含 50 个“敏感 Prompt”的测试集，这些 Prompt 在历史上曾导致 Claude Code 输出敏感信息。
2. 每季度（或模型更新后）运行这个测试集，收集新模型的输出。
3. 将输出喂给当前的检测管道，计算检测率和误报率的变化。
4. 如果检测率下降超过 10% 或误报率上升超过 20%，触发规则调优流程。

这个流程第一次执行时，我发现新模型的一个 Pattern：它不再输出 sk- 开头的 OpenAI 格式密钥，而是改用 api_key = os.environ.get("OPENAI_API_KEY") 这种方式。从安全角度看，这是好事，但从检测角度看，旧的正则规则完全失效了。如果不做回归测试，我会在不知情的情况下依赖一套过时的规则。

十一、哪些常见的“最佳实践”我验证后认为是无效的

最后说几个我在实践中验证过的结论，可能会挑战一些你听到过的“共识”。

11.1 无效实践一：在 .gitignore 中忽略所有 .env 文件即可

env 被忽略了，但 Claude Code 会把 .env 的内容直接嵌入代码中。我就见过一个案例：开发者在本地用 .env 配置了数据库密码，Claude 在生成数据库连接代码时，把 .env 的内容直接复制进了 db.py 文件。.gitignore 不会阻止这个操作，因为 db.py 本身是需要被追踪的。

11.2 无效实践二：使用环境变量前缀检测代替内容检测

有些工具会扫描代码中是否包含 AWS_ACCESS_KEY_ID= 这类环境变量赋值语句。这个方法在 ClCode 场景下漏报率极高。因为 Claude 不会生成环境变量赋值，它会生成 aws_access_key_id = "AKIAXXXXXX" 这种代码内的直接赋值。扫描变量名完全找不到。

11.3 无效实践三：只在 PR 合并时运行扫描

等到 PR 合并时扫描，意味着敏感信息已经进入了主分支。任何有权限访问仓库的人都能在提出 PR 后的几分钟内通过 GitHub API 拿到 diff 内容。正确的做法是：在 PR 创建时立即触发扫描，而不仅仅是在合并时。 这就是为什么我坚持在 CI/CD 的第一句就运行安全扫描，而不是把它放在 Tests 或 Build 之后。

11.4 无效实践四：依靠开发者自觉检查和提交

我管理过的团队中，最好的开发者也会在凌晨三点赶工的时候跳过检查。不是态度问题，是人性问题。安全措施必须默认生效，不能让开发者选择开启或关闭。

总结：检测的关键不在于工具，在于对“AI 生成代码的不可信假设”

我把这次事故和后续的所有优化归结为一句话：把 Claude Code 的输出视为“不受信任的外部输入”，而不是“辅助编写的内部代码”。 这个心态转变比任何工具都重要。

当一段代码来自同事的 PR，我们会默认它是经过一定思考的，只是因为疏忽才可能包含密钥。但当一段代码来自 Claude Code，我们必须默认它是完全未经安全审查的，只是恰好通过了语法检查。这两者的信任级别完全不同，检测策略也必须完全不同。

如果你现在就开始做一件事，我建议的顺序是：

1. 在 Claude Code 的 System Prompt 中加入三层约束（策略 C）。
2. 安装 TruffleHog Pre-commit 钩子并启用验证模式。
3. 在 CI/CD 中加入 GitLeaks 扫描，确保它运行在任何 Build 或 Test 步骤之前。
4. 一个月后，根据误报和漏报数据，决定是否需要升级到标准方案或严格方案。

那个凌晨两点的 PagerDuty 告警，我到现在手机里还留着截图。不是作为愧疚，是作为提醒：AI 写得越快，我们就越容易忘记检查。而越容易忘记检查的时候，就越需要一套不会忘记的检测体系。