GitHubから情報流出したときの対応|認証情報・リポジトリ流出の原因と調査ポイントを解説|サイバーセキュリティ.com

GitHubから情報流出したときの対応|認証情報・リポジトリ流出の原因と調査ポイントを解説

本コンテンツには広告を含み、本コンテンツを経由して商品・サービスの申込みがあった場合、提携している各掲載企業から送客手数料を受け取ることがあります。

GitHubは、ソースコードや設定ファイルを管理するため、多くの企業で利用されています。一方で、リポジトリにはソースコードだけでなく、APIキー、クラウド認証情報、顧客データ、設定ファイルなどが含まれていることもあり、認証情報の漏えいや公開設定ミスが起きると、影響がGitHubだけにとどまらない場合があります。

GitHub流出では、GitHubの基盤そのものが侵害されるケースだけでなく、従業員の端末からPATやOAuthトークン、SSH秘密鍵などが盗まれたり、privateのつもりだったリポジトリがpublicになったりすることで、第三者にリポジトリを取得されるケースがあります。リポジトリに認証情報が含まれていた場合は、本番環境やクラウドへ不正アクセスされる可能性もあります。

そのため、GitHub流出が疑われる場合は、パスワード変更だけで対応を終えず、関連するトークンやSSH鍵を無効化し、監査ログを保全したうえで、clone、push、権限変更、Actions実行などの操作を確認する必要があります。対応を急いでログや端末を変更すると、痕跡が消える恐れがあります。

そこで本記事では、GitHub流出で考えられる主な原因と最近公表された事例、最初に行うべき初動対応、監査ログで確認したいポイント、GitHub外への被害拡大を調べる方法、フォレンジック調査で確認できる内容までわかりやすく解説します。

GitHub流出とは

「GitHub流出」という言葉は、GitHub自体の基盤が侵害されたケースだけを指すものではありません。企業側の認証情報漏えいや公開設定ミスなどによって、リポジトリや内部データが第三者へ取得された事案も含めて使われることがあります。

特に注意したいのは、GitHub上のソースコードが流出しただけでは被害範囲を判断できない点です。リポジトリ内にクラウド認証情報やAPIキー、個人情報などが含まれていると、流出した情報を使った後続攻撃につながる可能性があります。

そのため、GitHub流出では「どのリポジトリが取得されたか」だけでなく、「その中に何が含まれていたか」「流出した認証情報が別の環境で使われていないか」まで確認することが重要です。

GitHub流出で公表された主な事例

近年の公表事例では、認証情報の漏えいや開発端末の侵害を起点として、GitHub上のリポジトリが外部へ取得されたケースが確認されています。

GitHub従業員端末から内部リポジトリが持ち出された事例

2026年5月には、悪性のVS Code拡張機能によってGitHub従業員の端末が侵害され、内部リポジトリ約3,800件が外部へ持ち出された可能性が公表されています。

一方で、公表内容ではGitHub利用者の組織や顧客リポジトリに影響した証拠は確認されていないとされています。

この事例からも、GitHub上の認証情報だけでなく、開発に利用する端末やIDE拡張機能が侵害の起点になる可能性があることが分かります。

漏えいしたGitHub認証情報からリポジトリがコピーされた事例

マネーフォワードでは、漏えいしたGitHub認証情報を利用され、リポジトリがコピーされた事案が公表されています。

公表された内容では、ソースコードやリポジトリ内の一部個人情報が流出した可能性がある一方、本番データベースへの不正アクセスは確認されていないとされています。

GitHubの認証情報が漏れた場合でも、被害範囲をGitHubだけに限定せず、本番環境やクラウドへの後続アクセスがなかったか確認することが重要です。

GitHub認証情報を端緒に個人情報流出の可能性が生じた事例

イノベーションでは、GitHub認証情報の漏えいを端緒とする不正アクセスにより、最大約6万件の氏名やメールアドレスなどが流出した可能性が報告されています。

このように、GitHub認証情報の侵害は、単なるソースコードの取得だけではなく、リポジトリに含まれる個人情報や認証情報を通じて影響が広がることがあります。

GitHubの認証情報が漏えいした場合は、リポジトリだけでなく、GitHubと連携しているクラウド、CI/CD、SaaSなども確認する必要があります。

GitHubから情報が流出する主な原因

GitHub流出は、一つの原因だけで起きるとは限りません。認証情報の窃取、公開設定ミス、開発端末の侵害など、複数の経路が考えられます。

PAT・OAuthトークン・SSH鍵などの漏えい

GitHubでは、Personal Access Token(PAT)、OAuthトークン、SSH鍵、GitHub Appなど、さまざまな認証情報が利用されます。

こうした認証情報が端末、ログ、CI設定、設定ファイルなどから漏れると、攻撃者が正規ユーザーのようにGitHubへアクセスできる可能性があります。

そのため、GitHubアカウントのパスワードを変更するだけでは、すでに発行されているトークンや鍵を悪用され続ける可能性があります。

開発端末やIDE拡張機能の侵害

開発者のパソコンがマルウェアに感染した場合、GitHubへのログインセッションや認証情報を盗まれることがあります。

悪性のIDE拡張機能や不審な開発ツールが利用されると、開発端末に保存されたトークンやブラウザセッションなどへアクセスされる可能性も考えられます。

GitHub流出が確認された場合は、GitHub側のログだけでなく、認証情報を利用していた開発端末についても調査することが重要です。

リポジトリの公開設定ミス

privateとして運用する予定だったリポジトリを誤ってpublicにした場合、第三者から閲覧やcloneが可能になることがあります。

また、リポジトリ本体だけでなく、fork、GitHub Pages、Actions artifacts、Packages、release assetsなどから意図せずデータが公開される可能性もあります。

そのため、流出の確認ではリポジトリの公開・非公開設定だけを見るのではなく、関連する公開経路も横断して確認する必要があります。

リポジトリ内へのシークレット混入

ソースコードをGitHubへ登録する際に、APIキー、クラウド認証情報、顧客データのCSV、.envファイル、バックアップなどを誤って含めてしまうことがあります。

一度外部へ取得された認証情報は、リポジトリを非公開に戻しただけでは安全になりません。

公開された可能性があるシークレットは、漏えいしたものとして扱い、失効やローテーションを行う必要があります。

clone後の後続攻撃への悪用

攻撃者がリポジトリを取得すると、ソースコードを解析して脆弱性や内部構成を調べることがあります。

リポジトリに本番環境の接続情報や認証情報が含まれていた場合は、不正アクセスにつながる可能性があります。また、コードの内容を利用したサプライチェーン攻撃や恐喝へ発展するケースも考えられます。

GitHub流出では、リポジトリがコピーされた時点で対応を終わらせず、その情報を使った後続攻撃が発生していないか確認することが重要です。

認証情報やリポジトリの流出が疑われる場合は、ログの保全より先に履歴や端末を消去すると、原因不明になる恐れがあります。封じ込めと調査を並行して進める必要があります。

GitHub流出が疑われる場合の初動対応

GitHubからリポジトリが流出した可能性がある場合は、パスワード変更だけで終わらせず、GitHubへのアクセスに利用できる資格情報を広く確認します。

GitHubの認証情報を無効化する

最初に、侵害された可能性があるGitHubアカウント、PAT、OAuth App、SSH鍵、GitHub App、Actionsで利用している資格情報などを確認します。

漏えいした可能性がある認証情報は、攻撃者がまだ利用している可能性があるため、速やかに無効化する必要があります。

GitHub認証情報を見直す手順
  1. 侵害が疑われるユーザーとアプリを特定します。
  2. PATやOAuthトークンを無効化します。
  3. SSH鍵やGitHub Appの資格情報を更新します。
  4. 既存セッションや不要な認可を確認します。

リポジトリ内の全シークレットをローテーションする

GitHubの資格情報だけでなく、流出した可能性があるリポジトリ内のシークレットも変更します。

クラウドのアクセスキー、APIキー、データベース認証情報、証明書などが含まれていた場合は、第三者が取得済みであることを前提に対応します。

シークレットをローテーションする流れ
  1. 影響リポジトリに含まれるシークレットを洗い出します。
  2. 本番・開発環境で利用している資格情報を分類します。
  3. 漏えいした可能性があるキーを失効します。
  4. 新しい資格情報へ切り替え、旧キーの利用がないか確認します。

GitHubの監査ログを保全する

GitHub EnterpriseやOrganizationの監査ログには、不審な操作を確認する手がかりが残っている場合があります。

clone、push、権限変更、PAT利用、OAuth認可、Actionsの実行などを確認し、攻撃者がどの範囲へアクセスした可能性があるのかを整理します。

監査ログで確認する流れ
  1. Organization・Enterpriseの監査ログを保存します。
  2. 不審なログインやトークン利用を確認します。
  3. clone・push・権限変更の履歴を確認します。
  4. Actionsやアプリの不審な実行履歴を確認します。

外部公開されている経路を確認する

リポジトリをprivateへ戻しただけでは、別の経路からデータが公開され続けている場合があります。

公開リポジトリ、fork、GitHub Pages、Actions artifacts、Packages、release assetsなども確認します。

外部公開経路を確認する手順
  1. publicになっているリポジトリを確認します。
  2. forkやPagesの公開状況を確認します。
  3. Actions artifactsやPackagesを確認します。
  4. release assetsなどの外部公開物を確認します。

本番環境への後続アクセスを確認する

流出したリポジトリにクラウドや本番環境の認証情報が含まれている場合は、GitHub外のログも確認します。

クラウド監査ログやVPN、IdPなどを調べ、流出した資格情報を利用した不正アクセスが発生していないかを確認します。

後続アクセスを確認する流れ
  1. 流出した可能性がある資格情報を一覧化します。
  2. クラウドやSaaSの監査ログを保存します。
  3. 不審なログイン・API利用を確認します。
  4. 本番環境への変更やデータ取得がないか確認します。

個人情報・秘密情報の影響範囲を整理する

リポジトリ内に顧客データや個人情報、内部資料などが含まれていた場合は、どの情報が第三者に取得された可能性があるのかを整理します。

対象データの種類や件数、対象期間を把握し、法務や個人情報保護、顧客対応の担当者と通知や公表の要否を検討します。

影響範囲を整理する手順
  1. 流出した可能性のあるリポジトリを特定します。
  2. 含まれていた個人情報・機密情報を洗い出します。
  3. 対象件数と影響する顧客・取引先を整理します。
  4. 法務や個人情報保護担当と対応方針を共有します。

GitHubの監査ログで確認したいポイント

GitHub流出の調査では、「誰がログインしたか」だけでなく、認証情報がどのように利用され、どのリポジトリへアクセスされたのかを時系列で確認することが重要です。

不審な認証・PAT利用

通常とは異なるユーザー、端末、場所、時間帯などから認証されていないかを確認します。

PATやOAuthトークンが利用されている場合は、そのトークンがいつ発行され、どの範囲の権限を持っていたのかも確認します。

リポジトリのclone・push

流出が疑われる場合は、リポジトリの取得や更新に関する記録を確認します。

特に短時間で複数リポジトリへアクセスしている場合や、通常利用しないアカウントから大量の操作が行われている場合は、詳しく調べる必要があります。

権限・公開設定の変更

攻撃者がアクセス権を拡大したり、privateリポジトリをpublicへ変更したりする可能性もあります。

Organizationメンバー、チーム権限、リポジトリのvisibilityなどに不審な変更がないか確認します。

OAuth・GitHub Appの認可

不審なOAuth AppやGitHub Appが認可されている場合、ユーザーが気づかないままリポジトリへアクセスされる可能性があります。

いつ、誰が、どのアプリを認可したのかを確認し、不要または不審なアプリは無効化します。

Actionsの不審な実行

GitHub Actionsには、クラウド認証情報やデプロイ用シークレットが登録されていることがあります。

不審なworkflow実行や設定変更がないかを確認し、Actions経由で認証情報が利用されていないかを調べることが重要です。

GitHub外への被害拡大も確認する

GitHub流出では、ソースコードやリポジトリだけを調べても被害の全体像を把握できない場合があります。流出した情報を使った本番環境へのアクセスやサプライチェーンへの影響まで確認する必要があります。

クラウド環境への不正アクセス

リポジトリ内にAWS、Azure、Google Cloudなどの資格情報が含まれていた場合は、クラウド側の監査ログを確認します。

流出時刻以降に不審なAPI操作やログインがないかを調べ、必要に応じて認証情報を失効します。

本番システムへの変更やデータ取得

本番環境のアクセス情報が含まれていた場合、攻撃者が設定変更やデータ取得を行っていないか確認する必要があります。

GitHub側の操作時刻と、本番環境の監査ログを時系列で突き合わせることで、関連性を確認しやすくなります。

CI/CDやサプライチェーンへの影響

取得されたソースコードを解析されると、システムの脆弱性や内部構成を把握される可能性があります。

また、Actionsやデプロイ環境が侵害されている場合は、不正なコードを混入されるなどサプライチェーンへの影響も考えられます。

顧客・取引先情報の流出

リポジトリに顧客情報や取引先データが含まれている場合は、情報漏えいとして影響範囲を整理する必要があります。

対象情報の種類や件数、第三者が取得した可能性を確認し、法務や関係部署と通知・公表の必要性を検討します。

GitHub内のアクセスを止めても、すでに漏れた認証情報が別の環境で悪用されている可能性があります。リポジトリ流出と後続アクセスを分けて調査しないと、被害を見逃す恐れがあります。

GitHub流出の原因と被害範囲をフォレンジック調査で確認する方法

GitHubの監査ログだけでは、認証情報がどこから漏れたのか、開発端末が侵害されていたのかまで判断できないことがあります。そのような場合に有効なのが、端末とクラウドの記録を横断的に確認するフォレンジック調査です。

GitHub認証情報が漏えいした原因を確認する

GitHub認証情報の漏えい原因を正確に確かめるには、GitHub側のログだけでなく、認証情報を保有していた開発端末や周辺システムも確認する必要があります。その手法として有効なのがフォレンジック調査です。

フォレンジック調査では、端末内の操作履歴、ブラウザ、認証情報の利用痕跡、不審なアプリやマルウェアなどを解析し、PATやSSH鍵などがどのような経路で漏れた可能性があるのかを整理します。

攻撃者がアクセスしたリポジトリを確認する

OrganizationやEnterpriseの監査ログ、GitHub上の操作記録などを確認し、攻撃者がどのアカウントを利用し、どのリポジトリへアクセスした可能性があるのかを整理します。

アクセスされたリポジトリを特定できれば、その中に含まれるソースコード、個人情報、シークレットなどから後続調査の優先順位を決めやすくなります。

開発端末の侵害やマルウェア感染を確認する

認証情報が開発端末から盗まれた可能性がある場合は、マルウェア、不審なIDE拡張、ブラウザセッションの悪用などを確認します。

端末が侵害されたままGitHubの認証情報だけを変更しても、再び新しい認証情報を盗まれる可能性があります。そのため、端末側の原因確認も重要です。

クラウド・本番環境への後続アクセスを確認する

リポジトリにクラウド認証情報や接続設定が含まれていた場合は、GitHubの調査だけで終わらせず、クラウドや本番環境の監査ログを確認します。

GitHub上の不審操作と外部環境のアクセス時刻を時系列で突き合わせることで、流出した情報が後続攻撃に利用された可能性を整理できます。

GitHub流出では、トークンの無効化やリポジトリの非公開化を急ぐ一方で、原因調査に必要なログや端末データを残す必要があります。流出経路や後続被害まで確認したい場合は、関連データを保全したうえで専門調査へ切り替えることが重要です。

おすすめのフォレンジック調査会社

DDF

公式サイトデジタルデータフォレンジック

編集部が厳選したおすすめのフォレンジック調査会社は、デジタルデータフォレンジックです。

デジタルデータフォレンジックは、累計4万7千件以上の豊富な相談実績を持ち、全国各地の警察・捜査機関からの相談実績も409件以上ある国内有数のフォレンジック調査サービスです。

24時間365日の相談窓口があり、緊急時でも安心です。相談から見積りまで無料で対応してくれるので、フォレンジック調査の依頼が初めてという方もまずは気軽に相談してみることをおすすめします。

まとめ

GitHub流出は、GitHub自体の侵害だけでなく、PAT、OAuthトークン、SSH鍵などの認証情報漏えいや、リポジトリの公開設定ミス、開発端末の侵害などによって発生することがあります。

流出が疑われる場合は、GitHubパスワードの変更だけで終わらせず、PAT、OAuth App、SSH鍵、GitHub App、Actionsなどの資格情報を無効化し、リポジトリ内に含まれていたシークレットも漏えい前提でローテーションする必要があります。

あわせて、EnterpriseやOrganizationの監査ログを保全し、認証、clone、push、権限変更、Actions実行などを確認します。リポジトリにクラウド認証情報や個人情報が含まれていた場合は、GitHub外の本番環境やクラウドまで被害が広がっていないか確認することが重要です。

認証情報の漏えい元や開発端末の侵害、後続アクセスまで自社だけで確認するのが難しい場合は、フォレンジック調査によって端末、GitHub、クラウドの記録を横断的に解析し、原因と被害範囲を整理する方法があります。

  • 中小企業の情報瀬キィリティ相談窓口[30分無料]
  • 情報処理安全確保支援士(登録セキスペ)募集
  • サイバー保険比較
  • 【企業専用】セキュリティ対策無料相談