密钥不小心提交进仓库TruffleHog 凭证检测帮你几分钟翻完整个 Git 历史【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehog上周有同事把带 AWS 密钥的配置文件推到了公开仓库。他删掉那个 commit 之后所有人都以为事情结束了——但密钥仍然躺在历史记录里而且没人知道它还活着。用 TruffleHog 做凭证检测就能处理这类情况它会翻完仓库的每一版内容找出疑似凭证然后逐个验证这些密钥是不是还能真的用。下面按装上、跑通、接到真实场景的顺序讲一遍。先说清楚 TruffleHog 是干什么的TruffleHog 是一个凭证扫描工具定位是发现、分类、验证、分析四类动作一起做。它内置 800 多个检测器能把扫到的字符串对应到具体身份——是 AWS 的、Stripe 的还是 Postgres 的密码。关键是验证这一步它会对能识别的凭证实际发起请求确认这个密钥是活的还是早就被作废了。光找到字符串意义有限知道它还能不能用才决定你要多快去轮换它。用最短路径装好 TruffleHog 并跑出第一条结果三种安装方式任选其一装完直接就能用# macOS brew install trufflehog # 其他方式安装脚本-b 指定安装目录默认 ./bin ./scripts/install.sh -b /usr/local/bin不想装本地二进制的话Docker 一条命令也能扫仓库 README.md 里有各系统的完整写法docker run --rm -it -v $PWD:/pwd \ trufflesecurity/trufflehog:latest filesystem /pwd装好之后对着本地任意目录跑第一条扫描trufflehog filesystem .我实际跑了一遍输出里每条结果都带有检测器名称、命中的文件位置以及验证状态。小项目几十秒内就能看到第一批结果仓库越大越能体现它并行的价值。别只盯着扫到了什么要看结果里的 verified / unverified 标记——这是 TruffleHog 和普通正则扫描最大的区别。把自定义检测规则写成一份 config.yaml内置检测器覆盖不到你们项目特有的凭证格式时写一条自定义规则就行。规则就是一个 YAML 文件四样东西名字、触发关键词、正则、可选的验证端点。detectors: - name: MyInternalToken keywords: [internal] regex: token: [A-Za-z0-9]{40}扫描时加-c指定这份文件trufflehog filesystem -c config.yaml .没有配verify的自定义检测器也能用适合标记.env、.yaml里硬编码的password这类泛型模式。仓库里就有现成模板可以抄通用 API 密钥规则、针对配置文件硬编码凭证的规则字段含义关键词触发、捕获组、熵值过滤、排除词都写在 自定义检测器说明 里。在 CI/CD 里让泄露凭证挡住构建这是接入流水线最常见的用法。加一个--fail标志TruffleHog 只要扫出结果就以退出码 183 结束CI 直接失败密钥进不了主干trufflehog git 仓库地址 --fail两个配合的常用参数--json把结果变成机器可读格式方便归档或上报--github-actions输出可直接挂到代码行的标注格式。跑在 CI 里时如果不想对第三方 API 发起验证请求再加--no-verification只看模式匹配结果即可。扫云存储和 Docker 镜像除了 Git 仓库TruffleHog 的每个子命令对应一种数据源s3扫 S3 桶gcs扫 GCS 桶docker扫镜像还有elasticsearch、jenkins等。典型用法是定期跑一轮对象存储扫描专治三年前传上去的备份文件trufflehog s3 --bucketyour-bucket镜像同理trufflehog docker 镜像名会把构建层里的内容也翻一遍适合在发布前检查基础镜像有没有夹带凭证。各数据源的完整清单可以看 main.go 里注册的子命令。常见疑问结果里的 verified 和 unverified 有什么区别verified 是 TruffleHog 实际请求了对端服务、确认这个凭证当前有效unverified 只表示模式匹配上了状态未知。处理优先级应该先给 verified 的结果。验证这一步会不会对我的服务发起真实请求会。验证本质就是用这个凭证去登一次所以它可能消耗 API 配额、留下访问日志。在内网环境或不希望产生外部请求时用--no-verification关掉即可扫描本身不受影响。删掉含密钥的 commit 就够了吗不够。Git 历史记录里密钥还在所以扫描要面向整个历史而不是最新一份文件——这正是 TruffleHog 扫 Git 时逐版本遍历的原因。发现泄露后的标准动作是轮换凭证再重建或清理历史。CI 里 --fail 的退出码是多少183。写流水线断言或告警规则时直接对这一个数字做判断即可不用解析 stdout。误报太多怎么收敛三个手段结果里用--filter-entropy按熵值过滤低随机性的匹配自定义检测器里加exclude_words排除高频干扰词只信验证过的结果做阻断。仓库基准测试里各版本扫描耗时基本稳定性能本身不是瓶颈多花时间调规则是划算的。扫一次只是止血把 TruffleHog 固定放进提交流水和定期任务里泄露才会在你之前被拦住 【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考