ブログ一覧に戻る
ベストプラクティス2026年7月23日3分で読めます

「公開前提のキー」を除外することで汎用シークレット検出の誤検知を削減する

Better generic secrets detection starts with finding non-secrets

ベストプラクティス

この記事のポイント

【なぜ重要か】 シークレットスキャナーは正規表現をベースに動作するため、SaaSや各種プラットフォームが「公開前提」として設計した認証情報(Publishable Key)も誤って検出してしまう。これにより、セキュリティ担当者は本来不要な手動トリアージ作業に時間を奪われる。Aikido Securityが開発するBetterleaksでこの問題への対処を開始しており、誤検知の削減手法とその効果を本...

【なぜ重要か】 シークレットスキャナーは正規表現をベースに動作するため、SaaSや各種プラットフォームが「公開前提」として設計した認証情報(Publishable Key)も誤って検出してしまう。これにより、セキュリティ担当者は本来不要な手動トリアージ作業に時間を奪われる。Aikido Securityが開発するBetterleaksでこの問題への対処を開始しており、誤検知の削減手法とその効果を本記事で解説している。

【ポイント】

  • 誤検知削減の手順として複数フェーズを計画:トークン効率フィルタリング→公開前提認証情報の拒否リスト(今回)→公開済みシークレットの拒否リスト→汎用ルールの分類分け→ML支援トリアージ、という順序で、コストの低い手法から順に実施する方針。
  • 公開前提キーの除外で誤検知を約2.37%削減:Common Crawlから100GBをダウンロードしてスキャンしたところ、新しい除外シグネチャにより27,886件の誤検知を削減できた。スキャン時間は約5%増加するが、その価値は十分あると判断している。
  • 除外シグネチャの作成はAIではなく手動:対象キーの形状・アクセス権限・SaaSプラットフォーム上の意味を正確に把握する必要があり、AIは今回の作業には適していなかったとしている。
  • 5つの判定パターンを定義:①形状が一意で除外容易なケース、②形状だけでは判別できずキーワードの文脈が必要なケース、③シークレットキーと形状が同じため活性確認(リアルタイムの疎通チェック)が必要なケース、④設定次第で危険度が変わるため活性確認が必要なケース、⑤テスト用認証情報で本番データが含まれる可能性があるため手動トリアージが必要なケース。
  • 「公開前提」でもリスクがゼロとは限らない:たとえばStripeのテスト用キーは本番への送金はできないが、顧客の個人情報などへアクセスできる可能性があるため、テスト認証情報は一律に除外せず手動確認の対象として残している。

【まとめ】 汎用シークレット検出における誤検知削減は「確実に非シークレットと言えるものから取り除く」という小さな改善の積み重ねで実現できる。現時点でBetterleaksはこの公開前提キーの除外をデフォルトで適用済みであり、大規模な汎用シークレット検出の実用化に向けた取り組みが続いている。

原文を読む

Aikido Security Blog

英語で詳細な技術情報を確認

原文を読む

コメント・質問

この記事についてのコメントや質問を投稿できます

コメントを投稿するにはログインが必要です

ログインする

読み込み中...