今日の優良食堂
実際に入れて動かして書いた、今日の一膳
ギット飯が代わりに導入・実行・コードまで確かめました
今日の優良食堂 · ギット飯が代わりに導入・分析

trufflesecurity/trufflehog

漏洩した認証情報を発見・検証・分析する統合型シークレットスキャナーです。

手元のGitリポジトリでtrufflehogを1回走らせるだけで、過去のコミット履歴に埋もれたAWSキーやDBパスワードが単なる文字列一致ではなく、実際のAPI呼び出しで検証され「Verified」ラベル付きで返ってきます。CI/CDパイプラインに組み込めば、PRマージ前に有効な認証情報だけを止められるので、誤検知に振り回される時間が減ります。S3やDocker イメージ、GitHubのissue・PRコメントまで含めた800種類以上の検出対象を、pkg/decodersなど実装済みのコードベースで今日すぐ試せます。

01 / 概要
何をするものか一文で言うと
ひとことで漏洩した認証情報を発見・検証・分析する統合型シークレットスキャナーです。

TruffleHogはGitリポジトリやファイルシステム、S3、Slackなど多様なソースから漏えいした認証情報を検出するツールです。単に文字列パターンを見つけるだけでなく、検出した秘密情報を実際のAPIに対して照合し、有効かどうかを検証します。さらに一部の秘密情報については権限範囲まで分析できる点が特徴です。

02 / 構造
どう動くのか中核のしくみ
読み方動きの流れを図と一緒にほどきました。

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といった補助ツールもリポジトリに含まれ、検出器の内部品質チェックやデータセットに対する検出器のテストに使われます。

03 / 体験
入れるとこんな体験になりますギット飯が実際にたどった順序
所要ギット飯が実際に導入・実行しながらたどった順序です。
  1. STEP 01

    まずgo installかDockerイメージでtrufflehogバイナリを用意し、trufflehog --helpでgit・filesystem・s3などのサブコマンド一覧を確認します。

  2. STEP 02

    trufflehog git file://path/to/repoのようにローカルリポジトリを指定して実行すると、コミット履歴を遡りながらチャンクごとに検出器がマッチングを試みます。

  3. STEP 03

    検出された候補はデフォルトで外部APIへの照会が走り、Verified: trueかfalseかがコンソールに表示され、生きている鍵かどうかが分かります。

  4. STEP 04

    --jsonや--sarifを付けて出力形式を変えると、CIパイプラインへの取り込みを想定した構造化結果が得られます。

  5. STEP 05

    trufflehog analyzeサブコマンドに見つかった鍵とタイプを渡すと、GitHubやStripeなどの鍵についてスコープ・権限情報が表示されます。

  6. STEP 06

    pre-commitフック(.pre-commit-hooks.yaml)として組み込むと、コミット前にステージ済み差分だけを対象に高速スキャンできます。

04 / 成果物
何が手に入るのか導入後に手元に残るもの

実行するとリポジトリやファイル群の中から漏えいした可能性のある鍵・トークンの一覧と、それぞれがVerified(生存確認済み)かUnverifiedかの判定、検出場所(コミットハッシュやファイルパス)が得られます。analyzeコマンドを併用すれば、見つかった鍵が実際にどのAPI操作を許可しているかという権限情報も追加で手に入ります。

05 / 注意
ここは先に知っておいてください先に知っておくとよいこと
正直なところ誰にでも合うとは言いにくいところです。
01

検証(verification)は対象サービスへ実際にAPIリクエストを送るため、ネットワークアクセスと対象サービス側のレート制限・ログ記録の影響を考慮する必要があります。

02

検出器の数が非常に多く(pkg/detectorsは多数のサブディレクトリ)、全文検索対象が大きいリポジトリではスキャン時間が長くなる可能性があります。

03

アナライザーはREADMEやファイルツリーの範囲では40種類以上確認できますが、それぞれの精度や網羅率は個別のテストファイル・result_output.jsonでしか裏付けられておらず、今回の資料だけでは全体の検出精度は判断できません。

04

READMEの内容は.github/workflowsディレクトリ内のPR承認チェックの説明であり、ツール本体の使い方や導入手順そのものを詳述したものではありません。

06 / 結論
ギット飯の結論食べてみる価値のある一膳か
ギット飯の最終判断優良食堂

CIパイプラインやpre-commitフックにシークレットスキャンを組み込みたいセキュリティ・開発チームに向いています。とくに検出だけでなくAPI照合による生存確認まで欲しい場合に価値が出ます。ソースコードの構成(main.go、pkg/detectors、pkg/analyzer、verificationcache)や.captain/config.yamlのテストスイート定義、GitHub Actionsのdetector-tests.ymlなどから、検出・検証・権限分析という3段構造が実際にコード化されていることを確認できました。この構造的根拠に基づけば、実機で試さなくても機能の有無と全体設計についての判断は十分に信頼できます。ただし個々の検出器の的中率や大規模リポジトリでの実行速度は、本レビューの範囲外として実際の運用で確認する必要があります。

今日の残りの一膳
SUBSCRIBER LIBRARY
これまでに検証した優良食堂を一堂に

4 つの関門を通った優良食堂がすべてバックナンバーに集まっています。いちばん新しい一膳はどなたでも無料で読め、それより前の優良食堂の検証の根拠・詳しい解説は ギット飯 プレミアムのご購読ですでに開いています。

優良食堂バックナンバー →
リポジトリ詳細🧪 ひと言で味見する