GitHub の「Secret scanning public monitoring for enterprises」は、企業が所有していない公開リポジトリや公開Issue、Pull Requestコメントなどに漏れたシークレットを、Enterpriseにひも付けて検知するための新しい監視機能です。従来のSecret scanningは主に自社が管理するリポジトリ内の漏えい検知が中心でしたが、今回のPublic monitoringにより、個人アカウント、個人フォーク、OSSプロジェクト、公開コメント欄など、企業の管理境界の外で起きた漏えいにも気づきやすくなります。GitHub公式Changelogでは2026年7月1日付の更新として公開されており、Public Previewとして提供されています。 (The GitHub Blog)
管理者がまず確認すべきことは、利用中のEnterpriseが対象条件を満たしているか、Verified domainが設定されているか、漏えい検知後の対応フローが決まっているかの3点です。開発者は「会社のリポジトリに入れていないから安全」と考えず、個人アカウントでの公開コミットやIssueへの貼り付けも検知・対応対象になり得る点を理解しておく必要があります。
Secret scanning public monitoring for enterprisesの更新ポイント
今回の変更点を一言でまとめると、GitHub上の公開領域で漏れた企業関連のシークレットを、Enterprise単位で見つけやすくする機能が追加された、ということです。
GitHubは、Public monitoringについて「GitHub.com上の公開領域をリアルタイムに監視し、公開されたシークレットをEnterpriseに関連付ける」と説明しています。対象には、Gitのコンテンツだけでなく、Pull RequestコメントやIssueなどの非コード領域も含まれます。 (The GitHub Blog)
| 確認項目 | 従来のSecret scanning | Public monitoringで広がる範囲 |
|---|---|---|
| 主な検知対象 | 自社が所有・管理するリポジトリ内のシークレット | GitHub.com上の任意の公開リポジトリや公開コンテンツ |
| 想定される漏えい例 | 社内リポジトリにAPIキーをコミット | 個人フォーク、OSSへのコミット、公開IssueやPRコメントへの貼り付け |
| 表示場所 | リポジトリや組織のSecret scanning alert | EnterpriseレベルのSecurity overview内のPublic monitoring |
| 目的 | 自社リポジトリ内の漏えい検知 | 企業の管理境界外で起きた公開漏えいの早期発見 |
| 注意点 | 検知後のローテーションが必要 | 検知範囲は公開済みの情報に限られ、プライベートリポジトリはスキャンしない |
重要なのは、Public monitoringが「非公開情報をのぞきにいく機能」ではない点です。GitHubは、Public monitoringはプライベートリポジトリをスキャンせず、すでに公開されているシークレットのみを表示すると説明しています。 (The GitHub Blog)
利用できる対象と前提条件
Public monitoringは、GitHub Enterprise CloudでGitHub Advanced SecurityまたはGitHub Secret Protectionが有効なEnterprise向けの機能です。公式ドキュメントでは、GitHub Enterprise Cloud with data residencyでは利用できないと説明されています。一方、Changelogではdata residencyへの対応は今後予定されていると案内されています。 (GitHub Docs)
また、Public monitoringはPublic Previewです。GitHub Docsでも「Public Previewであり変更される可能性がある」と明記されているため、本番運用に組み込む場合は、画面・権限・API連携などが今後変わる可能性を前提にしておくべきです。 (GitHub Docs)
対象ユーザー別に見る影響
| 立場 | 確認すべきこと | 実務上のポイント |
|---|---|---|
| Enterprise管理者 | 対象プラン、Secret ProtectionまたはAdvanced Securityの有効化状況、Verified domain | 有効化前にインシデント対応フローを決めておく |
| セキュリティ担当者 | Public monitoring alertの確認場所、通知・エスカレーション方法 | 検知後は削除より先に失効・ローテーションを優先する |
| 開発者 | 個人アカウント、OSS、Issue、PRコメントでのシークレット露出 | 「社外リポジトリだから関係ない」という認識を改める |
| 一般ユーザー | 会社メールを紐付けたGitHubアカウントの使い方 | 会社関連トークンやAPIキーを公開コメントに貼らない |
どのようにEnterpriseへ関連付けられるのか
Public monitoringの実務上の価値は、単に「公開リポジトリを広くスキャンする」ことではありません。検出したシークレットを、どのEnterpriseに関係するものか推定・関連付ける点にあります。
GitHubは、Public monitoringの関連付け方法として、主に次の2つを説明しています。 (The GitHub Blog)
| 関連付け方法 | 見ている情報 | 検知しやすいケース |
|---|---|---|
| Enterprise membership | コミットしたGitHubアカウントがEnterpriseメンバーかどうか | 管理対象アカウントや既知のメンバーによる漏えい |
| Verified domain matching | コミッターのメールアドレスがEnterpriseまたはOrganizationの検証済みドメインと一致するか | 個人アカウントで会社メールを使って公開コミットしたケース |
特に注意したいのは、Verified domain matchingです。GitHubは、アカウントがEnterpriseに直接リンクされていない場合や、メールアドレスが公開されていない場合でも、検証済みドメインに基づく関連付けが適用されると説明しています。つまり、社員が個人アカウントでOSSにコミットした場合でも、会社メールの情報が関係していれば、Enterprise側の検知対象になる可能性があります。 (The GitHub Blog)
管理者が最初にやるべき設定確認
Public monitoringは「有効化すればすぐ便利」な機能ですが、何も準備せずにオンにすると、アラートを見つけても誰が何をすべきか分からず対応が遅れます。導入前に、少なくとも次の順番で確認してください。
対象条件を確認する
まず、EnterpriseがGitHub Enterprise Cloudであり、GitHub Advanced SecurityまたはGitHub Secret Protectionが有効になっているかを確認します。公式ドキュメントでは、Public monitoringの利用要件としてこの条件が示されています。 (GitHub Docs)
契約や機能名は時期によって変更される可能性があるため、管理画面の表示とGitHub Docsの最新情報を照らし合わせるのが安全です。特にdata residencyを使っているEnterpriseでは、本稿時点の公式ドキュメント上は対象外とされているため、利用可否を管理画面またはGitHubサポートで確認してください。 (GitHub Docs)
Verified domainを整備する
Public monitoringの精度を高めるうえで、Verified domainは重要です。GitHubの有効化手順でも、必須ではないものの、機能の価値を最大化するために少なくとも1つのVerified domainを設定することが推奨されています。 (GitHub Docs)
Verified domainは、Enterprise配下のOrganizationに設定されたWebサイトやメールアドレスのドメインが、そのEnterpriseにより管理されていることを確認する仕組みです。GitHub Docsでは、www.example.comとexample.comのようなドメイン違いがある場合、それぞれ検証が必要になる例も示されています。 (GitHub Docs)
| 確認項目 | 例 | 見落としやすいポイント |
|---|---|---|
| 会社メールのドメイン | example.co.jp | 子会社・関連会社・旧社名ドメインが抜ける |
| Webサイトのドメイン | www.example.co.jp | メールドメインとWebドメインが異なる |
| 開発委託先の扱い | 協力会社メール、業務用外部ドメイン | 安易に承認すると検知範囲や通知制御の意図が曖昧になる |
| DNS TXTレコード | GitHub指定のTXTレコード | DNS反映に時間がかかる場合がある |
ドメイン検証ではDNS TXTレコードの追加が必要で、DNS設定の反映に最大72時間かかる場合があるとGitHub Docsに記載されています。セキュリティ担当だけで完結しないことが多いため、情シスやDNS管理者と事前に調整しておくとスムーズです。 (GitHub Docs)
Public monitoringを有効化する
GitHub Docsの手順では、EnterpriseのSettingsから「Advanced Security Code security」に進み、「Additional Settings」内のPublic monitoringをトグルで有効化します。Changelogでは、Enterprise ownersとenterprise security managersがSecurityタブから有効化できると説明されています。 (GitHub Docs)
実務では、誰が有効化できるかを画面で確認し、権限を持つ人を複数名にしておくと安全です。セキュリティ担当者だけが把握していて、実際のEnterprise ownerが手順を知らない、という状態は避けてください。
Public monitoring alertの見方
Public monitoringのアラートは、EnterpriseレベルのSecurity overview内にある専用ページで確認します。GitHub Docsでは、このPublic monitoringページはEnterpriseレベルでのみ利用でき、Organizationレベルでは利用できないと説明されています。 (GitHub Docs)
アラート一覧には、検出されたシークレットの種類、部分的なシークレット値、誰に関連付けられた漏えいか、どの公開リポジトリで検出されたか、検出からどれくらい経過したかが表示されます。アラートを開くと、コミット日、フルのシークレット文字列、コミッターのユーザー名やメール、ファイル上の位置、推奨対応などを確認できます。 (GitHub Docs)
ここで注意したいのは、詳細パネルにフルのシークレット値が表示され得ることです。対応チケットやチャットにそのまま貼り付けると、二次漏えいになります。アラート対応時は、次のように運用を決めておくと安全です。
| 場面 | 避けるべき対応 | 推奨される対応 |
|---|---|---|
| チケット起票 | シークレット文字列を全文貼る | シークレット種別、検出場所、所有者、対応状況だけを書く |
| 開発者への連絡 | 公開チャネルで詳細を共有 | 限定されたセキュリティチャンネルやインシデント管理ツールを使う |
| 証跡保管 | スクリーンショットを無制限に共有 | アクセス権限を絞った場所に保管する |
| 原因調査 | まず該当コミットを削除する | 先に失効・ローテーションし、後で履歴整理を検討する |
漏えいを検知したら最初にやること
シークレット漏えい対応で最も重要なのは、「削除」ではなく「失効」です。GitHub Docsは、漏えいしたシークレットは直ちに侵害されたものとみなし、シークレットの取り消しなどの適切な対応が必要だと説明しています。単にコードから削除する、新しいコミットをpushする、リポジトリを削除して作り直すだけでは、悪用を防げません。 (GitHub Docs)
対応手順の基本
| 手順 | やること | 判断基準 |
|---|---|---|
| 影響確認 | シークレット種別、プロバイダー、検出場所、所有者を確認 | APIキー、PAT、クラウド認証情報、SSH秘密鍵などを分類する |
| リスク判定 | 有効性、公開露出、本番利用、権限範囲を確認 | 本番・管理者権限・有効なキーは最優先 |
| 失効・ローテーション | プロバイダー側で古いシークレットを無効化し、新しい値へ切り替える | ダウンタイムが懸念される場合は新しい値へ切り替えてから旧値を失効する |
| 影響範囲の調査 | アプリ、CI/CD、GitHub Actions、外部連携で使用箇所を確認 | org:YOUR-ORG "SECRET-STRING"などの検索も活用する |
| 不正利用確認 | GitHub監査ログやプロバイダー側の監査ログを確認 | 利用時刻、IP、実行された操作を確認する |
| 事後整理 | 履歴削除、アラートクローズ、ナレッジ化 | Git履歴の書き換えは破壊的なため慎重に実施する |
GitHub Docsでは、高リスクのシークレットは即時失効を優先すべきと説明しています。一方で、サービス停止が懸念される場合は、同じ権限を持つ新しいシークレットを生成し、アプリケーションを新しい値に切り替えてから古いシークレットを失効する方法も示されています。 (GitHub Docs)
なお、公開リポジトリに漏えいしたGitHub personal access tokenはGitHubが自動的に取り消すと説明されています。また、GitHubのサポートするパートナーパターンに一致する他社シークレットが公開リポジトリに漏れた場合、GitHubがプロバイダーへ自動通知し、プロバイダー側で取り消される場合があります。とはいえ、利用者側での確認と影響調査は省略できません。 (GitHub Docs)
開発者が気をつけるべき実務上のポイント
Public monitoringが導入されると、開発者にとって「どこに書いたか」よりも「公開されたかどうか」が重要になります。会社のGitHub Organization内ではなくても、公開されていれば検知対象になり得ます。
特に注意すべき場面は次の通りです。
- 個人アカウントで作った検証用リポジトリに、業務用APIキーを入れてしまう
- 会社のコードを参考にした個人フォークへ、
.envや設定ファイルを誤ってpushする - OSSのIssueやPull Requestコメントに、エラーログとしてトークン付きURLを貼る
- 社内向けのサンプルコードをGistや公開リポジトリに置く
- 会社メールを使った個人GitHubアカウントで、業務に近い内容を公開コミットする
対策は、ツールだけでなく習慣として定着させる必要があります。APIキーやトークンはソースコードに直書きせず、GitHub ActionsのSecrets and variables、クラウドのシークレット管理サービス、Vault系の仕組みなどに分離します。GitHub Docsでも、機密資格情報を安全に渡す方法としてVaultやGitHub ActionsのSecrets and variablesが例示されています。 (GitHub Docs)
また、開発用トークンには最小権限と有効期限を設定してください。万一漏えいしても、権限が限定されていれば被害範囲を抑えられます。検証用に強い権限のトークンを長期間使い回す運用は、Public monitoring以前に危険です。
一般ユーザー・個人アカウント利用者が知っておくべきこと
GitHubを業務と個人の両方で使っている人は、会社メールを登録した個人アカウントの扱いに注意が必要です。Public monitoringでは、Enterpriseメンバーであるかどうかに加え、Verified domain matchingによって、会社の検証済みドメインと一致するメールアドレスを使った漏えいも関連付け対象になります。 (The GitHub Blog)
これは、個人活動をすべて会社が監視するという意味ではありません。GitHubは、Public monitoringはプライベートリポジトリをスキャンせず、すでに公開されているシークレットのみを扱うと説明しています。 (The GitHub Blog)
ただし、公開リポジトリや公開Issueに会社関連のトークンを貼れば、会社のインシデント対応対象になります。個人アカウントであっても、業務用のクラウドキー、GitHub PAT、CI/CDトークン、SaaS APIキーなどを扱う場合は、会社のセキュリティルールに従ってください。
導入時に失敗しやすいポイント
Public monitoringは、オンにするだけで完結する機能ではありません。むしろ、有効化後に検出されたアラートをどう扱うかを決めていないと、せっかくの検知が対応遅延につながります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| Verified domainを設定していない | 個人アカウントや会社メール由来の漏えいを拾いにくい | 主要ドメイン、子会社ドメイン、旧ドメインを棚卸しする |
| アラート確認者が1人だけ | 休暇や異動で対応が止まる | Enterprise owner、security manager、CSIRTで役割分担する |
| 削除を最初に実施する | シークレットが有効なまま悪用される | 先に失効・ローテーションする |
| フルシークレットをチケットに貼る | 二次漏えいが発生する | マスク値と検出場所だけで管理する |
| 開発者へ説明しない | 個人リポジトリやOSSで同じ事故が繰り返される | 具体例付きの社内ルールを配布する |
| Public Previewを前提にしない | 画面や仕様変更で運用が崩れる | 定期的にGitHub DocsとChangelogを確認する |
どの企業が優先して有効化すべきか
Public monitoringは、GitHub Enterprise Cloudを利用していて、かつ開発者が社外リポジトリやOSS活動に関わる企業ほど優先度が高い機能です。特に、次の条件に当てはまる場合は早めに確認した方がよいでしょう。
- 開発者が個人GitHubアカウントも業務で使っている
- OSSへのコントリビューションが多い
- 社内外の委託先やパートナーとGitHub上で協業している
- クラウドAPIキー、SaaSトークン、GitHub PATを多く扱っている
- 過去に
.envや認証情報の誤コミットが発生したことがある - セキュリティチームが個人フォークや公開Issueまで追跡できていない
一方で、Public monitoringは漏えいの「予防」ではなく「発見」を強化する機能です。Push protection、Secret scanning、最小権限、短命トークン、シークレット管理基盤、開発者教育と組み合わせて運用することで、初めて効果が出ます。
まとめ：まずは有効化条件と対応フローを確認する
Secret scanning public monitoring for enterprisesは、GitHub Enterpriseの管理境界外で起きるシークレット漏えいを見つけるための重要な更新です。従来のSecret scanningだけでは見落としやすかった、個人フォーク、OSS、公開Issue、Pull Requestコメントなどでの漏えいに気づける点が大きな価値です。
次に取るべき行動は明確です。まず、GitHub Enterprise CloudでGitHub Advanced SecurityまたはGitHub Secret Protectionが有効かを確認します。次に、Verified domainを整備し、Enterpriseの設定からPublic monitoringを有効化します。そのうえで、アラートを見つけたら誰が、どの順番で、どのシークレットプロバイダーを使って失効・ローテーションするかを運用手順に落とし込んでください。
検知できる範囲が広がるほど、対応の速さと正確さが問われます。Public monitoringを単なる新機能として扱うのではなく、開発者の個人利用、OSS参加、インシデント対応を含めた「GitHub上のシークレット漏えい対策」として整備することが重要です。
コメント