秘密検出ツールを試す際、ほとんどの人が最初に行うことはこれです：
AWS_SECRET_KEY = "FAKEAWSSECRETKEY123456"
PASSWORD = "password123"スキャンを実行しても何も検出されず、直後の反応は次のようなものになる：
なんて役立たずなんだ。うちの犬だってあれは捕まえられただろうに。
あまりにも明白に思える。セキュリティにおいて秘密を見つけるのが最も簡単な部分だ、そうだろう？パスワード=を検索し、正規表現をいくつか投入して、それで終わりだ。どれほど難しいというのか？
ある意味では君の言う通りだ。秘密のように見える文字列を見つけるのは簡単だ。偽陽性に埋もれずに本当の秘密を見つけるのが難しいのだ。
テストが見た目より難しい理由、最悪の解決策が最良に見える理由、そして実際にこれらのツールをどう評価すべきかについて、順を追って説明しましょう。
秘密検出の仕組み
秘密を検出する主な手法は二つある：ルールベースのパターンマッチングとエントロピー統計である。
ルールベースの検出は、正規表現を用いて定義された構造を持つシークレットを特定します。AWSキーはその典型例です。これらは常に同じプレフィックスで始まり、固定長であるため、次のような正規表現で検出できます：
AKIA[0-9A-Z]{16}
コード内のキーをフラグ付けするのを見ると、強力に感じられる。それがキーのように見えるすべてのプレースホルダーもフラグ付けしていることに気づくまでは。
AWS_ACCESS_KEY_ID="AKIA1234567890123456"
キーが1つならまだしも、何千ものルールを導入するとすぐに非常に煩雑になる。正規表現は有用だが、本物のキーとダミーキーを区別できず、結局は脆弱で煩雑な状態に陥る。
シークレット検証によるフィルタリング
誤検知を減らす最良の方法の一つは、検出後にシークレットを検証することです。これは通常、安全なAPI呼び出しを実行することを意味します。例えば、AWSキーは以下のようにテストできます：
aws sts get-caller-identity --access-key <KEY> --secret-key <SECRET>
呼び出しが成功した場合、有効なキーを取得できます。失敗した場合は、安全にアラートをダウングレードできます。
これは非常に優れた方法です。まず広く網を張り、後で絞り込めるからです。しかしここに落とし穴があります。ツールをテストする際、実際のAWSキーをGitHubにプッシュしているわけではありません。偽のキーを使用しているのです。キーを検証するツールはそれらを無効として破棄し、結果をゼロ件表示します。一方、すべてをフラグ付けする怠惰なツールの方が、一見パフォーマンスが優れているように見えるのです。
エントロピー統計を用いたフィルタリング
ここでエントロピーの意味を簡単に説明する必要があるでしょう。高エントロピー文字列とは、ランダム性が大きい文字列を指します。ランダム性が高いほど＝エントロピーが大きいのです。
ほとんどの秘密は検証できないため、ツールはノイズを低減する他の手法に依存する。エントロピー統計はその中でも最も効果的な手法の一つである。
考え方は単純だ：本物の秘密はランダムに見える。プレースホルダーはそうではない。この偽のStripeキーを考えてみよう：
StripeKey = "SK_123456789"
正規表現には一致するが、現実のものとしてはランダム性が不十分だ。本物の鍵ははるかに高いエントロピーを持ち、これは人間が偽造するのが非常に難しい特性である。
英語の単語フィルタリングも有効です。実際のAPIキーには、ほとんどの場合、読み取れる単語は含まれません。以下のようなものを見かけたら：
テスト823hufb934
ほぼ間違いなくプレースホルダーかテスト用認証情報だと確信していい。優れたツールは、TEST、PASSWORD、DEMOといった明らかな辞書語と高エントロピーを混ぜた文字列を優先度を下げるか無視する。これはテストで問題を引き起こすことが多い。なぜなら、人間がエントロピーを偽装するのは実際には非常に困難だからだ。たとえ自覚していなくても、入力時には自然とパターンに従ってしまうのだ。
残念ながら、APIキーは高エントロピー文字列である一方、これも常に単純な話とは限りません。UUID、ハッシュ、ファイル名も高エントロピー文字列であり、シークレットではありません。したがって、シークレットの周囲にコンテキストを導入することも重要です。最良の解決策は、エントロピー、コンテキスト、単語フィルタリングを組み合わせたものです。ただし、これはテスト時に問題を引き起こします。なぜなら、コンテンツに適合しない偽の認証情報を追加した場合、それらは同様に無視されてしまうからです。
なぜ最悪の道具が最高に見えるのか
これが逆説だ。最悪の解決策、つまり怪しげな文字列をすべて叫び立てるような手法こそが、簡易テストでは輝いて見える。それらは喜んでダミーの鍵やパスワードを捕まえる。一方、賢いツールは偽物を静かに無視するため、機能していないように見えるのだ。
現実的なデータでテストしない限り、結局はノイズの多いツールを称賛し、本番環境で実際に役立つツールを軽視することになる。
シークレット検出を正しくテストする方法
公正な評価を求めるなら、より良いテストデータが必要です。
一つの選択肢はハニートークンです。CanaryTokensのようなサービスを使えば、無害でありながら現実的な認証情報を生成できます。優れたツールはこれらを即座に検知すべきです。
別のアプローチとして、権限のない実際のキーを作成し、テストを実行した後でそれらを無効化する方法があります。これにより、安全でありながら有効な入力が得られ、検証ロジックをトリガーできます。
ただし、最良の方法は実際のコードベースでツールを実行することです。リポジトリにはシークレットが頻繁に存在し、特にコミット履歴の深い部分で見つかります。実際のプロジェクトをスキャンすることで、ツールが現実的な条件下でどのように動作するかが明らかになり、信頼できるベンチマークが得られます。
優れた秘密検出ツールの条件とは
強力な秘密検出ツールは、以下のすべてを実行すべきである：
- 可能な限りシークレットを検証する
プロバイダーが許可する場合、安全なAPI呼び出しで実際のシークレットを確認する。 - 特定のシークレットパターンをサポート
正規表現またはパターンルールを使用して、AWS、Stripe、Twilioなどの構造化されたキーを検出します。 - 汎用的なシークレットをエントロピーと文脈で処理する
固定パターンを持たないシークレットを捕捉するため、ランダムネススコアリングと周辺コード分析を併用する。 - 偽の認証情報やテスト用認証情報を除外する
TESTやPASSWORDなどの明らかな辞書語を含むキーの優先度を下げる - 幅広い種類の秘密情報をカバーします
APIキーだけでなく、証明書、SSHキー、データベースパスワードなども含みます。 - 漏洩が発生する前に防止する
秘密情報がバージョン管理システムに流入するのを防ぐため、コミット前フックまたはIDE統合を提供します。 - リポジトリとパイプラインを横断してスケールする
CI/CD環境、複数の履歴、エンタープライズ規模で効果的に作業する。
まとめ
秘密検出は単純に見えるが、その検証は決して簡単ではない。偽の秘密をすべてフラグ付けするノイズの多いツールは印象的に見える一方、検証とフィルタリングを行うより賢いツールは、一見するとあまり働いていないように見える。
適切にテストしたい場合は、ハニートークン、限定アクセスキー、または実際のリポジトリを使用してください。評価時には、本番環境で重要な品質に注目してください：検証、パターン検出、エントロピー分析、辞書フィルタリング、広範なカバレッジ、そして何よりも、コミット前の予防策です。
テスト用に仕込んだ偽のAWSキーは危険ではない。しかし、平然と隠れている本物のキーこそが危険なのだ。
今すぐソフトウェアを保護しましょう
.avif)
