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