ライフスタイル

GitHubのシークレットスキャンが新分類器に移行:文脈で本物を見分け、誤検知の減少と高速化を謳う

GitHubによると、コード内のパスワードやキーなどの認証情報を見つける「シークレットスキャン」は、ルールで候補を探し、小型AIモデルが判定する2段階の流れに変わった。GitHub自身の説明では、誤検知が減り、スキャンは高速化・低コスト化し、汎用シークレットもプッシュ前に止められるという。

読了目安 8 分

GitHubのシークレットスキャンが新分類器に移行:文脈で本物を見分け、誤検知の減少と高速化を謳う
画像:Mokaair (Original editorial artwork)

何が起きたのか

GitHubは公式ブログで、シークレットスキャン向けに学習させた、文脈を考慮するシークレット分類器について説明した。ここでの「シークレット」とは、パスワード、APIキー、接続文字列など公開すべきでない認証情報を指し、シークレットスキャンはそうした内容をコードから見つける機能である。GitHubによると、シークレットスキャンは2つのタイミングで動作する。プッシュ保護は、プッシュ(コードの変更をリポジトリ、つまりコードを置くプロジェクトの場所へアップロードすること)が受理される前に変更をスキャンする。プッシュ後スキャンは、コードがコミットされた後もリポジトリの内容を継続的にスキャンし、潜在的なシークレットを検出するとアラートを作成する。

GitHubによると、従来のLLMベースの流れと比べ、新しい分類器によりプッシュ後スキャンの実行時間の中央値が86%短縮された。この効率化により、汎用シークレットの検出をプッシュ保護にも広げ、開発者がプッシュする前に結果を返せるようになった。

汎用シークレットの判定が難しい理由

GitHubによると、汎用的なシークレットには、はっきりしたプレフィックス、長さ、文字セット、checksum(データが正しいかを確認するための文字列)があるとは限らない。その構文は、ビルドID、checksum、アセットのハッシュ、サンプル値といった機密ではない文字列と重なり得るため、文脈が決め手になる。一般の読者にとっては、同じ文字列でも本番の設定ファイルとテスト用サンプルでは意味がまったく異なり得る、ということだ。

新しい流れの仕組み

GitHubによると、新しいスキャナーは2段階で動く。第1段階では正規表現(regex、固定ルールで文字列のパターンを照合する方法)で広く候補を拾う。狙いは「高い再現率」、つまり本物のシークレットをできるだけ漏らさないことだ。第2段階では、この課題向けにファインチューニング(再学習)したModernBERT分類器が、各候補とその周辺の文脈を評価する。GitHubはこのモデルを小さく効率的だと説明している。モデルへの入力は候補値、ファイルパス、シークレットの種類、限られた範囲の周辺文脈で、出力は分類スコアであり、スキャナーはそれを基に候補を先へ進めるか判断する。

GitHubによると、分類器はプレースホルダー値、テスト用のダミーデータ(test fixture)、checksumなどの紛らわしい文字列を除外でき、確信度の高い検出結果だけがアラートになる。GitHubは、分類器はあくまで「シークレットらしく見えるもの」と「本物のシークレットである可能性が高いもの」を最善の努力で見分けるものだとも認めている。

GitHubが公表した成果

上記の数字はすべてGitHub自身が公表したもの
指標GitHubが公表した結果(従来のLLMの流れとの比較)
プッシュ後スキャン実行時間の中央値86%短縮
オフライン評価の適合率(同一の公開トラフィック)13%向上
オフライン評価の再現率(同一の公開トラフィック)19%向上
オーナー加重のアラート受け入れ率(顧客A/B実験)11.5%上昇
サービスコスト(リモートLLM呼び出しとの比較)98%超低下

表中の「適合率」は発したアラートのうち本当にシークレットだった割合、「再現率」は本物のシークレットのうち見つけられた割合を指す。「A/B実験」は新旧の流れを別々の顧客に割り当てて結果を比べるものだ。GitHubによると、受け入れ率はリポジトリのオーナーで加重しており、一度に大量のアラートを解決する顧客による歪みを抑えるためだという。

学習とデプロイの詳細

GitHubによると、学習データは3つの情報源を組み合わせている。GitHubのリポジトリ由来のプロダクト由来サンプル(シークレット検出機能の利用フィードバックと人手による検証を含む)、高再現率のregex候補(人手のラベルと、より粗い自動ラベルである弱ラベルを含む)、そしてドキュメント内のシークレット、テスト用ダミーデータ、公開鍵、checksumなどの難しいケース向けに作った合成サンプルである。学習前に、同じリポジトリ、候補値、サンプルを共有する行をグループ化し、ほぼ重複するデータが学習セットと評価セットの両方に入らないようにしている。

GitHubはさらに、推論(モデルが実際に判定を行う処理)を高速化するため、モデルを8ビット量子化(モデルの数値をより低い精度で保持すること)してONNXというモデルファイル形式で書き出したと述べている。今後は、本番環境のフィードバックを使った継続的改善のサイクルの構築と、シークレットの検出と抽出を一度に行える新しいモデルアーキテクチャの探索に注力するという。

一般の読者にとっての意味

GitHubによると、これにより開発者やセキュリティチームは誤検知が減り、コミット、プルリクエスト、日々の開発の流れの中でより速いフィードバックを得られるはずだという。GitHubの説明では、適合率が高いほど邪魔なアラートが減り、再現率が高いほど本物のシークレットをより多く捕捉でき、コストが低いほどスキャンの対象範囲を拡大し続けられる。

よくある質問

この分類器は従来のルールベースのスキャンを置き換えるものですか?

GitHubの説明では置き換えではない。regexは引き続き候補文字列を素早く生成し、分類器は「シークレットらしく見えるもの」と「本物の可能性が高いもの」を見分けて誤検知を減らす役割を担う。

プッシュ保護とプッシュ後スキャンとは何ですか?

GitHubによると、プッシュ保護はプッシュが受理される前に変更をスキャンし、開発者が対処する機会を与える。プッシュ後スキャンはコードのコミット後もリポジトリを継続的にスキャンし、潜在的なシークレットを検出するとアラートを作成する。

記事中の数字は信頼できますか?

これらの数字はすべてGitHub自身のブログに由来し、GitHubが自社製品について述べた自己申告である。その前提で読んでほしい。

GitHubは今後何を予定していますか?

GitHubは、本番環境のフィードバックに基づく継続的改善のサイクルを構築し、シークレットの検出と抽出を一度に行える新しいモデルアーキテクチャを探索するとしている。

このトピックの最新ニュースを見る

出典

ライフスタイル