セキュリティ

GlassWormとは｜VSCode拡張サプライチェーン攻撃の手口と中小企業の対策チェックリスト【2026年版】

2026年5月4日29分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

セキュリティ

この記事の結論

GlassWormは2025年10月にKoi Securityが発見した、VSCode／Open VSXの拡張機能を悪用する初の自己増殖型マルウェア。開発者のGitHub・npm・OpenVSXトークンを盗み、その資格情報で別の拡張を自動改ざんして拡散する。不可視Unicodeで悪意コードをエディタ上から消し、SolanaブロックチェーンとGoogle CalendarをC2に使う点が新しい。本記事は一次ソースで確認できる事実だけを整理したうえで、社内にIT専任がいない中小企業が『拡張機能のサプライチェーンリスクに自社はどう備えるか』を判断するための影響判定フレーム・失敗パターン・発注前チェックリスト・ベンダーへの質問集を提供する。

この記事の結論（30秒） GlassWormは、2025年10月にセキュリティ企業Koi Securityが発見した、VSCode系エディタの拡張機能を悪用する「自己増殖型」のマルウェアです。特徴は3つ。(1) 悪意コードを画面上から消す不可視Unicode、(2) 盗んだ開発者のトークンで別の拡張を自動改ざんして拡散するワーム挙動、(3) 停止させにくいSolanaブロックチェーン／Google CalendarのC2。狙われるのはあなたの会社の売上データではなく、開発者PC1台に置かれたGitHub・npm・クラウドの資格情報です。ここが盗まれると、ソースコード・本番環境・顧客データまで芋づる式に危険になります。中小企業がまずやるべきは、派手な製品導入ではなく「誰のPCに、どんな拡張が、どんな権限で入っているか」の棚卸しと、資格情報の平文放置をやめることです。

VSCode（Visual Studio Code）とその派生エディタは、いまや日本の開発現場の事実上の標準です。CursorやWindsurfのようなAIコーディングツールもVSCodeをベースにしており、拡張機能の配布基盤であるOpen VSX Registryを共有しています。つまり「うちはMicrosoftの公式Marketplaceしか使っていない」と思っていても、実際にはAIツール経由でOpen VSXの拡張を取り込んでいるケースが少なくありません。GlassWormが最初に足場にしたのが、まさにこのOpen VSXでした。

この記事は、ニュースの要約ではありません。一次ソース（発見元のKoi Securityおよび複数のセキュリティベンダー報告）で確認できる事実と、確認できていない点を切り分けたうえで、社内にIT判断力の専任者がいない成長企業の経営者・実務決裁者が「自社は何を確認し、どこで判断を誤りやすいか」を持ち帰れるように構成しました。

なぜ今、この記事を読むべきか（鮮度）

GlassWormは「終わった事件」ではありません。時系列を一次情報ベースで整理すると、次のように断続的に続いています。

2025年10月17日：Open VSX上の拡張「CodeJoy」(codejoy.codejoy-vscode-extension) のバージョン1.8.3／1.8.4に不審な挙動が出現。同日に計7つの拡張が汚染。（Koi Security）
2025年10月18日：Koi Securityが検知・分析を開始。研究者Idan Dardikman氏が公表。
2025年10月20日時点：Microsoftは公式Marketplaceから該当拡張を削除。一方でOpen VSX上には少なくとも4つの汚染拡張が残存し、C2サーバは稼働中と報告（BleepingComputer）。累計インストールは推定約35,800件。
2026年1月31日以降：Open VSXで追加72件の悪意ある拡張を確認。3月3〜9日にはGitHubリポジトリ151件が影響を受けたと複数ベンダーが報告（The Hacker News、Socket等）。

つまり、初報から半年以上が経過してもキャンペーンは継続しており、拡張機能はユーザー操作なしで自動更新されるため、「一度入れて放置している拡張」が最大の穴になります。過去に無害だった拡張が、ある日のアップデートで汚染される――これがサプライチェーン攻撃の本質です。だからこそ、事件当時のニュースを読んだだけで対策した気になっている企業ほど、いま棚卸しをやり直す価値があります。

FREE DOWNLOAD

中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします

多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。

5ステップガイドを無料でダウンロード

GlassWormで「確認されている事実」と「未確認の点」

まず、一次ソースで裏が取れている事実を表に整理します。ここに書いていない拡張名・被害額・特定企業名は、公開情報では確認できないため本記事では断定しません。

横にスクロールして確認できます

項目	確認されている内容	出典の性質
発見元・時期	Koi Securityが2025年10月17〜18日に検知	ベンダー一次情報
最初の汚染拡張	Open VSXの「CodeJoy」v1.8.3／1.8.4	ベンダー一次情報
初期規模	第一波で計7拡張、累計約35,800インストール	ベンダー一次情報
主な標的	GitHub／npm／OpenVSXのトークン、Git資格情報、暗号資産ウォレット拡張（49種）	ベンダー一次情報
隠蔽手法	不可視のUnicode変異セレクタで悪意コードをエディタ上から不可視化	ベンダー一次情報
C2基盤	Solanaブロックチェーン（デッドドロップ）、予備にGoogle Calendar	ベンダー一次情報
自己増殖	盗んだトークンで別拡張／パッケージを自動改ざんし拡散	ベンダー一次情報
2026年の継続	1月31日以降にOpen VSXで追加72拡張、3月にGitHub 151リポジトリに波及	複数ベンダー報告

重要な注記：GlassWormに関する情報は、Koi Securityをはじめとするセキュリティベンダーの調査報告が主な出典です。JPCERT/CCやIPAの公式アドバイザリで日本語の一次情報が出ているかは、対応時点で必ず確認してください。特定の被害企業名・被害総額といった数値は、公開情報では確定していません。二次報道の数字を鵜呑みにせず、出典の一次性を毎回チェックする姿勢が、正しい脅威モデルを組む第一歩です。

何が「新しい」のか：3つの技術的ブレークスルー

GlassWormが専門家に衝撃を与えたのは、被害規模の大きさよりも「手口の質」です。中小企業の経営者が理解しておくべきは、次の3点が従来の防御の前提を崩していることです。

1. 不可視Unicode：レビューしても「見えない」悪意コード

攻撃者は、Unicodeの「変異セレクタ（variation selector）」という、画面に何も表示されない特殊文字の中に実行コードを埋め込みました。人間がコードエディタで開いても空白にしか見えませんが、JavaScriptのインタプリタは正規のコードとして実行します。つまり「ソースを目視レビューしたから安全」という常識が通用しません。従来のコードレビューや一部の静的解析をすり抜ける設計になっている点が、この攻撃の第一の恐ろしさです。

2. 自己増殖：世界初の「拡張機能ワーム」

多くのマルウェアは、感染して情報を盗んだら終わりです。GlassWormは違います。感染した開発者PCからGitHub・npm・OpenVSXの認証トークンを盗み、そのトークンを使って別の拡張やパッケージを自動的に改ざん・再公開します。被害者一人ひとりが次の感染源（launch point）になるため、感染が指数関数的に広がる可能性があります。これがVSCode拡張で観測された初の「ワーム型」自己増殖とされる理由です。1社の1台が感染すると、その開発者がメンテナンスしているOSS拡張の利用者全員に波及しうる、という連鎖構造を持ちます。

3. 止められないC2：ブロックチェーンとカレンダー

攻撃の司令塔（C2）は、Solanaブロックチェーン上のトランザクションを「デッドドロップ（伝言板）」として使い、次の通信先を取得します。ブロックチェーンは削除できないため、通報でサーバを落としても指令経路が生き残ります。予備経路として公開Google Calendarのイベント名にBase64エンコードした配信先を仕込む、というレッグまで用意されていました。「悪いサーバを1つ止めれば終わり」という前提が崩れていることを意味します。

さらに、盗んだ端末をSOCKSプロキシ化して犯罪通信の踏み台にする、タスクマネージャに現れない不可視のリモートデスクトップ（HVNC）で遠隔操作する、といった追加ペイロードも報告されています。要するに、感染端末は「情報を抜かれる」だけでなく「他社攻撃の道具」にされる恐れがあるということです。

FREE DOWNLOAD

中小企業の脆弱性対応月次運用テンプレ

情シス1人体制でも回せる脆弱性棚卸・対応フローのテンプレート（Excel版）。

30分で相談するテンプレをDL

攻撃の流れ（キルチェーン）を1本の線で理解する

専門用語を外して、実際にどう被害が広がるのかを順に追います。

入口：開発者が便利な拡張を1つインストールする。あるいは既にインストール済みの拡張が自動更新で汚染版に置き換わる（ユーザーは気づかない）。
窃取：拡張が起動と同時に、PC内の~/.aws/credentials・~/.gitconfig・~/.ssh/・.env・ブラウザのCookieやセッショントークン、暗号資産ウォレットを探索し、外部へ送信する。
横展開：盗んだGitHub／npm／OpenVSXトークンで、その開発者が権限を持つリポジトリやパッケージ、拡張に悪意コードを注入して再公開する。
常駐・悪用：感染端末が遠隔操作やプロキシの踏み台として使われ、社内のGitやクラウド、本番環境へアクセスが試みられる。
拡散：改ざんされた拡張・パッケージを、他社・他開発者が取り込み、2に戻る。

この流れで最も見落とされがちなのが2の「認証情報がPCに平文で置かれている」前提です。多くの現場で、AWSのアクセスキーやGitのトークンがホームディレクトリに平文で保存されています。攻撃者はソースコードそのものより、この「鍵の束」を狙います。鍵さえあれば、時間をかけてどこにでも入れるからです。

「うちは開発会社じゃないから関係ない」が危険な理由

この事件を「エンジニアの話」として片づける経営判断こそ、最大の落とし穴です。次のいずれかに当てはまる中小企業は、規模に関係なく当事者です。

業務システムやWebサイトを外注し、その保守を受けている開発会社／フリーランスがVSCodeを使っている：委託先の端末が感染すれば、あなたの会社のソースや接続情報が漏れます。
社内にひとりでも「開発っぽい作業」をする人がいる：情シス兼任者がスクリプトを書く、マーケがGAS（Google Apps Script）やAIツールでコードを触る、といった状況でも拡張は使われます。
CursorやWindsurf、GitHub CopilotなどのAIコーディングツールを導入した：これらはVSCode系であり、拡張とレジストリのリスクを継承します。導入判断の観点はAIコーディングツール5強の比較と選び方で整理しています。
開発を内製化しようとしている／エンジニアを採用し始めた：人が増えるほど、管理されていない拡張のアタックサーフェスが広がります。

「自社に開発機能がある／委託先に開発を任せている」時点で、拡張機能のサプライチェーンはあなたの会社のサプライチェーンの一部です。ここを他人事にできる中小企業はほとんどありません。

自社への影響をどう判定するか（GXOの影響判定フレーム）

ニュースを「怖い」で終わらせないために、GXOが最初に使う判定の順序を示します。上から順に潰していくと、自社のリスクの輪郭が見えます。

在庫（誰の・何が）：どのPCに、どの拡張が、どのバージョンで入っているか。委託先も含めて把握しているか。
権限（何ができる）：その開発端末から、本番環境・顧客データ・Git・クラウドのどこまで到達できるか。
鍵の置き場所（何が盗まれる）：AWSキー・Gitトークン・APIキーがPC内に平文で置かれていないか。
検知（気づけるか）：拡張が不審な外部通信や認証情報アクセスをしたとき、誰かが気づける仕組みがあるか（EDR等）。
初動（止められるか）：感染が疑われたとき、60分以内にトークン失効・端末隔離に着手できる連絡体制があるか。
報告（説明できるか）：経営会議で「うちの現在地」を1枚で説明できるか。

この6段のうち、1と3が空欄のまま製品（EDRやSBOMツール）を買う企業が非常に多い――これが後述する典型的な失敗です。順番を守ることが、無駄な出費と防御の穴を同時に防ぎます。

GXOが見る「本当の失敗パターン」5つ

セキュリティ製品のカタログには載らない、意思決定の失敗を挙げます。GXOがセキュリティ相談で繰り返し目にするパターンです（特定の顧客事例ではなく、判断の型として提示します）。

失敗1：ニュースに反応して製品だけ買う。EDRやSBOMを導入したが、そもそも「誰が何の拡張を入れているか」を知らないまま。棚卸し（1）と鍵の分離（3）が抜けているため、製品が守る対象が定義できていない。
失敗2：委託先・フリーランスを対象外にする。自社正社員のPCだけルール化し、実際にコードを触る委託先端末を野放しにする。サプライチェーン攻撃の入口はむしろ社外にある。
失敗3：「禁止」だけして代替を用意しない。拡張の自由インストールを禁止したが、必要な拡張の申請・承認フローを整えなかったため、現場が個人PCやBYODに逃げてシャドーIT化する。
失敗4：認証情報を平文で放置し続ける。ガバナンス文書は立派だが、~/.aws/credentialsは平文のまま。攻撃者が狙う「鍵の束」に手をつけていない。
失敗5：初動の連絡線が決まっていない。感染疑いが出た深夜に「誰に連絡し、誰がトークンを失効するか」が未定。分単位で被害が広がるインシデントで、初動が翌営業日になる。

これらはいずれも「予算不足」ではなく「順番と役割分担の設計不足」で起きます。だからこそ、外部の専門家と一緒にセキュリティ体制の全体像を再設計することが、単発ツール導入より費用対効果が高くなります。GXOが重視するのは、話題性ではなく「自社の業務・データ・権限・運用責任にどう効くか」への翻訳です。

発注前・対応前チェックリスト（実務でそのまま使える）

自社で進めるか、外部と整理するかを判断するための確認項目です。半分以上に「NO／不明」がつくなら、体制設計から外部の目を入れる段階です。

拡張機能ガバナンスの実装ステップ（何を・どの順で）

チェックリストを「やる」に変えるための実装順です。中小企業では、いきなり全部を完璧にやろうとせず、上から着手するのが現実的です。

棚卸し：全端末の拡張を一覧化し、発行元・最終更新日・権限を可視化する。ここを飛ばして製品を買わない。
許可リスト：Microsoft公式・主要言語のLSP・Linter・Formatter・Gitなどを基本セットに、業務で必要な拡張を追加。禁止（出自不明・過剰権限）を明確化。申請フローをセットで作る。
認証情報の分離：鍵をPCの平文から、OS Keychain・クラウドSSO・シークレットマネージャへ移す。ここが被害規模を最も大きく左右する。
検知（EDR連携）：開発端末をEDR管理下に置き、「VSCodeプロセスから~/.sshや~/.awsへの異常アクセス」「不審な外部通信」を検知対象にする。
CI/自動化：gitleaks／TruffleHogでのシークレット混入検知、依存関係の監査（Socket等）、Dependabot／Renovateでの更新管理を仕組み化し、人手依存を減らす。
インシデント手順：拡張アンインストール→通信ログ確認→トークン一斉ローテーション→影響範囲特定→JPCERT/CC・IPAや専門ベンダーへの報告、という初動を文書化。
教育と経営報告：入社時・年次の短時間研修で「なぜ許可リストなのか」を共有し、EDRカバレッジ率や許可リスト外検出件数を経営KPIに載せる。

なお「信頼しない前提で権限とアクセスを組み直す」という発想は、拡張機能ガバナンス単体ではなく全社防御の思想に接続します。より広い設計は中小企業のゼロトラスト導入の段階的ガイドで扱っています。

ベンダー・顧問に「何を聞くべきか」

セキュリティを外部に相談する際、製品名から入ると売り手の得意分野に引っ張られます。次の順で質問すると、御社の実態に合った提案かを見抜けます。

「まず何台の・誰の端末を、どうやって棚卸ししますか？」（在庫の把握方法を最初に語れるか）
「委託先・フリーランスの端末はどう扱いますか？」（社外を対象に含める設計か）
「認証情報の平文放置は、どの順で・どこへ移しますか？」（製品より先に鍵の分離を語れるか）
「感染疑いが出たとき、初動は誰が・何分以内に・何をしますか？」（運用まで踏み込めるか）
「導入後、経営会議に何を・どの頻度で報告できるようになりますか？」（経営接続の視点があるか）

これらに「まず製品を入れましょう」としか答えないベンダーは、順番を理解していません。逆に、棚卸しと鍵の分離から話し始める相手は信頼できます。

体制設計の判断軸（人を採るか、顧問で回すか）

「専任のセキュリティ担当を採用すべきか」は中小企業共通の悩みです。金額の目安は各社の構成で大きく変わるため、ここでは判断軸を提示します（具体的な費用は自社構成・委託範囲・対象台数で見積もりが必要です）。

専任採用が向く：開発組織が継続的に拡大し、セキュリティ運用が毎日の業務量として発生している。採用と育成の時間投資を回収できる規模。
顧問（リテイナー）が向く：情シスが1名または兼任で、棚卸し・判定・対応の「判断」を外部に補完したい。日常運用は社内、専門判断は外部という分業。
単発診断で足りる：まず現在地を知りたい、経営会議に出す一次評価がほしい。ただし単発は「その時点の写真」であり、拡張は更新で変わるため、継続監視への接続を前提にする。

GXOは、話題性の高い単発対応よりも、月次で棚卸し・優先順位付け・証跡管理・改善実行までを運用化する方が、中小企業の防御力になると考えています。特にIT専任がいない体制では、月額で伴走するセキュリティ運用（リテイナー）のように「判定と対応代行」まで含む形が現実解になりやすい領域です。

放置した場合と整備した場合の違い

横にスクロールして確認できます

観点	放置した場合	整備した場合
業務影響	感染に気づけず、被害範囲の特定に何日もかかる	影響範囲・期限・責任者を決めて初動できる
投資判断	ニュースのたびに単発でツールを買い、効果測定が曖昧	棚卸し→鍵分離→検知の順で、リスク低減に紐付く投資になる
現場運用	禁止だけが残り、現場がBYODへ逃げてシャドーIT化	許可リスト＋申請フローで、自由と安全が両立する
経営報告	問題発生後に慌てて説明資料を作る	四半期で現在地・課題・次の一手を1枚で説明できる

この記事を読むべき人

開発を外注しており、委託先の端末経由の情報漏えいが想像できていなかった経営者・事業責任者
CursorやGitHub CopilotなどAIコーディングツールを導入したが、拡張とレジストリのリスクまで検討していなかった実務決裁者
情シスが1名または兼任で、「うちのリスクの現在地」を経営会議に説明する材料が欲しい担当者
「セキュリティ製品は入れたが、それが何を守っているのか説明できない」と薄々感じている責任者

GXOに相談すべきタイミング

次のサインが1つでも出たら、社内だけで抱えず外部の目を入れる段階です。

全端末（委託先含む）の拡張を誰も一覧化できていない
認証情報がPCに平文で置かれているかわからない／確認していない
感染疑いが出たときの初動の責任者と手順が空欄
過去にニュースで対策した「つもり」だが、その後の再点検をしていない
AIコーディングツールを現場判断で導入し、全社ルールがない

初動が固まっていない状態でインシデントが起きると、被害は分単位で拡大します。緊急時に迷わないための備えは、平時にしか作れません。実際に侵害が疑われる局面での動き方はインシデント対応の初動と相談窓口にまとめています。

FAQ：よくある質問

Q1：Microsoftの公式Marketplaceだけ使えば安全ですか？

A：安全とは言い切れません。GlassWormの起点はOpen VSXでしたが、Microsoft公式Marketplaceでも汚染拡張が確認され、削除対応が取られました。また人気拡張のメンテナアカウントが乗っ取られれば、公式でも汚染版が配信されます。「配布元」ではなく「拡張ごとの発行元・権限・更新履歴」で判断してください。

Q2：拡張は自動更新されるとのことですが、切るべきですか？

A：一律に切るのは推奨しません。自動更新はセキュリティ修正も運ぶためです。現実解は、許可リストで「入れてよい拡張」を絞り、EDRで異常挙動を検知し、CIでシークレット混入を止める多層防御です。自動更新の便利さを許可リストと検知でコントロールする、という発想が有効です。

Q3：CursorやWindsurfなどAIコーディングツールは特別なリスクがありますか？

A：はい。VSCode系である以上、拡張とOpen VSXのリスクを継承します。加えて、コードやプロンプトが外部AIへ送信される点が上乗せリスクです。Enterprise契約での学習利用拒否・DPA締結、社内発行のAPIキー集中管理、送信データの監査ログ取得を検討してください。ツール選定の観点はAIコーディングツールの比較記事を参照してください。

Q4：オープンソース拡張が安全かどうか、どう見分けますか？

A：完全な判別は困難ですが、(1) 拡張ページからGitHubリポジトリが実在してリンクされているか、(2) コミットやIssueが活発にメンテされているか、(3) 発行元がMicrosoft認証や著名OSS組織か個人か、(4) 要求権限が最小か過剰か、の4点で相対的なリスクは下げられます。ただしGlassWormのように「正規拡張が後から汚染される」ケースは、初回チェックだけでは防げません。継続的な検知が必要です。

Q5：委託先の開発会社にはどう要求すればよいですか？

A：契約・発注時に、開発端末のEDR導入、拡張の許可リスト運用、認証情報の平文放置禁止、インシデント時の報告義務を条件に含めるのが実務的です。「御社はGlassWorm型のサプライチェーン攻撃にどう備えていますか」と一問投げるだけでも、相手のセキュリティ成熟度が測れます。

Q6：まず何から始めればコストを抑えられますか？

A：お金をかけずに効くのは「棚卸し」と「認証情報の平文放置をやめる」ことです。この2つはツール購入前でも着手でき、被害規模を最も大きく下げます。順番を守り、在庫と鍵を押さえてから検知製品を検討するのが、無駄のない進め方です。

まとめ

GlassWormは、拡張機能というエンジニアの日常に潜り込み、開発者PCの「鍵の束」を奪って自己増殖する、防御の前提を崩す攻撃でした。不可視Unicodeで目視を無効化し、盗んだトークンで拡散し、ブロックチェーンで指令経路を生き延びさせる――どれも「1つ対策すれば終わり」という発想を許しません。

中小企業にとっての現実的な守りは、派手な製品導入ではなく、(1) 委託先を含めた拡張の棚卸し、(2) 認証情報の平文放置をやめる、(3) 異常を検知し初動を回す体制、の順で積み上げることです。ニュースを「怖い」で終わらせず、自社資産・影響判定・対応期限・経営報告へ翻訳して初めて、それは防御力になります。

社内にIT専任がいなくても、判断と対応を外部で補完しながら運用を止めない形は作れます。まずは自社の現在地を棚卸しから確認し、必要に応じてセキュリティ体制の再構築を専門家と一緒に設計することをおすすめします。