TruffleHog 凭证检测完整指南一条命令开始接进 CI 持续运行【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehogTruffleHog 是一款开源凭证检测工具先按内置规则找出形似 API 密钥、私钥、数据库口令的字符串再向对应服务的 API 发请求确认该凭证当前是否仍有效把误报压到最低。从一个真实的漏网场景说起一个常见事故开发者把.env里的数据库口令提交进仓库事后删掉文件、强推分支但凭证仍留在 git 历史里。这时用 grep 能搜到password这个词却回答不了两个关键问题这串值属于哪个服务它现在还有效吗API 密钥扫描工具要解决的就是这类问题。为什么 grep 和肉眼不够密钥格式互不相同AKIA开头是 AWS、xox开头是 Slack、sk_是 Stripe靠记忆不现实。值经常变形Base64、UTF-16、HTML 实体、被拆成多段拼接纯文本搜索会漏。搜到不等于危险已吊销的 key 和还活着的 key 需要区别对待。TruffleHog 的发现、归类、验证发现内置 800 多个检测器覆盖常见云厂商、SaaS、数据库的凭证格式并对内容做多轮解码后再匹配。归类命中后标注凭证类型能进一步给出归属身份例如是哪个 AWS 账号。验证对每条命中结果调用对应服务 API输出三种状态verifiedAPI 确认有效需要立即处理unverified命中但未验证无验证逻辑或验证被跳过unknown验证过程本身出错网络或 API 故障不能排除。每条结果还带提交哈希、文件、行号、提交者可以直接定位是谁在哪次提交漏的。仓库里保留了各版本的扫描耗时基准上图显示用户时间在版本间保持稳定升级后扫大仓库的耗时不会明显变化。用一条命令完成第一次扫描下面这条主线可以作为 TruffleHog 使用教程直接照着做。安装 TruffleHog# macOSHomebrew 安装 brew install trufflehog# 从源码安装克隆后编译需 Go 环境 git clone https://gitcode.com/GitHub_Trending/tr/trufflehog cd trufflehog go install想用容器直接跑docker run --rm trufflesecurity/trufflehog:latest --help。最小可用的扫描命令# 扫描一个 git 仓库只输出经 API 确认有效的凭证 trufflehog git https://git.example.com/your-org/repo.git --resultsverified不依赖 git 仓库时直接扫目录# 扫本地目录如部署产物、配置目录--no-verification 跳过验证、更快 trufflehog filesystem ./deploy --no-verification常用输出与判定参数--resultsverified,unknown控制输出哪些状态排查时建议两者都保留--jsonJSON 输出方便下游脚本消费--fail发现结果时以退出码 183 结束供 CI 判断是否拦截--exclude-detectors排除产生噪音的检测器。按数据源选扫描命令TruffleHog 的每个数据源对应一个子命令按数据存放位置选即可各子命令的详细选项看trufflehog 子命令 --help。本地仓库与托管平台仓库# 本地仓库file:// 前缀指向本地路径 trufflehog git file://./myrepo --resultsverified,unknown# 按组织批量扫 GitHubtoken 从环境变量 GITHUB_TOKEN 读 trufflehog github --orgyour-org --resultsverifiedGitLab 用trufflehog gitlab --tokenGITLAB_TOKEN --reporepo-url参数逻辑相同。GitHub 扫描还可以加--issue-comments、--pr-comments把 Issue 和 PR 讨论区一并扫进凭证检测范围——不少密钥是在讨论里贴出来的。云存储、镜像与数据流# 扫 S3 桶凭据读环境变量 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY trufflehog s3 --bucketbucket-name# 扫 Docker 镜像本地镜像用 docker:// 前缀 trufflehog docker --image docker://your-image:tagGCS 桶trufflehog gcs也支持同样的--results过滤。对于日志流把数据直接管道进去trufflehog stdin会从标准输入扫描适合接入 syslog 导出或对象下载后的数据流。自定义检测器内置规则覆盖不了自有令牌格式时用--config加载规则文件detectors: - name: internal-token keywords: - internal regex: token: ([A-Za-z0-9_-]{32,40})规则只需名称、关键词触发词和正则三段想对自定义规则做验证可在verify段指向一个自有校验端点端点返回 200 即视为有效。仓库里的 examples/generic.yml 是一份可直接使用的通用 API 密钥规则pkg/custom_detectors/CUSTOM_DETECTORS.md 给出完整参数说明含熵值、排除词等降噪选项。把检测接进自动化持续跑起来一次性扫描只覆盖当下第二天提交进来的凭证要靠机制拦住。CI 集成凭证检测的核心是两点只扫本次改动引入的提交命中即让流水线失败。CI 里拦住 PR# 只扫相对 main 新增的提交命中有效凭证即以退出码 183 结束 trufflehog git file://. --since-commit main --branch feature-1 --resultsverified,unknown --failREADME 中附有 GitHub Actions 与 GitLab CI 的完整示例可直接参考。若希望结果进入代码扫描面板加--sarif输出 SARIF 格式即可。提交前用 pre-commit 拦截 # 放进 git 钩子只检查暂存区改动命中即阻止提交 trufflehog git file://. --since-commit HEAD --resultsverified,unknown --fail仓库的 PreCommit.md 给出三种接入方式Git 全局core.hooksPath、pre-commit 框架、Husky钩子场景下 TruffleHog 会自动切换为只检查暂存改动。对已接受风险的误报在该行加trufflehog:ignore注释即可排除。收尾自查清单接入完成后确认三件事凭证可能出现的入口是否都覆盖代码仓库、配置目录、对象存储、镜像CI 是否启用了--fail命中时流水线真的会红发现verified凭证后是否有立即轮换 追查来源的固定流程第一次扫描的目的是找出已有漏洞自动化的价值在于拦住下一次泄露。【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考