Megalodon攻撃に学ぶ|GitHub経由サプライチェーン攻撃からフィリピン開発拠点を守る
5,500以上のGitHubリポジトリが被害を受けたMegalodon攻撃を題材に、フィリピン進出企業のオフショア開発拠点で取るべきサプライチェーン対策とNPC通知の実務を解説します。

Megalodon攻撃に学ぶ:GitHub経由のサプライチェーン攻撃からフィリピン開発拠点を守る実践ガイド
2026年5月に発生したMegalodon攻撃の事例をもとに、フィリピンの開発拠点を抱える日本企業がGitHubとクラウド認証情報を守るための実践手順を解説します。
Part 1: このテーマが重要な理由
Step 1: フィリピンビジネスでの背景 (3分)
フィリピンは日本企業のオフショア開発拠点として急速に存在感を高めています。マニラ首都圏やセブには日系IT企業の現地法人や、日本本社向けに開発を請け負うBPO(業務委託会社)が多数あり、その多くがGitHubを使ってソースコードを管理しています。今回報告された「Megalodon」と呼ばれるサプライチェーン攻撃は、GitHubのリポジトリに自動コミットを大量に流し込み、開発の自動化に使われるGitHub Actionsの仕組みを乗っ取って、AWSやGCPなどのクラウド認証情報を盗み出すものでした。被害は5,500件以上のリポジトリに及んでいます。
フィリピンの開発現場では、日本本社のクラウド資格情報や本番APIキーを現地エンジニアが扱う場面が少なくありません。そのため、現地の開発者1人のGitHubアカウントが乗っ取られるだけで、東京本社のクラウド環境にまで被害が広がる可能性があります。さらにフィリピンでは、個人データ保護法(DPA: Data Privacy Act)に基づき、NPC(National Privacy Commission、フィリピンの個人情報保護委員会)への事故報告義務があるため、情報漏洩は技術問題だけでなく法的リスクにもなります。
マニラのBGC(Bonifacio Global City)のオフィスで、日本人マネージャーが現地のIT責任者にこう切り出します。「先週GitHubで大規模な攻撃があったらしい。うちのリポジトリで似たような自動コミットが入っていないか、一緒に確認したいんだが、いま時間あるかな?」現地メンバーは少し驚いた表情を見せながらも、すぐにラップトップを開いて確認を始めました。
Step 2: 元記事の要点を整理する (5分)
以下は、元記事に書かれた事実をもとに作成した要約表です。
| 項目 | 内容 |
|---|---|
| 攻撃名 | Megalodon(メガロドン) |
| 発見・報告した企業 | SafeDep(セーフデップ、セキュリティ調査会社) |
| 攻撃発生日 | 2026年5月18日(UTC11:36〜17:48の約6時間) |
| 影響を受けたリポジトリ数 | 5,561件(個別リポジトリ) |
| 投入された悪意あるコミット数 | 合計5,718件(2,878件+2,841件、2つのメールアドレスから送信) |
| 攻撃の手口 | GitHub Actionsのワークフローに、認証情報を盗むコードを仕込む |
| 盗まれた情報の種類 | CI環境変数、AWS認証情報、GCPアクセストークン、Azure認証情報、SSH秘密鍵、Docker・Kubernetes設定、APIキー、データベース接続文字列、GitHub Actionsトークンなど |
| 仕込まれた仕掛けの特徴 | workflow_dispatchを使い、後からGitHub API経由で発動できる「休眠型のバックドア」を設置 |
| 関連する被害事例 | NPMで公開されていたTiledesk(オープンソースのチャット・チャットボット基盤)の改ざん版が5月19〜21日に配布された |
| Tiledeskの感染経路 | GitHubリポジトリが侵害され、メンテナーは気付かないまま汚染済みコードからNPMに公開 |
この表は学習目的で公開情報の事実をもとに作成したものです。詳細は上記リンクの元記事をご確認ください。
関連: フィリピンでAIを導入したい日本人経営者が知るべき実践ガイド で詳しく解説しています。
Step 3: 理解度チェック (5分)
Q1. Megalodon攻撃で乗っ取りに使われた、GitHubの自動化機能の名前は何ですか?
ヒント: コードの変更時に自動でテストやデプロイを走らせる仕組みで、.github/workflows/配下に置かれます。
Q2. 攻撃者がコミットを集中投入した時間帯と日付を答えてください。
ヒント: 1日のうち約6時間に集中していました。
Q3. Tiledeskというパッケージはなぜ汚染されたのですか。NPMアカウントが乗っ取られたわけではない点に注意して説明してください。
ヒント: 攻撃者が触ったのはGitHub側です。NPMに公開した人物は気付いていませんでした。
Q4. workflow_dispatchという仕組みが攻撃者にとって都合の良い理由を1つ挙げてください。
ヒント: GitHubが普段かけている「再帰防止のルール」が、このトリガーには適用されません。
Q5. この攻撃で盗まれる可能性のある「認証情報」を3種類挙げてください。
ヒント: クラウド3社の名前と、SSHやAPIに関するものを思い出してください。
関連: フィリピン市場に最適化したAI導入ロードマップ|現地の実情を踏まえた実践ガイド で詳しく解説しています。
Part 2: 実務への応用
Step 4: フィリピンでの導入ステップ (10分)
フィリピンの開発拠点で同様の攻撃に備えるための手順を、5つのステップに整理しました。
| ステップ | やること | フィリピン特有の注意点 |
|---|---|---|
| 1. 棚卸し | 自社が管理するGitHubリポジトリと、各リポジトリで動いているGitHub Actionsのワークフローを一覧にする | マニラとセブで別々に契約しているBPOがある場合、Organization単位で別れていることが多いので、両拠点のIT責任者に同時に依頼します |
| 2. 不審コミット検知 | 過去6か月分のコミットを「bot系の作者名」「短時間に大量に発生したコミット」で絞り込んで確認する | 現地エンジニアの稼働時間(フィリピン標準時、UTC+8)と差が大きい時間帯のコミットは特に要注意です |
| 3. 認証情報の最小化 | 本番のAWS・GCP・Azureの長期キーをGitHub Secretsから取り除き、OIDC連携や短期トークンに切り替える | 現地メンバー全員に2要素認証(MFA、ワンタイムコードによる本人確認)を必須化します。SMSではなくアプリ方式が推奨です |
| 4. 通知と研修 | NPC通知の手順と、社内の対応手順書を整え、現地スタッフに説明会を開く | フィリピンではセキュリティ事故から72時間以内にNPCへ通知する義務があります。研修費用は1人あたり1,000〜3,000ペソ程度の外部講師費を見込んでおくと現実的です |
| 5. 監視の継続 | GitHub Audit Logと、クラウド側の異常検知を毎日確認できる体制を作る | 監視ツールのライセンス費用は月額で数万ペソかかる場合があります。BPO契約の中に「ログ監視」が含まれているか、最初の契約時に確認しておきましょう |
Step 5: よくある失敗と対策 (5分)
失敗パターン1: 「日本本社だけで対応を決めて現地に通知だけする」
NG例: 東京の情報システム部だけが対応方針を決め、マニラの現地法人には「明日からこのルールで運用してください」と通達だけを送ります。現地のエンジニアは背景を理解できず、形式的な対応に終わってしまいます。
OK例: マニラのIT責任者と一緒に、現地の業務フローに合わせた手順書を作ります。チームでの説明会では、今回の事件で実際に何が盗まれたのかを具体例として見せながら、最後に質問を受ける時間を必ず取りましょう。
失敗パターン2: 「セキュリティ事故を本社にだけ報告し、NPC通知を遅らせる」
NG例: 情報漏洩が疑われたとき、まず東京本社に報告し、本社の判断を待ってからNPCへの通知を検討しようとします。その間に72時間の期限を過ぎてしまいます。
OK例: 現地法人のデータ保護責任者(DPO: Data Protection Officer、個人情報の取扱責任者)が、本社報告とNPC通知を同時並行で進める手順を、あらかじめ取り決めておきます。報告書のひな型も英語で用意しておきましょう。
失敗パターン3: 「現地BPOに任せきりで、認証情報の管理状況を把握していない」
NG例: 「現地のBPOが管理しているから大丈夫」と考え、どのスタッフが本番環境のAPIキーを持っているか、日本側で把握していません。担当者の退職時に鍵が放置されます。
OK例: BPOとの契約書に、退職者発生時のアカウント停止期限(例えば24時間以内)と、四半期ごとに認証情報の棚卸し報告を提出する義務を明記します。報告のひな型も日本側で用意して渡しておきましょう。
Part 3: さらに深く学ぶ
Step 6: 関連する技術用語 (5分)
サプライチェーン攻撃(供給網への攻撃)とは、ソフトウェアが作られて配布されるまでの流れのどこか1か所を狙って、最終的に使う人のところに悪意あるコードを届ける攻撃のことです。フィリピンの日系企業が日本本社向けに納品しているシステムが乗っ取られると、納品先である日本の顧客にまで被害が広がるため、現地法人にとっても他人事ではないリスクとして扱う必要があります。
GitHub Actions(GitHubの自動化機能)とは、GitHubに置いてあるコードに変更があったときに、テストやデプロイなどの作業を自動で実行してくれる仕組みです。マニラの開発チームが日本側のレビューを待たずに本番環境へ自動デプロイする運用をしている場合、この仕組みが悪用されると現地での変更がそのまま本番事故につながる危険があるため、承認フローをはさむ設定が大切です。
CI/CDシークレット(自動化処理で使う秘密情報)とは、自動デプロイの過程でクラウドや外部サービスにログインするために使う、パスワードのような文字列のことです。セブのBPOで開発を進めている場合、シークレットがリポジトリにそのまま書かれていないか、GitHub Secrets機能で安全に管理されているかを、日本側からも定期的に確認すると安心です。
二要素認証(MFA、本人確認を2段階で行う仕組み)とは、パスワードに加えてスマートフォンの認証アプリなどで本人確認を行う仕組みです。フィリピンでは現地エンジニアがカフェやコワーキングスペースから作業することも珍しくないため、パスワードだけの認証では不十分で、MFAを全員に強制適用することが現地法人のセキュリティの基本になります。
データ侵害通知義務(情報漏洩を当局に届け出る決まり)とは、個人情報が漏れた疑いがあるときに、決められた期限内に監督官庁へ届け出る法律上の義務のことです。フィリピンでは個人データ保護法(DPA)により、NPCへ72時間以内に通知する必要があり、マニラの現地法人で事故が起きた場合は日本本社への報告と並行して進める運用を整えておく必要があります。
Step 7: 自社への応用を考える (10分)
現地拠点のGitHub棚卸しを今すぐ始める
考えるヒント: 自社のフィリピン拠点では、誰がどのリポジトリの管理権限を持っているか即答できますか。退職者のアカウントが残っていないか、最後に確認したのはいつでしょうか。
次のアクション: 今週中に、現地のIT責任者と30分の打ち合わせを設定し、GitHub Organizationのメンバー一覧と、Owner権限を持つ人物のリストを出してもらいましょう。
本社と現地でのセキュリティ事故対応の役割を決める
考えるヒント: もし今夜マニラ拠点で情報漏洩が疑われたとき、誰が最初に動き、誰がNPCに連絡し、誰が日本本社に報告するか、書面で決まっていますか。
次のアクション: A4用紙1枚の「初動対応フローチャート」を作り、現地法人のDPO(データ保護責任者)と日本側の情報システム責任者の双方が署名して保管しましょう。
BPO契約書のセキュリティ条項を見直す
考えるヒント: 現在のBPO委託契約書には、退職者のアカウント停止期限、認証情報の管理方法、事故発生時の通知義務が明記されていますか。口頭での合意だけになっていませんか。
次のアクション: 法務担当と一緒に、次回の契約更新時に追加する条項案を3行でまとめ、現地BPOに事前共有して反応を確認しましょう。
Part 4: FAQ
Q1. フィリピンの現地法人ですが、日本本社のGitHubを使わせてもらっています。Megalodonの影響を受けるのは本社だけで、現地法人は関係ないのでしょうか。
関係します。本社のGitHubに現地メンバーがアクセスしている場合、現地メンバーの端末や認証情報が侵害されると、本社のリポジトリ全体に影響が出ます。さらに、現地メンバーの個人情報が含まれるシステムへの不正アクセスが起きた場合、NPC(フィリピン個人情報保護委員会)への通知義務はフィリピンの現地法人側に発生します。本社と現地のどちらか一方だけでは対応できない問題です。
Q2. フィリピン人エンジニアにセキュリティ研修を受けさせたいのですが、英語の教材と日本語の教材、どちらが良いですか。
現地メンバー向けの研修は基本的に英語で行うことをおすすめします。フィリピンでは業務上の標準言語が英語で、NPCのガイダンスも英語版が正式版です。日本人駐在員には日本語版を別途用意し、両方の内容が一致していることを社内で確認しておくと、後日のすり合わせが楽になります。
Q3. GitHub Actionsの設定変更は、現地のエンジニアに任せて良いものでしょうか。
権限の最小化が原則です。本番デプロイに関わるワークフローの変更は、日本側のレビューを必須にする運用を推奨します。GitHubには「Required reviewers」という、特定の変更に承認者を必須にする機能があり、これを使えば現地での作業速度を落とさずに、本社のチェックを通せます。
Q4. 認証情報の管理にコストをかけたくありません。最低限やるべきことは何ですか。
費用をかけずに今日からできることが3つあります。1つ目は、全員のGitHubアカウントで二要素認証を有効化することです。2つ目は、過去6か月のコミット履歴を一覧表示し、見覚えのない作者名がいないか確認することです。3つ目は、本番用のクラウド長期キーをGitHubから取り除き、短期トークンに切り替えることです。これらはどれも追加ライセンスなしで実施できます。
Q5. フィリピンの法律でセキュリティ事故が起きた場合、日本本社まで罰則が及ぶことはありますか。
罰則の直接的な対象は、フィリピン国内で個人情報を取り扱う法人、つまり現地法人です。ただし、現地法人の責任者が日本人駐在員である場合、その個人にも責任が及ぶ可能性があります。さらに、日本本社が現地法人の個人情報処理を実質的に支配していると判断されると、本社まで調査対象となる場合があります。法務対応は早めに現地の弁護士に相談しておきましょう。
活用のコツ(3 Tips)
今夜のうちに自社GitHubの「自動コミット」を確認しましょう
Megalodon攻撃の特徴は、約6時間で5,718件という異常な速度で自動コミットが投入されたことでした。自社のGitHub Organizationの「Insights」画面で、過去30日の作者別コミット数を見れば、人間離れした件数のアカウントがあるかどうかを5分で判断できます。現地任せにせず、日本本社側でも自分の目で確認する習慣を作りましょう。
現地法人のDPO(データ保護責任者)と日本側の情報システム責任者を、いますぐ電話でつないでおきましょう
セキュリティ事故が起きてから初めて連絡を取る関係では、72時間以内のNPC通知に間に合いません。今のうちに、両者がSlackやチャットで直接やり取りできる状態を作り、月1回の定例打ち合わせを設定しておくことが、いざというときの最大の防御になります。
「無料の最小対策3点セット」を今週中に展開しましょう
二要素認証の全員必須化、本番用クラウド長期キーの削除、過去6か月のコミット棚卸し、この3つは追加ライセンスなしで実施できます。完璧な体制を作ろうとすると数か月かかってしまいますが、この3点だけならフィリピン拠点でも1週間で完了できます。まずは現地のIT責任者に「この3つを今週中にお願いします」と具体的に伝えるところから始めましょう。
ボーナス: PH AI Worksの活用法
PH AI Worksは、フィリピンに進出している日本企業や在フィリピンの日本人ビジネスパーソンに向けて、AIとテクノロジーの活用を支援している会社です。今回のテーマであるサプライチェーン攻撃対策では、特に以下のような領域でお力になれます。
ご相談いただける内容の例:
- フィリピン現地法人のGitHubおよびクラウド環境のセキュリティ点検と、日本本社との役割分担の整理
- 現地エンジニア向けセキュリティ研修の英語教材作成と、日本人駐在員向け日本語版の整備
- NPC(個人情報保護委員会)への通知手順の整備と、現地法人と日本本社をつなぐ初動対応フローの設計
ご関心のあるテーマがあれば、無料でご相談いただけます。まずはお気軽にお問い合わせください。

