GitHubが漏洩シークレット検出専用AIを導入｜形式のない認証情報も発見

GitHubは2026年10月7日、ソースコード内の認証情報を見つけるために調整した専用AIモデルを発表しました。従来の定型的な文字列検出だけでなく、周囲のコードを読み取り、決まった形式を持たないパスワードなども検出対象にします。

既存のAI検出アラートを利用する顧客は新モデルへ自動的に移行します。GitHub Secret ProtectionとGitHub Advanced Securityに含まれる既存アラートは、追加料金なしで継続すると案内されています。

【なぜ従来の検出だけでは不十分なのか】APIキーのように決まった接頭辞や長さを持つ情報は、パターン照合で候補を見つけやすい一方、開発者が独自に設定したパスワードや内部サービスの認証文字列には共通の形式がない場合があります。文字列そのものに加えて変数名、代入先、呼び出し方などの周辺情報を考慮することが、今回の技術的な焦点です。

【検出の流れを考える】例えば設定ファイルに接続先、ユーザー名、パスワードらしい値が並んでいる場合、単独の文字列では秘密情報と断定できなくても、周囲の文脈から調査対象を絞れる可能性があります。ただし、これは仕組みを理解するための例であり、特定のコードを必ず検出できるという意味ではありません。

【発見後に必要な対応】認証情報をコードから削除するだけでは不十分な場合があります。既にリポジトリの履歴、ビルドログ、配布物などに残っていれば第三者が利用できる可能性があるため、対象の資格情報を失効させて再発行し、利用先と影響範囲を調査します。対応手順を事前に決めておくことが重要です。

【誤検知と見逃しをどう評価するか】検出件数が増えても、無害なテストデータへの警告ばかりなら運用負荷が高まります。一方で重要な認証情報の見逃しは深刻です。警告の有効率、確認にかかった時間、発見から失効までの時間を継続して測ると、導入効果を判断しやすくなります。

【プレビュー機能との違い】既存のAI検出アラートの更新と、プッシュ時にAIで確認する機能は提供段階が異なります。後者はプライベートプレビューと案内されているため、すべての利用者が直ちに使えると解釈すべきではありません。利用条件やAI Creditsの扱いも機能ごとに確認が必要です。

【開発チームの予防策】秘密情報は環境変数や専用のシークレット管理基盤から取得し、ソースコードへの直接記載を避けます。権限を最小化し、有効期限を短くし、検出アラートの担当者と対応期限を明確にすることが、AIによる検出を補完します。

【仕組みと背景】従来のシークレットスキャンは、特定の文字列パターンに一致する認証情報を見つける方法が中心でした。形式の決まっていない秘密情報は検出が難しい場合があります。

【導入時の課題】コードの文脈を読むAIモデルは、変数名や利用箇所から認証情報の可能性を判断することが期待されます。ただし、誤検知や見逃しを完全になくせるわけではありません。

【検証と今後】検出したシークレットは削除するだけでなく、失効や再発行が必要になる場合があります。公開履歴に残っていないかの確認も重要です。

【今後の注目点】技術の新しさだけでなく、既存の作業へ無理なく組み込めるか、導入費用に見合う効果があるか、利用者が結果を検証できるかが普及を左右します。実際の運用事例と継続的な評価が、今後の判断材料になります。

コードのプッシュ時にAIが認証情報を確認する機能はプライベートプレビューです。Copilotのsecurity-reviewコマンドへの対応もプライベートプレビューで提供予定とされ、追加のAI Creditsを消費する仕組みが案内されています。

AIによる検出は、定型パターンに一致しない秘密情報を見つける補助になります。ただし、誤検知や見逃しがあり得るため、認証情報のローテーション、最小権限、シークレット管理サービスと併用する必要があります。