秘密がGitHubの履歴に残ると何が起きるか

APIキーや内部データベースのパスワードなど、認証に使う秘密をシークレットと呼びます。変更を共有先のリポジトリ（コードと変更履歴を保存する場所）へ送る操作をpushと呼びます。コードや設定にシークレットを直接書いてpushすると、その値がGit（ソースコードの変更履歴を管理する仕組み）の履歴に残るおそれがあります。ファイルから値を消した後も、その値がGitの過去の履歴に残る場合があります。[12]

GitHubのsecret scanningは、リポジトリ内でシークレットを探す機能です。secret scanningは、すべてのブランチ（開発履歴を分岐させた作業ライン）のGit履歴を走査するため、送信後のシークレット検出に使えます。secret scanningは送信後の検出に使い、push protectionは送信前にpushを止めます。[12, 11]

後輩ファイルから消した後も、対応が必要になるのはなぜですか？

先輩履歴に値が残る可能性があるからだね。過去のコミットも確認対象になるよ。

後輩では、見つけた後は履歴の整理から始めるのでしょうか？

先輩まず認証情報を失効・更新するよ。履歴の整理は、その後に必要性を検討する作業だね。

形式照合で検出できる範囲

正規表現は、文字列の形式を表す規則です。GitHubの既存検出では、発行元ごとに決まったprovider patternと、秘密鍵や接続文字列などを対象とするgeneric patternを正規表現で照合します。形式が決まっているシークレットは、この方式で検出を始められます。[1]

組織独自の形式が決まっている場合は、利用者が正規表現によるcustom patternを定義し、検出対象を広げられます。既知のprovider形式、汎用形式、自社形式の順に、自社で必要な範囲を確かめることが導入の出発点です。[2]

検出方式主な対象有効性確認
provider pattern発行元ごとの形式が決まった秘密パターンごとに確認
generic pattern秘密鍵、接続文字列など非対応
AI-detected password形式の決まらないパスワード非対応

ここでいう有効性確認は、検出した値が発行元で現在も認証に使えるかを確かめることです。generic patternとAI-detected passwordは、この確認に対応していません。秘密らしい値の検出と、現在の有効性確認は別の処理です。[1, 6]

文脈分類が加える判定と速度の読み方

GitHubの公式解説は、内部データベースのパスワードのように、決まった識別パターンを持たない秘密もあると説明しています。そこでGitHubの新しいModernBERT分類器は、候補の周囲にあるコードの文脈を使って分類します。このモデルは候補を分類する役割を担います。[1, 3]

GitHubは、候補をまとめたバッチを2ミリ秒未満で評価すると報告しています。この値が示すのは、候補バッチの分類時間です。[3]

秘密ではない値を秘密と判定する誤検知と、秘密を検出できない見逃しは、どちらも運用上の確認対象です。GitHubは、適合率、遅延、処理量、費用を相互に関係する制約として説明しています。適合率は秘密と判定した候補のうち実際に秘密だった割合です。遅延は判定にかかる時間、処理量は一定時間に処理する候補数です。[4]

事後に確認する候補とpushを止める候補では、必要な判定のバランスが異なります。誤検知による遮断は、開発者の作業を中断するためです。[4]

AI検出全般について、公式文書は誤検知と見逃しの可能性を示しています。公式文書は、担当者にアラートをレビューし、誤検知と確認したアラートをFalse positive（誤検知）として閉じるよう推奨しています。この一般的な注意は、新しい分類器の誤検知率や見逃し率を示す数値評価ではありません。[5]

後輩形式照合に分類を足すと、導入時の確認基準はどう変わりますか？

先輩形式が決まった秘密は規則で拾い、形だけでは判断しにくい候補を文脈分類で補う設計になるね。

後輩pushを止める設定では、誤検知が開発者の作業に影響しますね。

先輩そうだね。対象にしたい秘密と、候補を確認する担当を合わせて考える必要があるよ。

push前の防止と漏えい後の対応

既存のpush protectionは、シークレットを含むpushがリポジトリへ到達する前に遮断します。既定のリポジトリ設定では、書き込み権限を持つ人が理由を指定してbypass（遮断の回避）できます。その操作はアラートと監査ログ（操作の記録）に記録されるため、管理者は遮断を通過したケースも後から追跡できます。[11]

運用担当者は、漏えいアラートを受けたら認証情報を失効させ、新しい値への更新を優先します。履歴からの削除は認証情報の失効に代わらないため、二つの作業を分けて扱います。すでに失効させた値の履歴削除には時間がかかり、不要な場合もあるとGitHubは説明しています。[12]

提供状況と導入前に確認すること

以下は2026年10月7日のGitHub公式発表時点の状況です。既存のAI-detected Passwordアラートは新モデルへ移行済みです。新しいAI push protectionはprivate preview（一部利用者向けの試験提供）です。Copilot CLI/Appの/security-reviewへの分類器追加は、近日中にprivate previewとして提供される予定です。[7]

GHSP（GitHub Secret Protection）はシークレット保護機能の契約です。GHAS（GitHub Advanced Security）は高度なセキュリティ機能の契約で、どちらもCopilot契約とは別です。 AI Creditsは、対象のAI機能の利用量に応じて消費するクレジットです。[8, 13]

機能10月7日時点の提供状況契約・有効化・費用
既存のAI-detected Passwordアラート新モデルへ移行済みGHSP/GHASに追加費用なし
AI push protection一部利用者向け試験提供対応するTeam/Enterprise CloudとGHSP/GHASの購入が必要。管理者が有効化。AI Creditsを消費する予定
/security-reviewへの新分類チェック近日中に一部利用者向け試験提供予定既定で無効。実行だけでは有効にならない。AI Creditsを消費する予定

既存アラートと、新たに利用するopt-in（利用者が選択して有効にする方式）のチェックでは、費用の扱いも異なります。[8, 9]

既存のCopilot CLI（コマンドラインから操作するCopilot）の/security-reviewは、コード内の悪用可能な脆弱性を探します。この機能は、確信度の高いfinding（検出結果）を読み取り専用で報告します。今後追加される分類器は、この既存レビューとは別のチェックとして案内されています。[7, 10]

導入担当者は、導入前に利用資格、管理者による有効化、費用の扱いを確認します。利用停止が必要な場合は、対象の予算に「Stop usage when budget limit is reached」などの停止オプションが設定されているかを確認してください。[8, 13]