シークレット（APIキー、パスワード、証明書など）は、遊び場のささやき声のデジタル版であり、一般公開されるものではなく、信頼できる受信者向けです。現代のソフトウェアでは、シークレットはプログラムによって使用されるため、遍在的でありながら脆弱です。放置されると、多くの場合、大規模な侵害の出発点となります。このガイドでは、シークレットがどこから漏洩するのか、なぜその検出が見た目よりも難しいのか、優れた検出が実際に何をするのか、そして偶発的な漏洩がインシデントになる前に阻止するためにどのように展開するかを説明します。
ソフトウェアにおける「シークレット」とは何に該当しますか？
シークレットとは、APIキー、データベースパスワード、OAuthトークン、SSHキー、TLS証明書など、システムやサービスへのアクセスを許可するあらゆる認証情報です。シークレットはプログラムによって利用されるため、ソースコード、CIパイプライン、開発者のマシン、バックアップなどを経由し、広範な攻撃対象領域を生み出します。
シークレットが一般的に漏洩する仕組み
最も一般的な情報漏洩経路の1つは、ソース管理履歴です。典型的なシナリオは次のとおりです。
- 開発者はフィーチャーブランチを作成し、迅速なテストのために認証情報をハードコードします。
- 検証されると、認証情報を環境変数またはVault呼び出しに置き換え、変更をレビューのためにプッシュします。
- コードレビューは現在の差分のみを対象とするため、一時的なシークレットはブランチまたはコミット履歴に埋もれたままになります。
Git履歴を書き換えない限り（これは破壊的でリスクを伴います）、そのシークレットは残り続けます。攻撃者がリポジトリ（たとえプライベートなものであっても）にアクセスした場合、履歴をスキャンして認証情報を収集し、より価値の高いターゲットへ侵入する可能性があります。
この問題はどの程度広まっていますか？
公開された調査によると、これは決して珍しいことではありません。GitHubの大規模スキャンでは、数百万もの公開されたシークレットが明らかになり、プライベートリポジトリでさえ驚くほど高い割合で存在しています。実際の侵害事例がそのリスクを証明しており、漏洩したソースコードダンプからは、クラウドトークンや支払いキーを含む数千もの認証情報が見つかっています。
SASTだけでは不十分な理由
静的アプリケーションセキュリティテスト（SAST）は、現在のコードベースにおけるSQLインジェクションやパストラバーサルなどの検出に優れていますが、通常は最新のスナップショットをスキャンするだけで、完全なコミット履歴は対象としません。シークレットは異なります。どのコミット、ブランチ、タグに含まれるシークレットも、侵害のリスクとなります。したがって、検出には完全な履歴と、その履歴が存在する複数のリポジトリを考慮する必要があります。
シークレット検出が「単なる正規表現」よりも難しい理由
一見すると、「API_KEY=」の正規表現を書いて終わりだと思われるかもしれません。しかし実際には、シークレット検出は開発者をノイズで埋もれさせないよう、精度と再現率のバランスを取る必要があります。
- エントロピーの高い文字列（ランダムに見える値）は、多くの場合シークレットですが、常にそうとは限りません。シークレットではない多くの成果物もエントロピーが高くなります。
- プレースホルダーと例: コードベースに散在しています。あらゆるキーを安易にフラグ付けすると、ワークフローを中断させる誤検知を引き起こします。
- プロバイダーのパターンは様々です。一部のサービス（Stripe、AWS、Twilio）は識別可能なプレフィックスやフォーマットを使用しますが、そうでないものもあります。
効果的なシークレット検出とは
効果的なシークレット検出ソリューションは、複数のシグナルを使用して誤検知を減らし、実際の漏洩を捕捉します。
- 既知のプロバイダーに対するパターンマッチング: プロバイダー固有の形式（例：Stripeのプレフィックス、AWSトークンの形状）に従うキーを特定します。
- Validation where possible. 検出結果が本物であるかを確認するために、非破壊的な検証（このAWSキーは存在するか？アクティブか？）を試みます。
- エントロピー + コンテキスト。 エントロピー測定を使用してランダム性の高い文字列を特定し、その後、周囲のコード（ファイルパス、変数名、コメント）を検査して、それがシークレットであるかどうかを判断します。
- アンチ辞書チェック。英語の単語や明白なプレースホルダーを含む文字列を除外して、ノイズを削減します。
- History-aware scanning. mainブランチの先端だけでなく、ブランチ、タグ、ミラー全体にわたるgitの全履歴をスキャンします。
- 開発者中心のデプロイメント。 ワークフローのより早い段階で情報漏洩を阻止するため、リモート（中央リポジトリ）とローカル（pre-commitフック、IDEプラグイン）の両方で検出を実行します。
シークレット検出ツールのテスト（と一般的な落とし穴）
ツールを評価する際、チームはしばしば簡単なテストを行います。明らかな秘密めいた文字列をハードコードし、スキャナーがそれを検出することを期待します。皮肉なことに、すべての明らかな偽の秘密をフラグ付けするツールは、品質が低い可能性があります。経験の浅いテストでは、ノイズの多いツールが最も良く見えるものです。
優れたツールは、些細で現実的ではないパターンやプレースホルダー値を意図的に無視します。あらゆるランダムな文字列に対して警告を発するのではなく、疑わしい発見の検証を優先します。
適切にテストする方法：
- ハニートークン／カナリアトークン（制御可能な実際の低リスクAPIキー）を使用し、検出とアラートをテストするために安全に公開できます。
- 現在のファイル内の新しいフェイクキーだけでなく、履歴ブランチや忘れられたコミットに対してもツールを実行します。
- 誤検知率と検証の成功を測定します。ツールはノイズを削減しつつ、実際にアクション可能なシークレットを検出できるでしょうか？
シークレット検出の展開場所
検出は複数のレイヤーで必要です：
- リモートGitリポジトリ（必須）。 中央のGitホスティングは信頼できる唯一の情報源です。すべてのリポジトリと完全な履歴をスキャンします。ここに存在するシークレットはすべて侵害されたものとして扱われるべきです。
- 開発者のローカル環境（強く推奨）。プレコミットフックやIDEまたはエディタの拡張機能を使用して、プッシュされる前にシークレットを捕捉します。ローカルでのフィードバックは手戻りを防ぎ、開発者に制御権を与えます。
- CI/CDパイプライン。検証済みのシークレットが検出された場合にマージやデプロイをブロックするチェックを追加し、開発を妨げる誤検知を最小限に抑えるルールを確保します。
「シークレットが[リモートリポジトリ]に紛れ込んだ場合、それは侵害されたと見なす必要があります。」
漏洩したシークレットを発見した場合の迅速な修正チェックリスト
- シークレットを直ちにローテーションします（認証情報をローテーションし、トークンを失効させます）。
- 範囲を評価する：そのキーでどのシステムにアクセス可能でしたか？
- すべてのコミットとブランチからシークレットを削除します。ワークフローで必要かつ許容できる場合にのみ、履歴の書き換えを検討してください。
- 他のリポジトリやバックアップで同様の漏洩がないか監査してください。
- 開発者のワークフローとツールを改善し、再発を防止します（IDEプラグイン、pre-commitフック、vaultの導入など）。
まとめ：要点
- 現代の開発においてシークレットは至る所に存在し、多くの場合Gitの履歴に残っています。
- ツリーの先端のみをスキャンするSASTツールは、シークレット検出には不十分です。
- 効果的な検出は、プロバイダーパターン、検証、エントロピー／コンテキスト分析、およびアンチ辞書フィルターを組み合わせてノイズを削減します。
- リークを早期に捕捉し、いたちごっこを避けるために、検知機能を中央（リモートリポジトリ）とローカル（IDE/フック）の両方にデプロイします。
- 些細な偽のキーではなく、ハニートークンと過去のスキャンデータを使用して、責任を持ってスキャナーをテストします。
シークレットの検出は、継続的な開発者ファーストの課題です。適切なシグナルと配置を組み合わせることで、開発者を誤検知で埋もれさせることなく、リスクを劇的に軽減できます。まずGit履歴をスキャンし、ローカル保護を追加し、選択するあらゆるシークレット検出ソリューションの主要機能として検証を組み込みましょう。今すぐAikido Securityをお試しください！
