GlassWormは、npmやGitHub、VS Code拡張などの開発者エコシステムを悪用するサプライチェーン型の攻撃キャンペーンである。単一のマルウェアではなく、複数の手法を組み合わせて展開される攻撃のまとまりとして観測されている。
この攻撃の特徴は、次のような「信頼された経路」をそのまま利用する点にある。
- 正規パッケージ
- 正規リポジトリ
- 正規拡張機能
そのため、通常の開発作業の中で侵入が成立する。
どのように広がるか
GlassWormは、開発フローの中に紛れ込む形で拡散する。
基本的な流れは以下の通りである。
- 正規のパッケージや拡張機能を装って配布される、または既存の正規リソースが侵害される
- 開発環境で実行される
- 認証情報（トークンやSSHキーなど）を窃取する
- その認証情報を使って別のリポジトリやパッケージにアクセスする
- 新たな汚染を発生させ、拡散する
このように、自己増殖型のワームそのものではないが、認証情報を足がかりに連鎖的に拡散していく。
侵入の手口
侵入は一つの方法に限定されない。複数の経路が組み合わされる。
主な例：
- 侵害された開発者アカウントによるパッケージ更新
- 依存関係の乗っ取り
- 悪意ある拡張機能の公開
いずれも正規の操作に見えるため、検知が難しい。
技術的な特徴
GlassWormでは、コードの見え方を利用した回避手法が使われる。
代表的なのが不可視Unicodeの悪用である。
- ゼロ幅文字
- バリエーションセレクタ
- Unicodeの制御文字
これらは画面上では見えないが、コードとしては意味を持つ。その結果、レビュー時に不正な処理が見えにくくなる。
また、実行は既存の開発環境の中で行われることが多く、特にJavaScript（Node.js）を中心に広がっている。
- Node.js
- Python
- シェル環境
特別なバイナリを必要としないため、通常の作業と区別がつきにくい。
何が問題なのか
この攻撃の本質的な問題は、信頼の仕組みがそのまま悪用される点にある。
- 信頼された配布経路が攻撃経路になる
- 認証情報が奪われることで侵害が連鎖する
- 個別端末ではなく開発基盤全体に影響が及ぶ
その結果、影響範囲が広くなりやすい。
対策の考え方
対策は、個々のコードだけでなく供給経路全体を前提に考える必要がある。
基本となる対策は次の通りである。
- 依存関係を固定し、意図しない更新を防ぐ
- トークンの権限を最小限にする
- 短寿命の認証情報を使用する
- 署名付きパッケージを検証する
- 不可視Unicodeの混入を検出する
- 開発環境の異常な挙動を監視する
また、Git操作履歴（force pushや不自然な公開変更）の監視も有効である。
まとめ
GlassWormは、開発者エコシステムの中に入り込み、認証情報を起点として広がるサプライチェーン攻撃である。
従来のマルウェア対策だけでは不十分であり、ソフトウェアの供給経路全体を前提としたセキュリティ設計が求められる。
