Metaが、自社のGitHub(ソースコードを管理する仕組み)のリポジトリが侵害され、製品のソースコードと約1,500人の個人情報が盗まれたことを認めました。SecurityWeekが報じ、Metaが確認した内容です。注目したいのは、入口がMetaの製品の脆弱性ではなく、「盗まれた従業員の認証情報」だった点です。
何が起きたのか
報道とMetaの説明によると、攻撃者は、ある従業員の認証情報を悪用して、Metaの一部のGitHubのリポジトリにアクセスしました。盗まれたのは、製品のソースコードと、約1,500人(多くは米国の従業員)の個人情報です。事件は数週間前に起き、Metaは2026年10月13日から、対象となった人への通知を始めました。
流出した内容の内訳は、約99%が製品のソースコードで、残りの約1%が個人情報です。Metaは、この個人情報は、ポリシーに反してリポジトリに誤って保存されたもので、その多くは試験用の合成(本物に見せた架空の)データだと説明しています。また、Metaは、自社製品の脆弱性ではなく、内部システムへの侵害もないとし、攻撃者がMetaを狙い撃ちしたとは考えていないとしています。認証情報がどのように漏れたか(フィッシングなのか別の経路か)、個人情報の種類、侵害されたリポジトリの数、攻撃者が誰かは、明らかにされていません。
Meta GitHub侵害の経緯と情シスの教訓(編集部作成)作成: 編集部 / もとの資料: SecurityWeekの報道とMetaが認めた内容を編集部が整理
事後の対応として、Metaは、侵害されたリポジトリで見つかったすべての秘密情報(鍵やトークン)を入れ替えたとしています。
影響を受けるのはどんな環境か
直接の当事者はMetaですが、この事故の構図は、GitHubなどでソースコードを管理している、あらゆる組織に共通します。関係するのは、自社やベンダーが、開発のためにGitHubやGitLabなどのリポジトリを使っている組織です。入口が「製品の脆弱性」ではなく「盗まれた認証情報」と「リポジトリの中身」だった点が、どこでも起こりうる形といえます。
とくに、リポジトリに秘密情報(APIキー・パスワード)や個人情報を、うっかり置いてしまうことは、珍しくありません。今回のように、ポリシーで禁じていても、誤って入ってしまうことがあります。認証情報が盗まれてリポジトリに入られたとき、その中身が被害を広げます。
情シスが今日やること
- 開発の入口を守る: GitHubなど開発に使うサービスのアカウントに、多要素認証(MFA)をかけます。認証情報の使い回しをなくし、不審なログインを検知できるようにします。退職者や使われていないアカウントも整理します。
- リポジトリに何を置いているか確認する: 秘密情報や個人情報が、リポジトリに混ざっていないかを確認します。秘密スキャンの仕組みを使い、鍵やパスワードの混入を見つけて取り除きます。
- 秘密情報の持ち方を見直す: APIキーやトークンは、コードに直接書かず、秘密情報の保管の仕組み(シークレット管理)に置きます。短命で範囲を絞ったものにし、定期的に入れ替えます。
- 漏れたときの手順を決めておく: リポジトリが漏れた疑いがあるときに、該当する鍵・トークンをすぐに失効・再発行し、影響を確認する手順を用意します。Metaも、見つかった秘密を総入れ替えしています。
- 試験データの扱いに注意する: 本物に見える個人情報は、合成データであっても、リポジトリに置く扱いには注意します。開発・試験のデータが、どこに置かれているかを把握します。
ソースコードは、会社の大切な資産です。その管理の入口(アカウント)と中身(リポジトリに置くもの)を守ることが、今回のような事故を防ぐ鍵になります。製品の脆弱性を探すだけでなく、「盗まれた認証情報で入られたら、リポジトリに何があるか」という視点で、自社の守りを点検しておきたいところです。
