TruffleHogはGitリポジトリやファイルシステム、S3、Slackなど多様なソースから漏えいした認証情報を検出するツールです。単に文字列パターンを見つけるだけでなく、検出した秘密情報を実際のAPIに対して照合し、有効かどうかを検証します。さらに一部の秘密情報については権限範囲まで分析できる点が特徴です。
main.goがkingpinでCLIを構築し、sourcesパッケージが指定されたソース(git、filesystem、S3など)からチャンク単位でデータを読み込みます。読み込んだチャンクはdecodersでBase64などをデコードした後、pkg/detectors配下の各検出器がキーワードと正規表現でマッチングします。マッチした候補はverificationcache(pkg/verificationcache)を介して実際の外部APIに問い合わせ、verified・unverified・unknownのいずれかに分類されます。検出結果はoutputパッケージでJSON・SARIF・GitHub Actions形式などに整形されます。さらにpkg/analyzer配下には、GitHub・Slack・Stripeなど40種類以上のサービス専用アナライザーがあり、見つかった鍵の権限スコープ(permissions.yaml)を照会してどこまでアクセスできるかを表示します。hack/checksecretpartsやhack/snifftestといった補助ツールもリポジトリに含まれ、検出器の内部品質チェックやデータセットに対する検出器のテストに使われます。
- STEP 01
まずgo installかDockerイメージでtrufflehogバイナリを用意し、trufflehog --helpでgit・filesystem・s3などのサブコマンド一覧を確認します。
- STEP 02
trufflehog git file://path/to/repoのようにローカルリポジトリを指定して実行すると、コミット履歴を遡りながらチャンクごとに検出器がマッチングを試みます。
- STEP 03
検出された候補はデフォルトで外部APIへの照会が走り、Verified: trueかfalseかがコンソールに表示され、生きている鍵かどうかが分かります。
- STEP 04
--jsonや--sarifを付けて出力形式を変えると、CIパイプラインへの取り込みを想定した構造化結果が得られます。
- STEP 05
trufflehog analyzeサブコマンドに見つかった鍵とタイプを渡すと、GitHubやStripeなどの鍵についてスコープ・権限情報が表示されます。
- STEP 06
pre-commitフック(.pre-commit-hooks.yaml)として組み込むと、コミット前にステージ済み差分だけを対象に高速スキャンできます。
実行するとリポジトリやファイル群の中から漏えいした可能性のある鍵・トークンの一覧と、それぞれがVerified(生存確認済み)かUnverifiedかの判定、検出場所(コミットハッシュやファイルパス)が得られます。analyzeコマンドを併用すれば、見つかった鍵が実際にどのAPI操作を許可しているかという権限情報も追加で手に入ります。
検証(verification)は対象サービスへ実際にAPIリクエストを送るため、ネットワークアクセスと対象サービス側のレート制限・ログ記録の影響を考慮する必要があります。
検出器の数が非常に多く(pkg/detectorsは多数のサブディレクトリ)、全文検索対象が大きいリポジトリではスキャン時間が長くなる可能性があります。
アナライザーはREADMEやファイルツリーの範囲では40種類以上確認できますが、それぞれの精度や網羅率は個別のテストファイル・result_output.jsonでしか裏付けられておらず、今回の資料だけでは全体の検出精度は判断できません。
READMEの内容は.github/workflowsディレクトリ内のPR承認チェックの説明であり、ツール本体の使い方や導入手順そのものを詳述したものではありません。
CIパイプラインやpre-commitフックにシークレットスキャンを組み込みたいセキュリティ・開発チームに向いています。とくに検出だけでなくAPI照合による生存確認まで欲しい場合に価値が出ます。ソースコードの構成(main.go、pkg/detectors、pkg/analyzer、verificationcache)や.captain/config.yamlのテストスイート定義、GitHub Actionsのdetector-tests.ymlなどから、検出・検証・権限分析という3段構造が実際にコード化されていることを確認できました。この構造的根拠に基づけば、実機で試さなくても機能の有無と全体設計についての判断は十分に信頼できます。ただし個々の検出器の的中率や大規模リポジトリでの実行速度は、本レビューの範囲外として実際の運用で確認する必要があります。