GitHub AI & ML

GitHubのシークレット検出の仕組み:より少ないノイズでより多くのシークレットを発見

GitHubのコンテキスト認識型シークレット分類器は検出品質を向上させ、加重採用率を11.5%引き上げ、スキャンの実行時間の中央値を86%削減します。本投稿「GitHub’s model for secret detection: Finding more secrets with less noise」は初めて The GitHub Blog に掲載されました。

GitHub Copilot app for Beginners: Teach Copilot your codebase
画像の出典 · GitHub AI & ML
11.5%

より高い受理率

飼い主重み付け警告精度

86%

「中央値より下のスキャン実行時間」

プッシュ後スキャン

98%

低い提供コスト

コンパクトモデル vs. リモートLLM呼び出し

Secret scanningは、開発者がその検出結果を信頼できる場合に最も効果を発揮します。検出が少なすぎると、実際の認証情報がリポジトリに残ったままになる可能性があります。アラートが多すぎると、開発者が秘密ではない文字列の調査に時間を費やしてしまうかもしれません。

汎用的なシークレットは、このバランスを特に難しくします。同じ文字列が実際の認証情報である場合も、ドキュメントのプレースホルダーである場合もあるため、検出には周囲のコードやテキストの理解が必要です。

この課題に対処するため、私たちはGitHubの製品ニーズに特化した非公開の分類器を訓練しました。本物の認証情報と類似物を区別しながら、大規模なスキャンに求められる速度と効率の要件を満たすものです。

姉妹記事である以下の投稿では, 機密保護はソフトウェアとともに拡張しなければならない以前の記事では、AIによって加速された開発に秘密情報の保護を追いつかせなければならない理由を説明しました。ここでは、その取り組みを支えるコンテキスト認識型分類器の舞台裏をご紹介します。より少ないノイズでより多くの実際の秘密情報を発見できるよう、どのように設計、訓練、評価したかについて説明します。

私たちが有効にしたもの

GitHubのシークレットスキャンは、2つの重要なタイミングで動作します。

  • プッシュ保護 プッシュが受け付けられる前に変更をスキャンすることで、機密情報がリポジトリに入り込むのを防ぎ、開発者が検出された問題に対処する機会を提供します。
  • プッシュ後のスキャン コードがコミットされた後に動作し、リポジトリの内容を継続的にスキャンし、潜在的なシークレットが検出されるとアラートを作成して、開発者やセキュリティチームが調査および修復できるようにします。

私たちは高速な分類器を開発し、以前のLLMベースのパイプラインと比較して、プッシュ後スキャンの実行時間の中央値を86%削減しました。この効率化により、汎用的なシークレット検出をプッシュ保護に拡張し、コードがコミットされた後だけでなく、開発者が変更をプッシュする前に結果を返すことが実用的になりました。

シークレットスキャンがコミットをブロック モデルがファイルの5行目のシークレットを検出した後の、プッシュ保護の様子。

なぜシークレットの検出が難しいのか

構造化された認証情報には、特徴的なプレフィックス、長さ、文字セット、チェックサムが含まれていることがよくあります。汎用的なシークレットにはない場合があります。その構文は、ビルド識別子、チェックサム、アセットのハッシュ、サンプル値、その他の非機密文字列と重なることがあります。文脈が決定的なシグナルとなります。

実際の認証情報である可能性が高いおそらく無害な類似文字列
本番データベースのURLの横に割り当てられたパスワードテストフィクスチャ内の同じパスワード形式の値
デプロイ構成内の接続文字列セットアップガイド内のlocalhostへの接続文字列
APIクレデンシャルに紐付けられた高エントロピー値高エントロピーのチェックサム、ビルドID、またはアセットハッシュ

これらのケースはハードネガティブと呼ばれます。つまり、クレデンシャルのパターンには一致するものの、実際には使用可能なクレデンシャルではない文字列です。ルールを追加すれば一部を抑制できますが、例外を設けるたびに本当の秘密情報を見逃すリスクが生じます。代わりに学習型の分類器を使えば、ファイルパス、シークレットの種類、変数名、周辺のコードやテキストといったシグナルを活用できます。

そこで私たちは、2段階のパイプラインを用いた新しいスキャナーをリリースしました。

  1. 候補生成: 正規表現フィルターがコンテンツを走査し、高い再現率で潜在的なシークレットを検出します。この段階は、クレデンシャルに類似したパターンの幅広いファミリーを迅速かつ決定論的に捕捉できるよう最適化されています。
  2. 文脈認識型分類: ファインチューニングされた ModernBERT 分類器が、各候補とその周囲のコンテキストを評価します。このモデルは、プレースホルダー値、サンプル、ドキュメントのスニペット、生成されたコンテンツ、非機密の識別子など、本物のシークレットと偽陽性を区別するシグナルを認識するように訓練されています。このモデルは小規模で、当社の推論インフラストラクチャ上で効率的に実行できるため、LLM ベースのパイプラインに比べて提供コストがはるかに低く、スケーリングも簡単です。

影響:

  • ユーザー受容率が11.5%向上し、誤検知が減少しました。
  • プッシュ後のシークレット検出の実行時間が86%高速化。
  • LLMベースのパイプラインと比較して、98%以上のコスト削減を実現。

私たちのパイプラインの仕組み

コンテンツのスキャン時には、正規表現パターンが広く網を張り、認証情報らしきものはすべてフラグを立てるため、最初の段階で本物のシークレットを見逃すことはありません。その後、各候補はファインチューニングされたModernBERT分類器に送られ、分類器は値とともにファイルパス、変数名、周辺のコードを読み込みます。分類器はそれが本物のシークレットである可能性を推定します。高確度の検出結果はアラートとなり、プレースホルダー、テストフィクスチャ、チェックサムなどの類似品は開発者に届く前にフィルタリングされます。

ステップ 1

スキャン

リポジトリのコンテンツ、コミット、プルリクエスト、およびその他のスキャン対象領域。

STEP 2

候補を生成する

正規表現パターンは、可能性のあるトークン、キー、および認証情報に似た文字列を特定します。

ステップ 3

分類する

ファインチューニングされたModernBERTは、候補とコンテキストを評価し、真のシークレットである可能性を割り当てます。

ステップ 4

警告または抑制

高い信頼性のある所見は前進し、偽陽性の可能性が高いものは除外されます。

重要な設計上の選択は、モデルが決定論的なスキャンを置き換えないという点です。代わりに、それを補完します。正規表現は、候補となる文字列を素早く見つけるための適切なツールであり続けます。分類器が使用されるのは、機械学習が最も効果を発揮する場面、すなわち「シークレットに見える」ものと「本物のシークレットである可能性が高い」ものを区別する場合です。

分類モデルは「秘密らしく見えるもの」と「実際の秘密である可能性が高いもの」を区別するために最善を尽くします。

ハードネガティブ問題:本物にほぼ見える秘密情報

偽陽性の多くは無作為に発生するものではありません。それらはハードネガティブ、すなわち認証情報のパターンには一致するものの、実際には使用できない認証情報である文字列です。例として、ドキュメントのプレースホルダー、テスト内の toy example、マスキングされた値、機密性のない ID、生成されたフィクスチャなどが挙げられます。こうしたケースは正規表現には容易に一致する一方で、本物のシークレットを誤って失うことなく純粋なルールベースのシステムで抑止するのは困難です。

ModernBERTが役立つのは、候補を周辺のコードやテキストとともに読み取り、自然言語出力を生成する際の遅延や計算オーバーヘッドなしに、LLMに匹敵する文脈理解を提供できるためです。たとえば、「example」「dummy」「fake」「replace-me」などの単語に囲まれた候補は、デプロイファイル内の環境変数に割り当てられた候補よりもリスクが低い場合があります。この分類器は、エンジニアがすべての例外を別のルールとしてコーディングするのではなく、ラベル付きの例からこうした文脈の違いを学習します。

このワークロードには ModernBERT が最適と判断し、採用しました。コンパクトで効率的であり、コード関連のテキストに対する分類に適しているためです。シークレットスキャンでは、短い候補ウィンドウに対して高スループットかつ低レイテンシで、キャリブレーションされた判断を下す必要があります。

そのため、パイプラインのこの段階では、汎用LLMよりもファインチューニングされたエンコーダ分類器の方が適したサービング形態となります。このモデルは私たちの決定境界を直接学習でき、シークレットスキャンの品質に関わる同じ再現率と適合率の指標を用いて評価できます。

訓練方法について

課題は、構文だけでは誤解を招くケースの代表的なデータを見つけることでした。トレーニングと評価の戦略は、3つのソースを組み合わせています。

  • シークレット検出の経験からのフィードバックおよび追加の人手による検証を用いた、GitHubリポジトリ由来の製品導出事例。
  • GitHubリポジトリデータからの高再現率の正規表現候補。人手による注釈付き例や、カバレッジを拡大するために使用された弱いラベルを含みます。
  • ドキュメントのシークレット、テストフィクスチャ、公開鍵、チェックサム、構造が類似した偽物、そしてニアミスのペアなど、まばらで難しいケースを対象とした合成例。

合成データ行は、取り込まれる前に決定論的な検証とモデルベースの品質レビューを通過します。学習では、実際のシークレット、現実的な偽陽性、そして正規表現のみのアプローチを頻繁に混乱させる難しい負例(ハードネガティブ)が重視されます。各モデル入力には、候補値、ファイルパス、シークレットの種類、および限られた量の周辺コンテキストが含まれます。しきい値はオフライン評価を通じて選択し、その後、より広範なロールアウトの前に本番に近いトラフィックで動作を検証します。

データを分割する前に、リポジトリ、候補値、または例を共有する行をグループ化し、ほぼ重複するデータが訓練用と評価用の両方に現れないようにしました。

警告品質に最も重要なケースに焦点を当てたトレーニングです。すなわち、実際のシークレット、現実的な偽陽性、そして正規表現が頻繁に一致させるハードネガティブです。入力表現には、候補となるシークレット文字列、ファイルパス、タイプ、および有限量の周囲のコンテキストが含まれます。出力は、スキャナーが候補を処理すべきかどうかを判断するために使用される分類スコアです。

私たちは製品上のトレードオフを最適化しました。つまり、再現率を維持または向上させながら、偽陽性とサービス提供コストを削減することです。実際には、分類器のしきい値をオフライン評価で選定し、ロールアウト前に本番に近いトラフィックで検証することを意味します。

最も重要な訓練原則は、モデルに紛らわしい例を見させることでした。私たちは、実際のシークレットと構文的には似ているが意味的には異なる候補を含めました。これにより、モデルはシークレットがどのようなものかだけでなく、文脈の中で偽陽性がどのようなものかも学習します。

訓練済みモデルは8ビット量子化付きのONNX形式でエクスポートされ、高速な推論が可能になります。

評価結果

オンライン結果従来のLLMパイプラインとの変更点測定内容
リポジトリオーナーによる重み付け承認11.5%増 検出された所見に対する顧客の受容
プッシュ後のスキャン実行時間の中央値86%低下 本番スキャンの実行時間
サービングコスト98%以上低い リモートのLLM呼び出しと比較した場合のコンパクト分類器のコスト
ファインチューニングしたモデルを従来のLLMパイプラインと比較した際の、顧客によるA/B評価の結果です。

私たちは新しいパイプラインの本番環境での影響を2段階で評価しました。まず同じ公開トラフィックで本番のベースラインと比較し、その後、顧客を対象とするA/B実験を行いました。

  • オフライン評価: プッシュ後のスキャンにおいて、新しいパイプラインは 13%高い精度と19%高い再現率 同じ公開トラフィックで評価した場合、従来のLLMパイプラインと比較して。 
  • オンライン評価: 次に、これらの品質向上が顧客の成果につながったかどうかを、従来のLLMパイプラインに対するA/B実験を通じて検証しました。 リポジトリオーナー重量化による承認率は11.5%増加しました。 大量のアラートを一度に一括解決する顧客が単純平均を歪めてしまうのを防ぐため、リポジトリオーナーによる承認に重み付けを行っています。 

これを持ち歩く

開発者が信頼して使ってくれるセキュリティツールこそが最良のツールです。精度(適合率)が高いほど、注意を散らすアラートが減ります。再現率が高いほど、より多くの本物のシークレットを検出できます。コストが下がれば、スキャンを法外に高額にすることなく、カバレッジの改善を続けられます。

開発者やセキュリティチームにとって、これは誤検知の減少、そしてシークレットが混入されやすい場所、すなわちコミット、プルリクエスト、日常の開発ワークフローにおける迅速なフィードバックにつながるはずです。

ハイブリッドシステムは強力です。正規表現は速度、透明性、そして幅広い候補の網羅性をもたらします。ModernBERT は学習に基づく文脈理解と誤検出の削減をもたらします。この組み合わせにより、この製品の制約条件下では、どちらか一方のアプローチを単独で使う場合よりも優れた結果が得られます。

また、モデルのサイズはモデルの有用性と同一ではないことも学びました。タスクが狭く、決定境界が測定可能で、サービングの効率性が重要である場合には、より小さなファインチューニングされた分類器こそが正しい答えになり得ます。

これは、シークレットスキャニングをより正確で、スケーラブルで、使いやすいものにするための一歩です。今後、私たちは次の2つの領域に注力します。

  • 継続的な改善のフライホイールの構築。本番環境からのフィードバックループを活用して新たな偽陰性と偽陽性を特定し、実世界のシグナルをより高品質なトレーニングデータおよび評価データへと変換していきます。
  • 新しいモデルアーキテクチャの探索。シークレットの検出と抽出を1つのステップで実行できるアプローチを調査しており、精度とスケールを維持しながらパイプラインの複雑さを軽減します。

謝辞

この新しいシークレットスキャナーのトレーニングデータ、評価スイート、サービングスタック、およびロールアウト計画の構築を支援してくれた、GitHubおよびMicrosoft全体のエンジニアリング、サイエンス、プロダクトの各チームに心から感謝します。

その投稿 GitHubのシークレット検出モデル:より少ないノイズでより多くのシークレットを発見 「appeared first on」は記事の末尾でよく見られる定型フレーズで、「〜に最初に掲載された」という意味です。 完全な文脈がない断片のため、翻訳は以下のようになります。 **「以下に最初に掲載されました」** ただし、このフレーズは通常、直後にサイト名やURLが続く形式(例:`appeared first on Example Site`)で使われるため、隣接するセグメントと合わせて自然な日本語になるよう調整される場合があります。 The GitHub Blog.

原文の出典

GitHub AI & ML

内容について

原文の公開と権利は出典元に帰属します。

機械翻訳 · 原文をご参照ください