GitHub、全パブリックリポジトリを監視する「Public Monitoring」のパブリックプレビューを開始

GitHubは2026年7月1日、企業のシークレットスキャン対象を根本的に拡張する新機能「Public Monitoring」のパブリックプレビューを開始した。組織が管理するリポジトリだけでなく、GitHub.com上のすべてのパブリックリポジトリ、プルリクエスト、イシュー、ディスカッションをリアルタイムで監視し、検出された認証情報を該当する企業へと紐付ける。この機能は、GitHub Enterprise Cloudの顧客で、Secret ProtectionまたはAdvanced Securityを有効にしている場合、追加費用なしで利用可能である。

■深刻化するシークレット漏洩の現状

今回の新機能リリースの背景には、従来の組織境界型スキャナーでは対処しきれなくなっている深刻なセキュリティ危機がある。GitGuardianが発表した「2026年版シークレット拡散状況レポート（2026 State of Secrets Sprawl）」によると、2025年単体で2900万件もの新しいハードコードされたシークレットがGitHubのパブリックリポジトリに追加された。これは前年比34%増であり、過去最大の年間増加幅を記録している。特にAIサービスの認証情報漏洩は81%急増した。

また、Palo Alto NetworksのUnit 42研究チームの調査では、攻撃者は認証情報が公開されてから通常5分以内にパブリックリポジトリからIAM認証情報を収集していることが判明している。一方で、Verizonの「2025年データ侵害調査報告書（2025 Data Breach Investigations Report）」によると、企業チームが漏洩したシークレットを実際に修復するまでにかかる期間の中央値は94日間である。この「露出から対処までの89日間のギャップ」こそが、多くのデータ侵害が発生する原因となっている。

■組織の境界を越える開発者アクティビティと従来の死角

従来のシークレットスキャンには、構造的な死角が常に存在していた。開発者が個人のフォークにコミットしたり、オープンソースプロジェクトに貢献したり、あるいは個人アカウントからパブリックなイシューやプルリクエストにトークンを貼り付けたりする場合、それらは企業のセキュリティチームが監視する境界の外側で行われる。そのアカウントが企業のエンジニアのものであり、企業のAPIキーが含まれていたとしても、コミットされたリポジトリを企業が所有・管理していないため、組織スコープのスキャンツールでは検知できなかった。

このギャップは机上の空論ではない。2026年5月、サイバーセキュリティ企業Nightwingの請負業者が、844メガバイトに及ぶAWS GovCloudの認証情報、内部システムのパスワード、SSHキー、Kubernetes設定ファイルを、「Private-CISA」という皮肉な名前のパブリックGitHubリポジトリにコミットした。このリポジトリは、GitGuardianの研究者であるギヨーム・ヴァラドン（Guillaume Valadon）氏が発見するまで、約6ヶ月間パブリックにアクセス可能な状態のまま放置されていた。

この事例は、GitHubが今回防ごうとしている漏洩経路の典型例である。政府支給のノートPCと自宅のPCの間で業務ファイルを同期するために個人用GitHubアカウントが使用され、企業の監視境界の完全に外側で動作していた。リポジトリは公開されていたが、企業が使用していたスキャンツールはそこを監視していなかった。

■設定不要で紐付けを可能にするGitHubのアイデンティティ層

Public Monitoringの技術的な核心は、単なるパターンマッチングではない。パターンマッチング自体はGitHubに何年も前から備わっていた。差別化要因は「アトリビューション（紐付け）」である。プラットフォーム上のどこで見つかった漏洩認証情報であっても、企業側が監視場所を明示的に指定することなく、特定の企業に紐付けることができる。

GitHubはこれを、並行して動作する2つのメカニズムによって実現している。1つ目は「検証済みドメインの一致（verified domain matching）」である。企業は自社の電子メール ドメインをGitHubで検証でき、Public Monitoringはその検証済みドメインを使用して、一致するメールアドレスからのコミットを紐付ける。これは、アカウントが企業に正式にリンクされていない場合や、コミットしたユーザーのプロフィールでメールアドレスが非公開に設定されている場合でも機能する。

2つ目は、GitHub固有の「アイデンティティグラフ」である。アクティビティがGitHubのプラットフォーム上で行われるため、GitHubは外部のスキャンツールではアクセスできない内部のアカウント連携データを利用できる。パブリックなGitHubをクローリングするサードパーティ製スキャナーは、外部の人間と同様のアトリビューション問題に直面する。つまり、シークレットを発見することはできても、コミットを企業のアイデンティティに結びつけるには、メールアドレスから推測するか、管理者に組織に属するすべてのアカウントを事前に申告してもらう必要がある。GitHubの内部アイデンティティ層は、これら両方の制約を排除する。

実用上の成果として、GitHubの変更履歴（changelog）には、アトリビューションが「夜間の非同期クロールではなくリアルタイムで、コミットメールからの推測ではなくネイティブなプラットフォームのメタデータによって確定的に、そして監視を指示された場所だけでなく任意のパブリックリポジトリにわたって」行われると説明されている。

Public Monitoringによって生成される各アラートには、使用された紐付け方法、検出されたシークレットの種類、公開されていた場所（ファイル、イシュー、プルリクエスト、ディスカッションなど）、およびコミッターのアイデンティティが表示される。検証済みドメインの一致は、コミットを行ったアカウントが企業に正式に登録されていない場合でも適用される。

■漏洩率加速の構造的要因としてのAIコーディングエージェント

GitGuardianの2026年レポートが示すシークレット漏洩の加速は、主に開発者のモラルの問題ではなく、「速度」の問題である。GitGuardianの調査によると、AIコーディングツールと共同で作成されたコミットは、GitHub全体のベースライン率の約2倍の割合でシークレットを漏洩させている。AI支援開発ツールは、人間のレビューサイクルが追いつかないほどの速さで設定に関わるコードを記述する。さらに、MCP（Model Context Protocol）エコシステムが新たな認証情報の露出面を生み出しており、GitGuardianはパブリックなGitHub上のMCP設定ファイルだけで2万4008件の固有のシークレットを記録している。

この漏洩パターンは構造的なものである。AIコーディングエージェントは、人間開発のスピードに合わせて構築されたガバナンスメカニズム（コードレビュー、シークレットローテーションのワークフロー、プッシュ保護の例外処理など）を上回るペースで、インテグレーション、サービスアカウント、設定ファイルを生成する。開発者がAIエージェントにデプロイ設定の記述を依頼した際、エージェントには「既存の環境ファイルにあるAPIキーをハードコードするのを避ける」という訓練された直感は働かない。その結果、怠慢によるものではなく、高速開発において防ぐことが極めて困難な認証情報の露出が発生している。

■GitHubの3層防御アーキテクチャにおける位置づけ

GitHubは、シークレットセキュリティ製品を3つの連続する防御レイヤーとして構築しており、それぞれが認証情報漏洩のライフサイクルにおける異なる時点をターゲットにしている。

第1層は「プッシュ保護（push protection）」であり、検出されたシークレットを含むコミットがリポジトリに到達する前にブロックする。これにより、既知の認証情報フォーマットが公開されるのを未然に防ぐ。2026年3月時点で、プッシュ保護のデフォルト対象は拡張され、Figma、Google、OpenVSX、PostHogなどのパターンをカバーしており、現在では数十のプロバイダーがデフォルトで保護されている。

第2層は「MCPサーバーシークレットスキャン（MCP Server secret scanning）」で、パブリックプレビューを経て2026年5月に一般提供（GA）が開始された。このレイヤーは、コミットが形成される前、つまりAIコーディングエージェント自体のワークフロー内のさらに早い段階で検出を行う。開発者のAIコーディングエージェントがMCP互換のIDEで動作している場合、現在の差分（diff）に対してGitHubのシークレットスキャンエンジンを呼び出し、ファイルが保存される前に認証情報の露出を表面化させることができる。

そして第3層となる最新の機能が「Public Monitoring」である。プッシュワークフロー内や開発者環境内で動作する最初の2つのレイヤーとは異なり、Public Monitoringは遡及的かつ境界に依存しない形で動作する。有効化されると、すでに公開されている最近漏洩したシークレットを即座に表面化させ、今後のGitHub.com上でのすべてのパブリックアクティビティの監視を開始する。セキュリティタブで機能を有効にする以外に、セットアップや設定は不要である。

■ユーザーのプライバシー保護について

Public Monitoringがプライベートリポジトリをスキャンすることは決してない。その範囲は、すでにパブリックにアクセス可能なコンテンツ（パブリックリポジトリのファイルとコミット履歴、プルリクエストの説明とコメント、GitHubイシュー、GitHubディスカッション）に厳格に限定されている。GitHubが表明している設計原則は明確であり、この機能はすでに露出しているシークレットのみを表面化させ、攻撃者に悪用される前に企業が侵害された認証情報を無効化できるようにすることを目的としている。

このプライバシー境界は、ポリシーに依存するものではなく、構造的に強制されている。機能の設計上、企業の構成に関わらずプライベートリポジトリにアクセスすることはできない。エンタープライズオーナーおよびエンタープライズセキュリティマネージャーは、エンタープライズ設定の「セキュリティ」タブからPublic Monitoringを有効にできる。有効化すると、最近漏洩したシークレットが即座に表示され、今後のマッチングも発生の都度表面化する。

なお、データレジデンシー（データ格納国の指定）を伴うEnterprise Cloudのサポートは現時点では未対応だが、近日提供予定とされている。

■漏洩シークレットの検出は解決の半分に過ぎない

Verizonの2025年DBIRに記録された「修復時間の中央値94日間」という数値は、Public Monitoringができることとできないことを理解する上で最も重要な指標である。GitHubの新機能は、リアルタイムのプラットフォームネイティブ監視により、検出までの時間をほぼゼロに短縮する可能性がある。しかし、94日間のギャップは主に検出の失敗によるものではなく、修復の失敗によるものである。認証情報が漏洩したことを把握している企業であっても、それをローテーション（更新）するまでに平均して3ヶ月かかっているのが現状である。

シークレットのローテーションは、言葉で言うほど簡単ではない。ビルドシステム、CI/CD変数、コンテナイメージ、ベンダーインテグレーションなどに埋め込まれた認証情報は、それらに依存するすべての下流システムを把握しなければ交換できない。ローテーションによって本番環境が停止するリスクがあるため、チームが認証情報の露出を認識していても、修復を先送りするという組織的な圧力が生じる。GitGuardianの調査では、2022年に有効かつ漏洩したと確認された認証情報の64%が、2026年1月時点でも依然として悪用可能な状態であった。これは企業に検出ツールが不足していたからではなく、ローテーションや失効のワークフローが遅く、手動であり、自動化されていなかったためである。

Public Monitoringはセキュリティチームにアラートを提供する。その後に何が起こるか、つまりチームがどれだけ迅速に認証情報を無効化するか、自動化されたローテーションパイプラインが整備されているか、下流の依存関係がマッピングされているかによって、アラートが保護につながるか、未解決のバックログとして残るかが決まる。Public Monitoringを有効にする企業にとって、最も効果的な追加投資は、さらなるスキャンツールの導入ではなく、漏洩した認証情報をライフサイクル管理が義務付けられた非人間アイデンティティとして扱う、再現可能で文書化された失効ワークフローを構築することである。

■Enterprise Cloudユーザーが今すぐできること

Secret ProtectionまたはAdvanced Securityを利用しているGitHub Enterprise Cloudの顧客は、エンタープライズ設定の「セキュリティ」タブから今すぐPublic Monitoringを有効にできる。エンタープライズオーナーとエンタープライズセキュリティマネージャーの双方が、この変更を行うために必要なアクセス権を持っている。有効化すると、パブリックコンテンツ内で確認できる最近漏洩したすべてのシークレットが即座に表面化し、追加の設定は不要である。

初めてPublic Monitoringを有効にするセキュリティチームは、初期のトリアージ（優先順位付け）の急増に備える必要がある。企業内の開発者がパブリックリポジトリにどれだけ貢献してきたかによって、最初のスキャン結果でこれまで把握していなかった過去の露出が大量に表面化する可能性がある。これらの結果を、GitHub Secret Protection内でも利用可能な有効性チェック（validity checks）を用いて「アクティブな認証情報ステータス」ごとに処理することで、チームはすでに失効しているものではなく、現在も有効なシークレットを優先して対処し、アラート疲れに陥ることなく初期の処理件数を管理できる。

GitHubは、7月1日の変更履歴エントリにリンクされているコミュニティディスカッションを通じて、エンタープライズ顧客からのフィードバックを募集している。

■注目ポイントQ&A

●GitHub Public Monitoringとは何ですか？また、誰が利用できますか？

Public Monitoringは、現在パブリックプレビュー中のGitHub Secret Protectionの機能です。リポジトリファイル、プルリクエストのコメント、イシューなど、GitHub.com上のすべてのパブリックコンテンツをスキャンし、特定の企業に属する認証情報を検出します。GitHub Enterprise Cloudの顧客で、Secret ProtectionまたはAdvanced Securityを有効にしている場合、追加費用なしで利用できます。エンタープライズオーナーおよびエンタープライズセキュリティマネージャーが「セキュリティ」タブから有効化できます。

●開発者の個人アカウントから漏洩したシークレットを、GitHubはどのようにして自社に紐付けるのですか？

GitHubは2つのメカニズムを使用します。1つは「検証済みドメインの一致」で、組織がGitHubで電子メール ドメインを検証している場合、一致するメールアドレスからのコミットは、企業に正式登録されていないアカウントからであっても企業に紐付けられます。もう1つはGitHub固有の「アイデンティティグラフ」で、外部のスキャンツールではアクセスできない内部のアカウント連携データを利用します。これにより、コミットメールアドレスからの推測ではなく、確実かつリアルタイムな紐付けが可能になります。

●Public Monitoringは、認証情報が発見された時点で侵害を防ぐことができますか？

いいえ、防ぐことはできません。この違いは重要です。Public Monitoringは検出までの時間を大幅に短縮しますが、Verizonの2025年データ侵害調査報告書によると、企業が漏洩したシークレットを実際に失効・ローテーションするまでにかかる時間の中央値は94日間です。この機能はアラートを提供するだけであり、発見から保護までの期間を縮めるのは、文書化され自動化された失効ワークフローです。GitGuardianの2026年の調査では、2022年に漏洩し有効であると確認された認証情報の64%が4年後も悪用可能な状態であったことが示されており、信頼できる修復経路がなければ検出だけではリスクを排除できないことを証明しています。

●この機能は組織のプライベートリポジトリもスキャンしますか？

いいえ。Public Monitoringは、GitHub.com上ですでにパブリックにアクセス可能なコンテンツのみをスキャンします。プライベートリポジトリをスキャンすることは決してありません。対象はパブリックなGitコンテンツ、プルリクエストのコメント、イシュー、ディスカッションなど、すでにインターネットユーザーに露出している領域に限定されています。

元記事: GitHub Secret Scanning Now Watches All Public Repos for Leaked Enterprise Keys