如何快速发现泄露的凭证TruffleHog 凭证检测 3 个高频用法【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehogTruffleHog 是一款开源的凭证检测工具内置 800 多种检测器能扫描代码、仓库和云存储中的 API 密钥与密码并逐一调用对应服务验证凭证是否真实有效帮你在泄露酿成事故前把它揪出来。某天 CI 突然红才发现密钥早就进了仓库想象这个场景一个实习生把.env提交进了仓库里面有一把 AWS Access Key。三个月后安全团队审计时才发现——而密钥可能早已被扫描器抓取并滥用。更麻烦的是即使后来删掉了那行代码只要仓库没有 force push历史提交里依然留着它。靠git log -p人工翻历史、或者 grep 几个已知关键字覆盖率低、误报高。这正是 TruffleHog 要解决的问题自动遍历 Git 历史包括已删除提交用 800 多个检测器识别密钥类型再向对应服务的 API 发起验证请求告诉你这把 key 是还活着还是已失效。它是什么先分类再验证TruffleHog 的定位是凭证的发现、分类、验证、分析一体化扫描器。和只做正则匹配的工具不同它的核心价值在验证这一步发现扫描 Git 仓库、GitHub/GitLab 组织、文件系统、S3/GCS 存储桶、Docker 镜像、stdin 等 18 类数据源分类内置 800 检测器AWS、Stripe、GitHub token、私钥、JWT 等自动识别密钥类型验证对识别出的凭证调用其所属服务 API 确认有效性结果分verified/unverified/unknown三档分析trufflehog analyze可对常见凭证进一步检查权限范围和可访问资源从零到第一条扫描命令macOS 用户一行装好brew install trufflehogLinux/Windows 或从源码安装克隆仓库后运行安装脚本git clone https://gitcode.com/GitHub_Trending/tr/trufflehog cd trufflehog ./scripts/install.sh -b /usr/local/bin第一条能跑通的命令——扫描一个 Git 仓库只看验证过的结果trufflehog git https://github.com/trufflesecurity/test_keys --resultsverified输出会列出检测器类型如AWS、命中文件、行号、提交哈希和作者信息Verified: true表示这把 key 确实还能用。三个高频用法用法一扫描本地仓库和历史提交在仓库外部的目录执行本地仓库走file://协议trufflehog git file:///path/to/repo --resultsverified,unknown扫描时会克隆仓库到临时目录再分析天然覆盖历史提交想限定范围可加--since-commit commit或--max-depth N。只想扫普通文件目录则用trufflehog filesystem path。用法二接入 CI卡住每次提交配合官方 GitHub Action每次 PR 和 push 到main时只扫描变更提交发现活密钥即让流水线失败- uses: trufflesecurity/trufflehogmain with: extra_args: --resultsverified,unknown --fail--fail会让进程以退出码 183 结束CI 据此拦截。不想用 Action 也可以直接在流水线里跑 CLI参考 GitLab CI 示例想在密钥离开本机前就拦下可以看 pre-commit 钩子配置。用法三写自定义检测器补盲区内置检测器覆盖不了的自研系统比如内部网关 token可以用自定义检测器一个 YAML 定义正则 关键字再配一个 webhook 做验证用--config加载。仓库里有两个现成模板可直接改trufflehog git file://. --config examples/generic_config_secrets.yml完整写法见 自定义检测器文档examples/generic.yml 是带验证 webhook 的示例examples/generic_config_secrets.yml 则专门用于标记.env、.properties里的通用硬编码密码。容易踩的坑只看到横幅就以为扫完了输出只有 TruffleHog. Unearth your secrets.说明没有命中不是程序报错验证会消耗真实 API 调用--no-verification可关闭验证提速但会失去是否有效的判断内网服务可用--verifier指向自定义验证端点误报太多时用过滤参数--filter-entropy 3.0按香农熵过滤低质量未验证结果扫描时已知误报可在源码行尾加trufflehog:ignore注释跳过GitHub 组织扫描慢未带 token 时受 API 限流加--token或设GITHUB_TOKEN提速常用命令速查场景命令扫描远程 Git 仓库trufflehog git url --resultsverified扫描本地仓库trufflehog git file://. --since-commit main扫描文件/目录trufflehog filesystem path扫描 S3 桶trufflehog s3 --bucketname扫描 Docker 镜像trufflehog docker --image image:tagJSON 输出加--json发现结果即失败CI 用加--fail退出码 183指定并发数加--concurrency N更多子命令s3、gcs、syslog、postman、multi-scan等参数可用trufflehog cmd --help查看。凭证泄露往往不是会不会发生而是何时被扫到的问题。装上 TruffleHog先给你的仓库跑一次--resultsverified看看历史提交里有没有还活着的 key 【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何快速发现泄露的凭证：TruffleHog 凭证检测 3 个高频用法
如何快速发现泄露的凭证TruffleHog 凭证检测 3 个高频用法【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehogTruffleHog 是一款开源的凭证检测工具内置 800 多种检测器能扫描代码、仓库和云存储中的 API 密钥与密码并逐一调用对应服务验证凭证是否真实有效帮你在泄露酿成事故前把它揪出来。某天 CI 突然红才发现密钥早就进了仓库想象这个场景一个实习生把.env提交进了仓库里面有一把 AWS Access Key。三个月后安全团队审计时才发现——而密钥可能早已被扫描器抓取并滥用。更麻烦的是即使后来删掉了那行代码只要仓库没有 force push历史提交里依然留着它。靠git log -p人工翻历史、或者 grep 几个已知关键字覆盖率低、误报高。这正是 TruffleHog 要解决的问题自动遍历 Git 历史包括已删除提交用 800 多个检测器识别密钥类型再向对应服务的 API 发起验证请求告诉你这把 key 是还活着还是已失效。它是什么先分类再验证TruffleHog 的定位是凭证的发现、分类、验证、分析一体化扫描器。和只做正则匹配的工具不同它的核心价值在验证这一步发现扫描 Git 仓库、GitHub/GitLab 组织、文件系统、S3/GCS 存储桶、Docker 镜像、stdin 等 18 类数据源分类内置 800 检测器AWS、Stripe、GitHub token、私钥、JWT 等自动识别密钥类型验证对识别出的凭证调用其所属服务 API 确认有效性结果分verified/unverified/unknown三档分析trufflehog analyze可对常见凭证进一步检查权限范围和可访问资源从零到第一条扫描命令macOS 用户一行装好brew install trufflehogLinux/Windows 或从源码安装克隆仓库后运行安装脚本git clone https://gitcode.com/GitHub_Trending/tr/trufflehog cd trufflehog ./scripts/install.sh -b /usr/local/bin第一条能跑通的命令——扫描一个 Git 仓库只看验证过的结果trufflehog git https://github.com/trufflesecurity/test_keys --resultsverified输出会列出检测器类型如AWS、命中文件、行号、提交哈希和作者信息Verified: true表示这把 key 确实还能用。三个高频用法用法一扫描本地仓库和历史提交在仓库外部的目录执行本地仓库走file://协议trufflehog git file:///path/to/repo --resultsverified,unknown扫描时会克隆仓库到临时目录再分析天然覆盖历史提交想限定范围可加--since-commit commit或--max-depth N。只想扫普通文件目录则用trufflehog filesystem path。用法二接入 CI卡住每次提交配合官方 GitHub Action每次 PR 和 push 到main时只扫描变更提交发现活密钥即让流水线失败- uses: trufflesecurity/trufflehogmain with: extra_args: --resultsverified,unknown --fail--fail会让进程以退出码 183 结束CI 据此拦截。不想用 Action 也可以直接在流水线里跑 CLI参考 GitLab CI 示例想在密钥离开本机前就拦下可以看 pre-commit 钩子配置。用法三写自定义检测器补盲区内置检测器覆盖不了的自研系统比如内部网关 token可以用自定义检测器一个 YAML 定义正则 关键字再配一个 webhook 做验证用--config加载。仓库里有两个现成模板可直接改trufflehog git file://. --config examples/generic_config_secrets.yml完整写法见 自定义检测器文档examples/generic.yml 是带验证 webhook 的示例examples/generic_config_secrets.yml 则专门用于标记.env、.properties里的通用硬编码密码。容易踩的坑只看到横幅就以为扫完了输出只有 TruffleHog. Unearth your secrets.说明没有命中不是程序报错验证会消耗真实 API 调用--no-verification可关闭验证提速但会失去是否有效的判断内网服务可用--verifier指向自定义验证端点误报太多时用过滤参数--filter-entropy 3.0按香农熵过滤低质量未验证结果扫描时已知误报可在源码行尾加trufflehog:ignore注释跳过GitHub 组织扫描慢未带 token 时受 API 限流加--token或设GITHUB_TOKEN提速常用命令速查场景命令扫描远程 Git 仓库trufflehog git url --resultsverified扫描本地仓库trufflehog git file://. --since-commit main扫描文件/目录trufflehog filesystem path扫描 S3 桶trufflehog s3 --bucketname扫描 Docker 镜像trufflehog docker --image image:tagJSON 输出加--json发现结果即失败CI 用加--fail退出码 183指定并发数加--concurrency N更多子命令s3、gcs、syslog、postman、multi-scan等参数可用trufflehog cmd --help查看。凭证泄露往往不是会不会发生而是何时被扫到的问题。装上 TruffleHog先给你的仓库跑一次--resultsverified看看历史提交里有没有还活着的 key 【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考