「GitHubって開発者が使うツールなのに、なぜ一般ユーザーの個人情報が漏れるの?」
「自社のリポジトリに個人情報が含まれていないか、確認する方法が分からない」
GitHub経由の情報漏洩ってよく聞くでしゅけど、開発者が使うツールなのに、なんで利用者の情報が漏れるんでしゅか?
リポジトリの中に個人情報を含むファイルが入っていたんだよ。開発者が「うっかり」混入させてしまうケースが後を絶たない。今回のイノベーション社の件も、まさにそのパターンだな
法人向けIT製品の比較サービス「ITトレンド」を運営するイノベーション社が、GitHubへの不正アクセスにより最大6万件の個人情報漏洩の危機に直面した。
ソースコード管理ツールに潜む”見えないリスク”が、利用者の個人情報を直撃した可能性がある事案だ。
この記事では、GitHub経由の情報漏洩がなぜ起きるのか、そして自社に同じことが起きないよう何をすべきかを解説する。
- イノベーション社がGitHub認証情報の漏えいにより最大約6万件の個人情報が流出の恐れ
- 被害の発端はGitHub認証情報の漏えい——リポジトリ内ファイルに個人情報が混入していた
- 2026年はCAMPFIRE・マネーフォワードと続くGitHub認証情報漏洩の連鎖が起きている
ソースコードに潜む個人情報のリスクを正しく理解することで、自社のセキュリティ対策を見直すきっかけにしてほしい。
目次
GitHub不正アクセスで何が流出したのか
「ITトレンド」など法人向けITサービスを運営する株式会社イノベーション(東京都渋谷区)は2026年8月4日、GitHubへの不正アクセスが発生したと発表した。
同社が開発業務に使用していたGitHubアカウントの認証情報が外部に漏えいし、第三者がそのアカウントに不正ログインしたとみられる。
認証情報の漏えいが引き起こした大規模インシデント
不正アクセスにより閲覧された可能性がある個人情報の件数は最大約6万件。
氏名とメールアドレスが対象で、うち一部の対象者には電話番号も含まれる。
これらの情報は、ソースコードやリポジトリ内のファイルに記載された状態で保管されており、正規の業務システムではなく開発資産の中に個人情報が混入していたことが明らかになっている。
発覚後の対応について、同社は以下のように説明している。
- 不正アクセスの起点となった認証情報の無効化とアカウントの遮断(完了)
- ソースコード内の各種認証キー・パスワードの無効化と再発行(概ね完了)
- 対象となった顧客へのメールなどでの個別連絡(予定)
現時点では「社内での調査を継続しており、詳細な事実関係が確定していない」とのことで、漏洩件数は「精査中」だ。
最終的な被害範囲は今後の調査次第で変わる可能性がある。
認証情報が漏えいすると、リポジトリ内の情報が読まれる
GitHubのPersonal Access TokenやOAuth Tokenが攻撃者の手に渡ると、そのトークンに付与された権限・スコープの範囲でリポジトリへのアクセス権が与えられてしまう。
プライベートリポジトリも対象になり得る。
プライベートリポジトリなら外部から見えないんじゃないでしゅか?
認証情報さえ手に入れれば、正規の開発者と同じ権限でリポジトリを閲覧できてしまう。「非公開」の意味が、認証情報の漏えいで消えてしまうんだな
攻撃者は認証情報を使って、ソースコード内に埋め込まれたAPIキー、接続文字列、そして今回のような個人情報を含むファイルにアクセスできてしまう。
これが、GitHubの認証情報漏えいがただのアカウント乗っ取りにとどまらない理由だ。
なぜ繰り返されるのか——GitHub経由漏洩の構造的問題
2026年はGitHub認証情報の漏えいを起点とする情報漏洩が相次いでいる。
4月にはクラウドファンディングサービスのCAMPFIRE、5月にはMoneyForwardで同様の事案が発生した。
いずれも「公表当初の想定より被害範囲が拡大した」という共通点がある。
マネーフォワードの事案では、最終的に62,901名分のデータが対象となり、銀行口座連携機能が35日間停止されるなど、当初発表を大幅に超える影響が生じた。
今回のイノベーション社も「精査中」の段階で最大6万件と公表しており、最終的な件数が変動する可能性は否定できない。
なぜリポジトリに個人情報が混入するのか
開発現場では、本番環境の接続情報やAPIキーをソースコードに直接記述する「ハードコーディング」と呼ばれる慣行が今なお根強く残っている。
また、テスト環境の構築に実際の顧客データを流用するケースもある。
こうした慣行が、個人情報をリポジトリに引き込む原因になっている。
ポイントは以下のとおりだ。
- 認証情報や個人情報のハードコーディングは、リポジトリへのアクセス権を持つ人間全員が読める状態を意味する
- APIキーやパスワードを環境変数や秘密管理サービスに分離せず、ソースコードに書いたままにしている
- テストデータに実際の顧客情報を使用し、それがリポジトリに含まれたままになっている
GitHubのSecret Scanningなどの自動検出機能を活用し、誤って認証情報がコミットされた場合にすぐ検知できる体制を整えることも重要だ。
APIキーやパスワードは環境変数(Environment Variables)や秘密管理サービスに分離するのが鉄則となっている。
まず「ソースコードに認証情報を書かない」という鉄則を組織全体で徹底する。それだけで相当なリスクが下がる。Secret ScanningやGitGuardianのようなツールで検知することも手だな
まとめ——ソースコード管理は「開発だけの問題」ではない
イノベーション社のGitHub不正アクセス事案は、ソースコード管理の甘さが利用者の個人情報漏洩に直結することを改めて示した。
ITトレンドのような比較・情報サービスは多数の法人顧客の情報を扱うため、その管理体制の重要性は高い。
GitHubのセキュリティは開発チームだけでなく、経営層やセキュリティ担当者が組織として取り組むべきテーマだ。
認証情報をソースコードに含めない、アクセストークンの権限を最小限にしローテーションを行う、リポジトリを定期的にスキャンする。
この3点が、同様のインシデントを防ぐ基本的な対策となる。
今日から早速、うちのリポジトリもチェックしてみるでしゅ!
ふふふ、その意識が大事だな。見つけたら即座に無効化と再発行。それが鉄則だ