2026年5月 GitHubのセキュリティ侵害：拡張機能の管理は依然として課題となっています――では、どうすればよいのでしょうか？

GitHubは、世界最大級のコードホスティングプラットフォームの一つです。 開発者のIDE拡張機能を通じて攻撃が侵入したという事実こそが、このリスクカテゴリーが現在どのような状況にあるかを如実に物語っています。 攻撃者らは、およそ 3,800 件の内部リポジトリが流出させられたと主張しています。この数値について、GitHubは、 自身の調査結果と概ね一致していると述べています。

しかし、そこから得られるより大きな教訓は、ある1つの企業や、1つの不正な拡張機能という範囲にとどまらないものです。 GitHubのセキュリティ侵害は、組織がIDE拡張機能を「管理対象のソフトウェア」ではなく「単なる利便性向上のためのソフトウェア」として扱った場合に何が起こるかを示す実例であり、経営陣レベルでの教訓でもあります。

GitHubのセキュリティ侵害に関する詳細（現時点での情報）

、GitHubの公式声明 および 、ならびに業界報道 に基づき、その順序は以下の通りです：

• 従業員の端末が、悪意のある VS Code 拡張機能によって侵害されました
• GitHubは、影響を受けたエンドポイントを隔離し、悪意のある拡張機能のバージョンを削除しました
• 同社は直ちにインシデント対応を開始しました
• GitHubは、現在の調査結果によると、GitHub内部のリポジトリからのデータ流出のみが確認されていると述べました
• また、GitHubは、この件が公表された時点では、これらの内部リポジトリ以外に保存されている顧客情報への影響を示す証拠はないと述べています。

あるサイバー犯罪フォーラムで、犯行声明が投稿されました。 GitHubは、その実行主体について公に名指ししておらず、この主張は未確認のものとして扱うべきです。

現時点では、既知の影響範囲は社内リポジトリに限定されており、顧客のリポジトリは対象外です。 しかし、セキュリティチームやITチームにとって、このインシデントの影響はGitHub自体にとどまりません。その理由は、アクセス経路が非常に一般的なものだからです。つまり、馴染みのあるエコシステムから、一見信頼できそうな拡張機能を実行している、信頼された開発者向けエンドポイントを通じてアクセスが行われたのです。

なぜこの事件は、単なる悪意のある拡張機能の問題にとどまらないのでしょうか

簡単に言えば、マーケットプレイスの審査が不十分だったということです。 さらに深く考えると、IDEの拡張機能は依然としてアンマネージドなソフトウェアサプライチェーンであると言えます。 これらは、環境内の他のほぼすべてのソフトウェアカテゴリに適用されているガバナンスの対象外となり、インストールや更新が行われ、開発者レベルのアクセス権限が与えられています。

現代の開発環境には、従来のエンドポイントやソフトウェアのガバナンスワークフローの範囲外にあるコンポーネントが数多く含まれています：

• IDEの拡張機能
• パッケージマネージャーとパッケージ
• ローカルAIコーディングツール
• CLI ヘルパー
• 言語サーバー
• プラグインをビルドする
• Repo固有の推奨ツール
• 開発者のワークフローを効率化する、カスタムユーティリティと設定

これらはいずれも、侵入の第一歩となり得ます。 開発者のマシンに侵入すると、攻撃者は単にコードにアクセスできるだけでなく、その背後にあるあらゆるものへのアクセス権も得ることになります。

開発者向けエンドポイントがなぜこれほど価値の高い標的となるのか

開発者用ワークステーションは、多くの場合、特権が集中して付与されているため、極めて価値が高いものです。

影響範囲には通常、ソースコード以外にもさまざまな要素が含まれます

悪用された拡張機能は、以下の場所にアクセスできる可能性があります：

• ソース管理の認証情報
• クラウドアクセストークン
• SSH鍵
• 環境ファイル内の秘密
• 内部サービス用のローカル設定
• パッケージ公開の認証情報
• コード署名証明書
• AIアシスタントの設定またはAIの活用
• 開発者向けサービスに関連付けられたブラウザセッション

だからこそ、このようなインシデントは「エンドポイントの問題」から組織全体の問題へと急速に拡大し、侵害された開発者が広く利用されているソフトウェアを維持管理している場合には、世界的な懸念事項となるのです。 これらの悪意のある拡張機能は、すべてのシステムを直接侵害する必要はありません。 認証情報や鍵をほんのわずかでも収集するだけで、従来のマルウェア感染よりもはるかに速いペースでアクセス権限を拡大させてしまう可能性があります。

拡張機能は、周囲のツールから信頼性を引き継ぎます

より深刻なリスクは、信頼と技術的な特権に起因しています。 セキュリティチームは、IDEの拡張機能の更新やインストールよりも、実行ファイル、インストーラー、ブラウザからのダウンロードをより厳重に精査することがよくあります。

一方、開発者は、速度やワークフローを向上させるツールをインストールする習慣が身についており、多くの場合、自分のワークステーションで管理者権限を使って作業を行っています。 Two AI-themed extensions alone reached 1.5 million installs before discovery while secretly exfiltrating source code. こうした組み合わせは、特に、すでに のサイバーセキュリティツールの乱立に悩まされている環境において、悪用される理想的な条件を生み出します。

IDEの拡張機能は、現在では攻撃対象領域として認識されています

これはもはや、ごく一部の懸念事項という段階ではありません。 IDEの拡張機能は、既知の、正式に認められた攻撃対象領域です。

MITREは、 2025年3月において、「 」IDE拡張機能をATT&CKの手法として追加しました（ ）。 これが重要なのは、防御側と攻撃側の双方が実戦を通じてすでに学んできたことを反映しているからです。つまり、拡張機能とは、開発者のシステムに対して実質的かつ永続的なアクセス権を持つ実行環境であるということです。

悪意のある拡張機能の発見は、もはや珍しいことではなくなりました。 ReversingLabsによると 、 2025において、悪意のあるVS Codeの検出件数はほぼ4倍に増加しました。

主要な拡張エコシステム全体において、セキュリティ担当者は、毒入りや悪用されたコンポーネントを一定頻度で発見しており、組織としては、これを一時的な急増ではなく、継続的な脅威であると想定すべきです。

セキュリティチームが注目すべき傾向

GitHubのセキュリティ侵害もまた、 2025 および2026で見られる開発者向けツールエコシステム全体に共通する繰り返されるパターンに当てはまります。

一般的な手順は、次のようなものです：

個々の事象をそれぞれ独立した侵害として扱うのは、本質を見失うことになります。 攻撃対象領域は、開発環境そのものです。

多くの組織は、依然として自社のリスクを把握できていません

ここからが、話が気まずくなってくるところです。

多くの組織がこうおっしゃるでしょう：

• 管理しているエンドポイントの数はいくつですか
• 未修正の重大な脆弱性はいくつありますか
• 管理者権限を持つユーザーはどれくらいいますか
• IDEのどのバリエーションの、いくつのバージョンがインストールされているかさえも

「～」と答えられる人は、はるかに少ないのです：

• 開発者用マシン全体で、IDE拡張機能がいくつインストールされていますか
• それらがどの出版社から出版されたか
• 今週、どの拡張機能が変更されましたか
• 過去 24 時間の間に、どのエンドポイントで新しい拡張機能がインストールされましたか
• よりオープンな拡張機能レジストリと連携したIDEを運用している開発者はどの開発者でしょうか

その可視性がなければ、拡張機能を利用した侵害は、データの持ち出しがすでに進行し始めるまで、発見されないままとなります。

IDE拡張機能のリスクに対するTaniumの見解

これは、ある一つの拡張機能についての話ではありません。 これは、拡張機能の衛生管理に関する話です。 IDEの拡張機能は、攻撃の標的となる脆弱性です（ ）。VS Code、Cursor、Windsurf、VSCodium、または類似のツールを使用しているすべての組織は、自組織の環境内でこれを適切に管理する必要があります。

マーケットプレイスの運営事業者は、時間の経過とともにその役割を拡大していますが、組織の環境内で何が実行されるかについての責任は、その組織自身にあります。

Taniumが顧客の環境全体で把握していること：

• macOSエンドポイントの 43％に、少なくとも1つのIDEがインストールされています
• Windowsエンドポイントの 9％に、少なくとも1つのIDEがインストールされています
• 一般的な組織では、 330 個の異なるVS Code拡張機能がインストールされています

ほとんどのセキュリティチームは、自チームが管理しているエンドポイントの数を把握しています。 それらのエンドポイント上でいくつの拡張機能が実行されているか、誰がインストールしたのか、あるいはそれらの拡張機能がどのような情報にアクセスできるのかについて、正確に説明できる人はほとんどいません。 そのギャップこそが、リスクが潜んでいる場所なのです。

拡張機能は、IDEの「Extension Host」内で、IDE本体と同じ権限で実行されます。これは通常、開発者と同じ権限を持つことを意味します。 現代の開発者用マシンには、クラウド、ソース管理、社内サービス、およびAIコーディングアシスタントの認証情報が保存されています。 1つの拡張機能が侵害されるだけで、エンジニアリング部門全体への初期侵入経路となる可能性があります。 爆風範囲は、開発者が手を加えられるすべての要素です。

組織は、IDE拡張機能を、環境に導入される他のソフトウェアと同様に厳格に管理すべきです。 実際には、これは次のようなことを意味します：

• 開発者向けエンドポイントにインストールされているすべての拡張機能のリストを作成する
• 新しい拡張機能の承認プロセスの確立： 2026 では、定評のあるパブリッシャーによる拡張機能が繰り返し悪用されているため、これらを内部ガバナンスの代替として扱うべきではありません
• リスクの先行指標として、新規または変更された拡張機能の監視
• 特に、Cursor、Windsurf、VSCodium などの IDE には細心の注意を払う必要があります。これらの IDE は、バージョンや構成によっては Open VSX やその他のマイクロソフト社以外の拡張機能ソースを使用する場合があり、そのガバナンスモデルはよりオープンであり、審査の責任は組織側に大きくのしかかるためです。
• 一定の間隔で開発者の認証情報をローテーションし、開発者のマシンに保存されている認証情報はすべて、情報が外部へ流出するリスクがあるものとして扱う
• 成熟したプログラムがすでにnpmやPyPIのパッケージに対して適用しているのと同じ厳格なサプライチェーン管理を、IDE拡張機能にも適用すること

これは VS Code 以外にも当てはまります。 GitHubのセキュリティ侵害が発生したのと同じ週に、 のNx Console拡張機能（）から悪意のあるコードが発見されました。このコードは、Claude Codeの設定ファイルに加え、AWS、GitHub、npm、Vault、Kubernetes、および 1Password 件の認証情報を標的としていました。 Microsoftの のdurabletask Python SDKの悪意のあるバージョンも、PyPI に公開されました。

これらは、制御方法や是正措置が異なる種類の侵害ですが、いずれも信頼されている開発者向けツールを悪用しています。 同じ種類のリスクが、複数のエコシステムにまたがって同時に発生していました。 AIツールの拡張機能も、決して安全なカテゴリーとは言えません。「Claude Code」拡張機能に含まれる CVE-2025-52882 件の事例は、このリスクが、開発者が最も信頼しているツールにまで及んでいることを改めて示しています。

IDEの拡張機能は、サプライチェーンの攻撃対象領域となります。 これらを管理するには、可視性、インベントリ、変更の検知、およびライフサイクル管理が必要です。

なぜすでに警告の兆候が見られていたのか

これは、新たな種類の脅威というわけではありません。 のKoi Securityによる調査（ 2025年12月 ）によると、かつては正当な拡張機能であったものを悪用した7年間にわたるブラウザ拡張機能キャンペーンにより、数百万人のユーザーが標的とされていたことが明らかになりました。 GitHubへの不正アクセスは、新たなパターンではなく、既知のパターンであることを裏付けています。

Tanium社は、この攻撃対象領域の管理に関するガイダンスを、以前「 2026」で公開しました。 すでに資産管理や変更検知の体制を整えている組織は、この種の攻撃がインシデントに発展する前に検知できる態勢が整っています。

マーケットプレイスでは、今後徐々に審査体制が改善されていくと思われますが、現時点では、貴組織は自社の環境内で何が実行されているかを把握し、侵害された拡張機能が発見された際に、迅速に対応できるよう、変更を速やかに検知できるかどうかを確認しておく必要があります。

セキュリティチームが今すべきこと

適切な対応とは、パニックに陥ることでもなければ、適正な手続きを経ない一律の禁止措置でもありません。 それは規律あるガバナンスです。

1. 拡張機能のインベントリを作成する

まずは基本的な質問から始めましょう。現在、何がインストールされているのでしょうか？

以下の品目の最新の在庫状況が必要です：

• 使用中のIDE
• エンドポイントごとの拡張機能
• 拡張機能の発行元
• バージョン
• 初回公開日
• 最終更新日

それがなければ、手探りの状態で対応することになってしまいます。 エンドポイントの在庫状況や拡張機能固有のテレメトリを適時に把握できていないチームは、こうした基本的な質問にさえ答えるのに苦労することになるでしょう。

2。 予期せぬ拡張機能の変更をセキュリティインシデントとして扱う

開発者のマシンに新しくインストールされた、あるいは新しく更新された拡張機能は、表示されないようなことがあってはなりません。 多くの環境において、これは、異常なレポ取引へのアクセスに関連した後期段階の警告よりも、より強力な早期警告のシグナルとなります。 アラート疲労を回避するためには、変更管理、承認済みの拡張機能、および既知の開発者ベースラインとの関連性を把握することが不可欠です。

3。 審査・承認の仕組みを確立する

「認証済みパブリッシャー」は、内部ガバナンスの代わりとして扱われるべきではありません。 そのシグナルは信頼を重視する助けにはなりますが、それだけで会話を終わらせてはいけません。

4。 代替の拡張機能エコシステムには細心の注意を払ってください

組織では、設計上よりオープンな拡張機能レジストリを基盤としたツールを支持する傾向が強まっています。 これは開発者の柔軟性を高める上で役立つかもしれませんが、その一方で、検証の責任をより多く企業側に負わせる結果となります。

5。 開発者の認証情報をローテーションおよび削減する

開発者のマシンに保存されているものはすべて、収集の対象となり得ると想定してください。 これには、古い鍵、期限切れのセッション、パッケージトークン、そして誰も存在を忘れてしまっているローカル環境のシークレットなどが含まれます。

6。 インシデント対応プレイブックを拡張し、開発者向けツールを組み込む

IRプロセスでは、以下の点を明確に盛り込む必要があります：

• 悪意のある拡張機能
• 改ざんされたローカルパッケージ
• Repoが推奨するツールの悪用
• AIコーディングツールの設定
• 拡張機能を利用した認証情報の盗難

開発者向けツールに関する情報漏洩後の対応マニュアルを更新していない組織は、この攻撃経路に対する備えが不十分である可能性が高いです。

実用的な対応フレームワークとはどのようなものか

対応策の一般的な指針は、3つの時間軸、すなわち「直ちなる封じ込め」、「短期的なガバナンス」、そして「継続的なサプライチェーン管理」に沿ったものです。

の包括的なサイバー衛生プログラム（ ）を活用することで、これらの対策を事後対応ではなく、持続可能なものにするのに役立ちます。

GitHubのセキュリティ侵害から読み取りすぎないべき点

避けるべき簡単な間違いがいくつかあります。

この話を単なる出典の帰属問題に矮小化しないでください。 時間の経過とともに犯行の帰属が明らかになるかもしれませんが、運用上の教訓は、犯人を特定することには依存しません。 リスクとは、攻撃経路のことです。

その出来事が注目を集めているからといって、顧客への影響があるとは決めつけないでください。 GitHubの公式声明によると、影響を受けた社内リポジトリ以外に保存されている顧客情報への影響を示す証拠はないとのことです。 捜査は状況に応じて変化していくことを踏まえ、この件は真剣に受け止めるべきです。

1つの拡張機能を削除すれば問題が解決するとは、決めつけないでください。 悪意のある拡張機能が特定された時点で、より重要なのは、それが存在していた間に何にアクセスしていたかという点です。 だからこそ、ID、リポジトリ、クラウド、ネットワークのログ記録に加え、エンドポイントの継続的なテレメトリと迅速な封じ込めが重要となるのです。 初期の予防だけでは不十分です。 対応担当者は、その拡張機能が何にアクセスしたか、またその後どのような認証情報が使用されたかを特定するために、ドメインをまたぐ証拠を必要とします。

GitHubのセキュリティ侵害に関するよくある質問

GitHubのセキュリティ侵害を受けて、セキュリティチームから多くの質問が寄せられています。 以下に、最も一般的なものを挙げます。

GitHubのセキュリティ侵害において、顧客のリポジトリへのアクセスはありましたか？

GitHubは、現在の調査の結果、GitHub内部のリポジトリ以外に保存されている顧客情報への影響を示す証拠は見つからなかったと発表しました。 これが現時点での公表されている状況です。

GitHubのセキュリティ侵害を引き起こしたのは、どの拡張機能だったのでしょうか？

GitHubは、声明を発表した時点では、その拡張機能の名称を公表していませんでした。 ほとんどの組織にとって、特定の名前を待つよりも、インストールされているすべての拡張機能を監査するほうが、より現実的な対応策となります。

組織はIDE拡張機能の使用をやめるべきでしょうか？

いいえ。しかし、それらを管理不要な便利なソフトウェアとして扱うのはやめるべきです。 拡張機能には、在庫管理、承認、変更の監視、およびライフサイクル管理が必要です。

私のチームが社内でGitHubを使用していない場合、なぜこれが関係してくるのでしょうか？

このレッスンはGitHubに特化した内容ではないからです。 開発者向けエンドポイント、ソースコードへのアクセス権、クラウドの認証情報、および拡張機能が多用されるワークフローを持つ組織は、いずれも同種のリスクにさらされています。

最も重要なポイント

GitHubのセキュリティ侵害は、単なるまた一つのセキュリティ侵害のニュース見出しに過ぎません。 これは、開発者向けツールのガバナンスが、最前線のセキュリティ課題となっていることを明確に示しています。

セキュリティチームは、サーバー、ノートパソコン、モバイルデバイス、およびクラウドワークロードに対する可視性を高めるために、長年にわたり取り組んできました。 現在、開発環境内で実行されるもの、特に拡張機能やローカルツール、そしてそれらのツールがアクセス可能な認証情報についても、同様の規律が求められています。

それが、この出来事から得られる本当の教訓です。 もはや、IDEの拡張機能が悪用される可能性があることを証明すること自体が課題ではありません。 課題は、組織が、すでに のソフトウェア・サプライチェーン・リスク（ ）と同様に、これらを管理する準備ができているかどうかという点です。

GitHubのセキュリティ侵害を受けて、開発者のエンドポイント、ソフトウェアのインベントリ、および拡張機能による変更の監視方法を見直しているチームにとって、可視性とガバナンスこそが、この抽象的なサプライチェーンリスクを、セキュリティチームが実際に管理できるものへと変える鍵となります。
デモをご依頼ください 。Taniumが、組織の環境全体にわたるエンドポイント、拡張機能、およびソフトウェアの変更について、どのように可視性を提供するかをご確認いただけます。