GitHubの内部リポジトリ不正アクセス調査でまず押さえるべき結論は、2026年5月20日時点で、GitHubは顧客自身のEnterprise、Organization、Repositoryなど、GitHub内部リポジトリ外に保存された顧客情報への影響を示す証拠はないとしている点です。一方で、GitHub内部リポジトリの一部にはサポート対応の抜粋など顧客由来の情報が含まれる可能性があるため、GitHub管理者は「通知の確認」「監査ログの確認」「資格情報の棚卸し」をすぐ実施すべきです。(The GitHub Blog)
今回の件は、GitHubを使うすべての組織がパニック的に全リポジトリを移行するような話ではありません。ただし、ソフトウェア開発基盤であるGitHubに関するセキュリティ情報である以上、組織の管理者、セキュリティ担当者、開発リーダーは「自社に関係する通知が来ていないか」「不審なアクセスやトークン利用がないか」「開発端末やVS Code拡張機能にリスクがないか」を確認しておく必要があります。
GitHub内部リポジトリ不正アクセス調査で何が起きたのか
GitHubは2026年5月20日、従業員端末の侵害に関連して、GitHubの内部リポジトリへの不正アクセスを調査していると公表しました。GitHubによると、2026年5月18日に、第三者が公開した悪意あるVS Code拡張機能に関係する従業員端末の侵害を検知し、問題の拡張機能バージョンの削除、端末の隔離、インシデント対応を開始したとされています。(The GitHub Blog)
現時点でGitHubが示している主なポイントは次のとおりです。
| 確認項目 | GitHubの公表内容 | 管理者が取るべき見方 |
|---|---|---|
| 侵害の起点 | 従業員端末の侵害。悪意あるVS Code拡張機能が関係 | 自社でもVS Code拡張機能と開発端末の確認が必要 |
| 影響範囲 | 現在の評価ではGitHub内部リポジトリのみ | 顧客リポジトリ自体の流出と決めつけない |
| 攻撃者の主張 | 約3,800リポジトリという主張は調査状況と方向性として一致 | 数字だけで過剰判断せず、公式続報を確認 |
| 顧客情報への影響 | 顧客自身のEnterprise、Organization、Repositoryなど、内部リポジトリ外の顧客情報への影響を示す証拠はない | 「影響なし」と断定せず、個別通知の有無を確認 |
| 内部リポジトリ内の顧客情報 | サポート対応の抜粋などが含まれる可能性 | GitHub Supportに共有した機微情報を思い出す |
| GitHub側の対応 | 重要なシークレットをローテーションし、ログ分析と監視を継続 | 自社側も資格情報とログを確認する |
重要なのは、「GitHubの顧客リポジトリが直接流出した」と読み替えないことです。GitHubの発表は、現時点の評価として内部リポジトリへの流出を中心に説明しています。一方で、調査は継続中であり、GitHubは影響が判明した場合には既定のインシデント対応・通知チャネルで顧客に連絡するとしています。(The GitHub Blog)
影響範囲を判断するために見るべきポイント
GitHub管理者が最初に確認すべきなのは、「自社のリポジトリが流出したか」だけではありません。今回のようなケースでは、次の3つを分けて考えると判断しやすくなります。
顧客リポジトリそのものへの影響
GitHubは、顧客自身のEnterprise、Organization、Repositoryなど、GitHub内部リポジトリ外に保存された顧客情報への影響を示す証拠はないと説明しています。つまり、現時点の公式情報だけを根拠に「自社のプライベートリポジトリが流出した」と判断するのは早計です。(The GitHub Blog)
ただし、これは「確認不要」という意味ではありません。組織の監査ログ、GitHub Apps、OAuthアプリ、個人アクセストークン、Actions secretsなどの状態を確認し、普段と異なるアクセスや権限変更がないかを見ておくべきです。
GitHub内部リポジトリに含まれ得る顧客関連情報
GitHubは、一部の内部リポジトリに顧客情報が含まれる可能性として、サポート対応の抜粋を例に挙げています。(The GitHub Blog)
ここで注意したいのは、サポート問い合わせ時に共有した情報です。たとえば、障害調査のために以下のような情報をGitHub Supportへ送っていた場合は、影響通知の有無を特に注意して確認してください。
| 共有していた可能性がある情報 | 取るべき対応 |
|---|---|
| エラーログ、CI/CDログ | トークンやURL、内部ホスト名が含まれていないか再確認 |
| リポジトリ名、Organization名 | 機微なプロジェクト名が外部に伝わるリスクを評価 |
| 設定ファイルの抜粋 | APIキー、接続文字列、Webhook URLが含まれていないか確認 |
| 認証・SSO・SAML関連の相談内容 | IdP設定、ドメイン、管理者アカウント情報の露出可能性を確認 |
| GitHub Actionsの実行ログ | Actions secretsの値が出力されていないか確認 |
特に、ログや設定ファイルにシークレットを含めてサポートに送った記憶がある場合は、GitHubからの個別通知を待つだけでなく、該当する資格情報の無効化や再発行を検討した方が安全です。
開発者端末とVS Code拡張機能のリスク
GitHubの発表では、従業員端末の侵害に悪意あるVS Code拡張機能が関係したとされています。GitHub公式発表のリンク先で示されているアドバイザリでは、Nx Consoleの侵害版としてバージョン18.95.0が挙げられ、修正版は18.100.0とされています。(GitHub)
自社の開発者がNx Consoleや関連するVS Code拡張機能を利用している場合は、以下を確認してください。
| 確認項目 | 具体的な作業 |
|---|---|
| 影響バージョンの利用有無 | Nx Console 18.95.0を利用していた端末がないか確認 |
| 拡張機能の更新状態 | 最新の安全なバージョンへ更新 |
| 端末上の不審なファイル・プロセス | 公式アドバイザリのIoCを参照して確認 |
| 端末内の資格情報 | GitHubトークン、SSH鍵、npm token、クラウド認証情報を棚卸し |
| 侵害が疑われる端末 | ネットワーク隔離、EDR調査、資格情報ローテーションを実施 |
VS Code拡張機能は開発者の作業効率を高める一方で、ローカルファイル、ターミナル、認証情報、プロジェクト設定に近い位置で動作します。組織としては「便利だから各自で自由に入れる」状態から、許可リスト方式や定期棚卸しへ移行することが現実的な対策になります。
GitHub管理者が最初に実施すべき対応
今回のGitHub内部リポジトリ不正アクセス調査を受けて、組織のGitHub管理者は次の順序で確認すると効率的です。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | GitHubからの通知を確認 | 自社が個別影響対象か判断する |
| 高 | Organizationの監査ログを確認 | 不審な認証、権限変更、アプリ追加を検出する |
| 高 | PAT、GitHub Apps、OAuthアプリを棚卸し | 過剰権限や不要なアクセス経路を減らす |
| 中 | Secret scanningの状態を確認 | リポジトリ内の漏えい済み資格情報を検出する |
| 中 | 開発者端末とVS Code拡張機能を確認 | 端末起点の資格情報窃取を防ぐ |
| 中 | GitHub Supportへ過去に共有した情報を確認 | サポート対応抜粋に含まれる機微情報を把握する |
| 低 | 社内向け注意喚起を出す | 誤情報・過剰反応・放置を防ぐ |
GitHubからの通知を確認する
まず、Organization owner、Enterprise owner、セキュリティ担当者、請求・管理用メールアドレスにGitHubから通知が来ていないか確認します。GitHubは、影響が判明した場合に既定のインシデント対応・通知チャネルで顧客へ連絡すると説明しています。(The GitHub Blog)
確認すべき場所は、メールだけではありません。社内のチケットシステム、セキュリティ窓口の共有メールボックス、GitHub Supportとの過去のやり取り、Enterprise管理者向けの連絡先も確認対象です。
通知が来ていない場合でも、「何もしなくてよい」とは考えない方が安全です。通知確認と並行して、監査ログと資格情報の棚卸しを進めましょう。
監査ログで不審な操作を確認する
GitHubのOrganization監査ログでは、組織内メンバーによる操作を確認できます。監査ログには、誰が、何を、いつ実行したか、対象リポジトリや国などの情報が含まれ、Organization ownerがアクセスできます。GitHub Docsによると、Organizationの監査ログは直近180日間のイベントを対象とし、既定では過去3か月分が表示されます。(GitHub Docs)
今回の確認では、少なくとも2026年5月18日以降を対象に、次の観点で確認します。
| 見るべき観点 | 確認例 |
|---|---|
| 認証イベント | 普段と異なる地域、時間帯、アカウントからの操作 |
| アクセスイベント | 不自然なリポジトリアクセス、短時間の大量操作 |
| 権限変更 | Owner追加、Team権限変更、外部コラボレーター追加 |
| リポジトリ設定 | visibility変更、fork設定変更、branch protection変更 |
| アプリ連携 | GitHub Apps、OAuthアプリ、Webhookの追加や変更 |
| Actions関連 | secrets、variables、workflow設定の変更 |
検索時は、まず日付で絞り込み、次にactor、repo、operationで対象を狭めます。GitHub Docsでは、operation:accessやoperation:authentication、actor:ユーザー名、repo:組織名/リポジトリ名のような検索修飾子が紹介されています。(GitHub Docs)
調査時に避けたいのは、1つのログだけを見て結論を出すことです。たとえば「不審な国からのアクセス」に見えても、VPN、出張、CI/CD実行環境、外部委託先の作業である可能性があります。逆に、普段と同じ地域でも、侵害された端末やトークンを使われていれば不正操作は起こり得ます。アカウント、時刻、対象リポジトリ、操作内容をセットで確認してください。
侵害された可能性のあるトークンを追跡する
GitHub Docsでは、監査ログ上でトークンに関連するイベントを確認する方法が説明されています。監査ログには、個人アクセストークン、OAuth token、GitHub Apps、Deploy key、SSH keyなどの認証方法に関する情報が含まれる場合があり、hashed_token、programmatic_access_type、token_scopesといったデータを使って調査できます。(GitHub Docs)
実務では、次のように進めます。
| 状況 | 対応 |
|---|---|
| 侵害が疑われるトークンの値が分かる | SHA-256ハッシュ化して監査ログで関連イベントを検索 |
| トークンの値が分からない | 該当ユーザー、期間、対象リポジトリ、操作種別から絞り込む |
| Gitイベントを確認したい | 監査ログのエクスポート結果も確認 |
| 影響範囲が特定できない | トークンを無効化し、最小権限で再発行 |
注意点として、トークンの生値をチャット、チケット、ドキュメントに貼り付けないでください。調査のためにハッシュ化する場合も、信頼できる端末と一時的な作業環境で行い、作業ログに残さない運用が必要です。
個人アクセストークンとGitHub Appsを見直す
GitHubを組織利用している場合、実際のリスクは「GitHub本体のインシデント」だけでなく、自社内の過剰な権限設定にもあります。今回の件をきっかけに、個人アクセストークン、GitHub Apps、OAuthアプリを見直しましょう。
Personal Access Tokenはclassicとfine-grainedを分けて確認する
GitHubのOrganization ownerは、Organizationにアクセスできるfine-grained personal access tokenを確認し、特定のトークンのアクセスを取り消せます。ただし、このUIで確認・取り消しできるのはfine-grained personal access tokenであり、personal access token classicは同じ方法では確認できません。(GitHub Docs)
また、GitHub Docsでは、Organization ownerがpersonal access tokenのアクセス制御ポリシーや有効期限ポリシーを設定できると説明されています。fine-grained personal access tokenの最大有効期限は既定で366日ですが、personal access token classicには有効期限要件がありません。(GitHub Docs)
見直しの判断基準は次のとおりです。
| トークンの状態 | 推奨対応 |
|---|---|
| personal access token classicで広いscopeを持つ | fine-grained PATまたはGitHub Appへ移行を検討 |
| 有効期限がない、または長すぎる | 最大有効期限ポリシーを設定 |
| 所有者が退職者・異動者 | ただちに無効化またはアクセス取り消し |
| 用途が不明 | 利用者に確認し、不要なら削除 |
| CI/CDで個人トークンを利用 | GitHub App、OIDC、環境別シークレットなどへ置き換え |
特に危険なのは、「退職者の個人トークンがCI/CDでまだ使われている」「classic PATにrepo全体の権限が付いている」「誰が作ったか分からないトークンが残っている」という状態です。インシデント発生時に影響範囲を切り分けにくくなります。
GitHub Appsは権限と対象リポジトリを確認する
GitHub Appsについては、Organization ownerがインストール済みアプリの権限やリポジトリアクセスを確認し、必要に応じてアクセス対象の変更、停止、削除ができます。(GitHub Docs)
棚卸しでは、次の点を確認します。
| 確認項目 | 判断基準 |
|---|---|
| アプリの用途 | 現在も業務で使っているか |
| 権限 | Readで足りるのにWriteやAdminが付いていないか |
| 対象リポジトリ | 全リポジトリではなく必要なリポジトリだけか |
| 管理者 | 所有者が不明なアプリになっていないか |
| 最終利用状況 | 長期間使われていない連携が残っていないか |
GitHub Appsの権限は、便利さを優先すると広くなりがちです。インストール時の一時的な検証環境で許可したアプリが、本番リポジトリにアクセスできる状態で残っていないか確認してください。
OAuthアプリは承認フローを制御する
OAuthアプリについては、OrganizationでOAuth app access restrictionsを有効にすると、メンバーや外部コラボレーターが未承認のOAuthアプリにOrganizationリソースへのアクセスを許可できなくなります。GitHub Docsは、制限を設定していない場合、組織メンバーが承認したOAuthアプリがOrganizationのプライベートリソースへアクセスできる可能性があると警告しています。(GitHub Docs)
さらに、Organization ownerは、未承認アプリのアクセス要求を誰が出せるか、リポジトリ管理者がGitHub Appsをインストールできるかを制御できます。(GitHub Docs)
組織規模が大きい場合は、次の運用が現実的です。
| 組織の状況 | 推奨設定 |
|---|---|
| メンバーが多い | 未承認アプリのリクエストを制限 |
| 外部委託先が多い | 外部コラボレーターのアプリ要求を厳格化 |
| 機微なリポジトリが多い | GitHub AppsのインストールをOrganization ownerに限定 |
| 検証用アプリが多い | 四半期ごとに不要アプリを削除 |
| SaaS連携が多い | 利用部門、責任者、権限、対象リポジトリを台帳化 |
Secret scanningでリポジトリ内の資格情報を確認する
今回のようなセキュリティ情報が出たとき、管理者が見落としやすいのが「自社リポジトリにすでに埋め込まれている資格情報」です。GitHubのsecret scanningは、Git履歴全体のブランチを対象に、APIキー、パスワード、トークンなどのハードコードされた資格情報を検出します。Issue、Pull Request、Discussion、Wiki、secret gistなどもスキャン対象に含まれます。(GitHub Docs)
Secret scanningのアラートを確認するときは、単に「検出された文字列を削除する」だけでは不十分です。GitHub Docsも、アラートを受け取った場合は、悪用を防ぐために影響を受けた資格情報をただちにローテーションするよう説明しています。履歴からシークレットを削除する作業は時間がかかり、資格情報を無効化済みであれば必ずしも最優先ではありません。(GitHub Docs)
対応の優先順位は次のように決めると実務的です。
| 優先度 | 対象 | 対応 |
|---|---|---|
| 最優先 | 本番環境のクラウドキー、DB接続情報、デプロイトークン | 即時無効化、再発行、利用ログ確認 |
| 高 | GitHub PAT、npm token、コンテナレジストリ認証情報 | 無効化、権限縮小、再発行 |
| 中 | 検証環境のAPIキー | 有効性確認、不要なら削除 |
| 中 | 期限切れ・無効化済みのキー | アラートを整理し、再発防止策を実施 |
| 低 | ダミー値、テスト文字列 | 誤検知として記録。ただし命名が紛らわしい場合は修正 |
Organization-ownedのprivate/internal repositoryでsecret scanningを使うには、プランやGitHub Secret Protectionの有効化状況に依存します。GitHub Docsでは、public repositoryは無料で自動実行され、Organization-ownedのprivate/internal repositoryではGitHub TeamまたはGitHub Enterprise CloudでGitHub Secret Protectionが有効な場合に利用できると説明されています。(GitHub Docs)
社内向けに伝えるべきこと
セキュリティ情報が出た直後は、開発者や経営層から「GitHubは危険なのか」「すぐ移行すべきか」「全トークンを変えるべきか」といった質問が出やすくなります。管理者は、現時点の事実と社内で取る対応を分けて伝えると混乱を抑えられます。
社内向けの短い文面例は次のとおりです。
GitHubが2026年5月20日に、内部リポジトリへの不正アクセス調査を公表しました。現時点でGitHubは、顧客自身のOrganizationやRepositoryなど、内部リポジトリ外の顧客情報への影響を示す証拠はないとしています。一方で、内部リポジトリにサポート対応の抜粋など顧客関連情報が含まれる可能性があるため、当社ではGitHubからの通知有無、監査ログ、GitHub Apps、個人アクセストークン、開発端末上のVS Code拡張機能を確認します。開発者は、不審なGitHub通知、予期しない認証要求、VS Code拡張機能の異常、認証情報の露出に気付いた場合、セキュリティ窓口へ連絡してください。
この文面で重要なのは、断定しすぎないことです。「流出した」「影響なし」と言い切らず、公式発表に基づく現状と、自社で実施する確認作業を明確にします。
やってはいけない対応
今回のGitHub内部リポジトリ不正アクセス調査に対して、過剰反応も放置も避けるべきです。特に次の対応は、現場の混乱や二次的な障害につながる可能性があります。
| やってはいけない対応 | 問題点 |
|---|---|
| 公式情報を確認せず「顧客リポジトリ流出」と社内告知する | 誤情報により不要な混乱を招く |
| 全トークンを無計画に一斉ローテーションする | CI/CD停止、デプロイ失敗、復旧遅延につながる |
| 通知が来ていないことを理由に何も確認しない | 自社側の過剰権限や端末リスクを見逃す |
| Secret scanningのアラートを閉じるだけで済ませる | 資格情報が有効なまま残る可能性がある |
| 開発者に「各自で注意して」とだけ伝える | 確認基準が曖昧で対応漏れが起きる |
| GitHub AppsやOAuthアプリの権限を棚卸ししない | 不要な外部連携が侵害時の経路になる |
資格情報のローテーションは、優先順位を付けて行うべきです。まず、GitHubから個別通知があった範囲、過去にサポートへ共有した可能性がある情報、secret scanningで検出された有効なシークレット、広い権限を持つclassic PAT、退職者・不明所有者のトークンから対応します。
よくある疑問
自社のプライベートリポジトリは流出したのか
2026年5月20日時点のGitHub公式発表では、顧客自身のEnterprise、Organization、Repositoryなど、GitHub内部リポジトリ外に保存された顧客情報への影響を示す証拠はないとされています。(The GitHub Blog)
ただし、調査は継続中です。GitHubからの個別通知、監査ログ、アプリ連携、トークン利用状況を確認し、公式続報を追ってください。
GitHubから通知が来ていなければ対応不要か
不要ではありません。個別影響の有無とは別に、今回の件はGitHub管理の棚卸しを行う良いタイミングです。特に、PAT classic、広すぎるGitHub Apps権限、未承認OAuthアプリ、開発端末上のシークレットは、今回の件に関係なくリスクになります。
すべてのGitHubトークンを変更すべきか
証拠や影響範囲がない状態で、すべてのトークンを一斉に変更するのは現実的ではありません。まずは、高権限、長寿命、所有者不明、本番環境連携、サポートへ共有した可能性がある資格情報を優先してください。
開発者は何をすればよいか
VS Code拡張機能のバージョン確認、不審なプロセスやファイルの確認、GitHubトークンやSSH鍵の棚卸し、予期しないGitHub通知の報告を行います。Nx Consoleを利用している場合は、公式アドバイザリに従い、影響バージョンの有無と修正版への更新を確認してください。(GitHub)
今日中に実施すべきチェックリスト
最後に、GitHub管理者が今日中に実施すべき作業を整理します。
| チェック | 実施内容 |
|---|---|
| GitHub通知確認 | Organization owner、Enterprise owner、セキュリティ窓口のメールとサポート履歴を確認 |
| 公式情報確認 | GitHub Blogと関連アドバイザリの更新を確認 |
| 監査ログ確認 | 2026年5月18日以降の認証、アクセス、権限変更、アプリ追加を確認 |
| PAT棚卸し | fine-grained PAT、classic PAT、長寿命トークン、所有者不明トークンを確認 |
| GitHub Apps確認 | 権限、対象リポジトリ、不要アプリ、管理者不明アプリを確認 |
| OAuthアプリ確認 | OAuth app access restrictionsと承認済みアプリを確認 |
| Secret scanning確認 | 有効なシークレットのアラートを優先的に対応 |
| 開発端末確認 | VS Code拡張機能、Nx Console利用有無、不審なプロセスや資格情報を確認 |
| 社内周知 | 現時点の事実、確認作業、開発者の連絡先を簡潔に共有 |
今回のGitHub内部リポジトリ不正アクセス調査では、「現時点で顧客リポジトリへの影響を示す証拠はない」という公式説明を正しく理解しつつ、調査継続中であることを前提に動くことが重要です。まずはGitHubからの通知確認、Organization監査ログの確認、PATとGitHub Appsの棚卸し、secret scanningのアラート対応、開発端末のVS Code拡張機能確認を順番に進めてください。
過剰反応ではなく、管理者として確認すべき入口を一つずつ閉じることが、今回のようなサプライチェーン型のリスクに対する最も実務的な対応です。
コメント