TruffleHogでリポジトリのシークレットをスキャンする
APIキーを誤ってリポジトリにコミットしてしまった経験はありませんか?あなただけではありません。毎日何千もの認証情報がgitを通じて漏洩しており、開発者が削除したと思った後も、コミット履歴に残り続けていることがよくあります。TruffleHogのシークレットスキャンは、セキュリティインシデントになる前に、リポジトリ内の露出したAPIキーを検出するための直感的な方法を提供します。
この記事では、TruffleHogの仕組み、ローカルおよびCIでgitリポジトリのシークレットをスキャンする方法、そして効果的に修復の優先順位を付けるための結果の解釈方法について説明します。
重要なポイント
- TruffleHogは現在のファイルだけでなく、git履歴全体をスキャンし、古いコミットに埋もれたシークレットを検出します
- 検証済みの検出結果は、即座にローテーションが必要な、実際に利用可能で悪用される可能性のある認証情報を示します
- TruffleHogをCIパイプラインに統合することで、認証情報の漏洩が本番環境に到達する前に防止できます
- シークレットが見つかった場合は、まずローテーションを行い、その後BFG Repo-Cleanerやgit-filter-repoなどのツールを使用して履歴から削除します
なぜシークレットがGitに混入するのか
開発者は迅速に作業を進めます。デバッグ中にデータベースパスワードがハードコードされることがあります。AWSキーが設定ファイルに記載されることもあります。このようなミスは常に発生しており、gitの不変な履歴により、「削除された」シークレットでも古いコミットに残り続けます。
リスクは現実的です:自動化されたボットが公開リポジトリを継続的にスキャンしており、露出した認証情報はプッシュされてから数分以内に悪用される可能性があります。プライベートリポジトリでさえ安全ではありません—開発者アカウントが1つ侵害されたり、アクセス制御が誤って設定されたりすると、すべてが露出する可能性があります。
TruffleHogがシークレットを検出する仕組み
TruffleHogは単純なgrepツールではありません。数百の組み込みパターンを持つ検出器ベースのスキャンを使用して、特定の認証情報タイプを検出します:AWSキー、GitHubトークン、Stripe APIキー、データベース接続文字列など。
検出アプローチは以下を組み合わせています:
- パターンマッチング: 既知のシークレット形式に調整された正規表現検出器
- コンテキスト分析: ノイズを減らすために周囲のコードを検査
- オプションの検証: 認証情報が有効であることを確認するために実際のAPIに対してテスト
この多層的なアプローチにより、エントロピーのみのスキャナーよりも誤検出が少なくなります。TruffleHogが何かをフラグ付けした場合、通常は調査する価値があります。
ローカルリポジトリのスキャン
ローカルでgitリポジトリのシークレットをスキャンするには、TruffleHogをリポジトリに向けます:
trufflehog git file://.
これは現在の作業ツリーだけでなく、git履歴全体をスキャンします。古いコミットに埋もれたシークレットは、最近のものと一緒に検出されます。
開発中により迅速なフィードバックを得るために、スキャン範囲を最近のコミットや特定のブランチに制限できます。これにより、変更をプッシュする前に実行することが現実的になります。
検証済みと未検証の結果の理解
TruffleHogは2つの検出タイプを区別します:
- 検証済み: 認証情報がそのAPIに対してテストされ、有効であることが確認されました
- 未検証: パターンは既知のシークレット形式と一致しますが、検証が不可能だったか、試行されませんでした
検証済みの検出結果は即座の対応を要求します—これらは今すぐ悪用される可能性のある有効な認証情報です。未検証の検出結果も確認する価値がありますが、大量の結果セットをトリアージする際には優先順位を下げることができます。
検証済みの結果のみに出力をフィルタリングするには:
trufflehog git file://. --only-verified
Discover how at OpenReplay.com.
TruffleHog GitHub ActionのCIへの統合
手動でスキャンを実行すると問題を発見できますが、自動化により問題を防止できます。TruffleHog GitHub ActionはCIパイプラインに直接統合され、すべてのプルリクエストとプッシュをスキャンします。
基本的なワークフロー設定は、受信した変更をスキャンし、シークレットが検出された場合にビルドを失敗させます。これにより、認証情報の漏洩がメインブランチ、さらには本番環境に到達する前に阻止するゲートが作成されます。
このアクションは、差分のみのスキャン(PRチェックでより高速)またはリポジトリ履歴全体のスキャン(定期的な監査に有用)をサポートしています。ほとんどのチームは、すべてのPRで軽量な差分スキャンを実行し、包括的な履歴スキャンを毎週スケジュールしています。
Git以外:その他のスキャン対象
この記事はgitワークフローに焦点を当てていますが、TruffleHogは追加の対象をサポートしています:ファイルシステム、S3バケット、Dockerイメージ。ほとんどの開発者にとって、gitとファイルシステムのスキャナーが典型的なユースケースをカバーします。より広範な機能は、インフラストラクチャが成長するにつれて関連性が高まります。
シークレットが見つかった場合の対処法
シークレットを見つけることは最初のステップに過ぎません。対応の方が重要です:
- 認証情報を直ちにローテーション—侵害されたと仮定する
- BFG Repo-Cleanerやgit-filter-repoなどのツールを使用してgit履歴から削除
- 影響を受けたサービスのアクセスログを監査して、不正使用がないか確認
- ワークフローを更新して、今後ソース管理での認証情報漏洩を防止
単にファイルを削除して再度コミットしても役に立ちません。履歴を書き換えるまで、シークレットは履歴に残ります。
まとめ
TruffleHogは、単なる監査ツールとしてではなく、予防的コントロールとして最も効果的に機能します。CIの早い段階、理想的にはすべてのプルリクエストで実行してください。漏洩した認証情報を早期に発見するほど、影響範囲は小さくなります。
自動スキャンと良好な衛生習慣を組み合わせましょう:シークレットには環境変数を使用し、機密パターンを.gitignoreに追加し、ローカル強制のためのpre-commitフックを検討してください。
シークレットスキャンがすべてのリスクを排除するわけではありませんが、ミスとその発見の間の時間を劇的に短縮します。それはしばしば、ニアミスとインシデントの違いとなります。
よくある質問
TruffleHogはデフォルトでgit履歴全体をスキャンし、現在の作業ツリーだけではありません。これは、後のコミットで削除された場合でも、古いコミットに埋もれたシークレットが検出されることを意味します。gitの不変な履歴はすべてを保持するため、すべての露出した認証情報を見つけるには包括的なスキャンが不可欠です。
検証済みの検出結果は、TruffleHogが認証情報を実際のAPIに対してテストし、まだ有効であることを確認したことを意味します。未検証の検出結果は既知のシークレットパターンと一致しますが、検証されませんでした。検証済みの検出結果は、有効で悪用可能な認証情報を表すため、即座の対応を優先してください。
ファイルを削除してコミットしても、履歴からシークレットは削除されません。BFG Repo-Cleanerやgit-filter-repoなどのツールを使用してgit履歴を書き換え、すべてのコミットから認証情報を削除します。書き換え後、リモートに強制プッシュし、すべての共同作業者にリポジトリを再クローンしてもらいます。
はい、TruffleHogはローカル強制のためにpre-commitフックとして実行できます。これにより、シークレットがリモートリポジトリに到達する前に検出されます。pre-commitフックとCI統合を組み合わせて多層防御を実現し、ローカルとパイプラインの両方でシークレットがブロックされるようにします。
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.