想定読者: 年商 50-300 億 / 従業員 100-1000 名の中堅企業で、開発組織を抱える情シス / 開発リーダー / セキュリティ責任者。「開発者は VSCode 拡張を自由に入れとる」「拡張機能経由のリスクを把握しとらん」「最近のサプライチェーン攻撃ニュースが気になる」と感じとる人向け。 本記事の使い方: VSCode マーケットプレイス経由のサプライチェーン攻撃（「GlassWorm」系として総称される拡張機能マルウェア）の攻撃シナリオ整理 + 8 ステップ防御ガイドで、開発者セキュリティを 1 記事で完結。

結論を 30 秒で。 VSCode マーケットプレイスは月数十億ダウンロード規模で、悪意ある拡張 / 乗っ取られた人気拡張 / typosquatting（似た名前で偽装） がサプライチェーン攻撃の主要経路になっとる。中堅企業の開発組織で「拡張機能を自由に入れる」運用は、API キー / Git 認証情報 / 顧客データ への間接アクセスを攻撃者に渡しかねん。本記事は 8 ステップ防御ガイド（(1) 棚卸し / (2) 許可リスト / (3) 認証情報保護 / (4) EDR 連携 / (5) SBOM / (6) インシデント対応 / (7) 教育 / (8) 経営報告）でこれを完成させる。

注: 本記事の「GlassWorm」は VSCode マーケットプレイス経由のサプライチェーン攻撃 / 拡張機能マルウェアの総称 として用いる。具体的な攻撃事例 / 拡張名 / 被害規模は、各セキュリティベンダーのアドバイザリで確認が必要。

なぜ VSCode 拡張がサプライチェーン攻撃の入り口になるか（30 秒）

3 大要因：

  1. 拡張機能の権限が大きい: ファイル読み書き / 外部通信 / 認証情報アクセス / シェル実行 を拡張が持てる
  2. マーケットプレイスのレビューが限定的: アップロード時の自動スキャン中心、人手レビューは限定
  3. 開発者は「便利だから入れる」習慣: セキュリティリスクを意識せず数十個の拡張機能を入れとる

中堅企業で開発者 30 名 × 平均 10 拡張 = 300 拡張のアタックサーフェス。1 つでも悪意あれば全社のソースコード / 認証情報が流出。

VSCode 拡張サプライチェーン攻撃の典型シナリオ 5 パターン

報告される典型 5 パターン：

#攻撃シナリオ影響
1悪意ある拡張の新規アップロード直接マルウェア配布、低 DL 数で発覚遅延
2人気拡張のメンテナアカウント乗っ取り既存ユーザに更新で配布、影響大
3typosquatting（似た名前で偽装）「prettiercode」「prettier-vscode」等で誤インストール誘発
4依存ライブラリ経由の感染拡張機能の npm 依存に悪意ある package 混入
5設定ファイルからの認証情報窃取`.vscode/settings.json` / `.env` / `credentials.json` を読み出し外部送信

致命: いずれも 開発者の PC 1 台が感染すれば、社内 Git / クラウド / API キー全アクセス が攻撃者に渡る。

攻撃の典型ペイロード

過去の事例で観測される典型動作：

  • `~/.aws/credentials` `~/.gitconfig` `~/.ssh/` の読み出し
  • `.env` ファイルのスキャン + 外部送信
  • ブラウザ Cookie / セッショントークンの窃取
  • npm / pip / cargo の認証トークン窃取
  • 開発機からの クリップボード履歴 読み出し
  • キーロガー動作 + パスワード窃取
  • Cryptojacking（CPU 利用してマイニング）
  • コードベース全体の C2 サーバへの送信

中堅企業の開発機 1 台でこれが起きると、被害は 会社全体のソース / 顧客データ流出 に直結。

8 ステップ防御ガイド（中堅企業向け）

ステップ 1：拡張機能棚卸し

着手前に現状把握：

  • 全開発者の VSCode 拡張一覧収集（`code --list-extensions` を全社実行）
  • 拡張別 DL 数 / Publisher / 最終更新日
  • 内部利用の長期非更新拡張（メンテ放棄リスク）の特定
  • typosquatting 候補（人気拡張と似た名前）の洗い出し

中堅企業典型工数：情シス 1 名 × 16-24 時間（30-50 名規模の開発組織）。

ステップ 2：許可リスト（allowlist）整備

「自由に入れる」から「許可リストのみ」運用へ：

  • 基本許可リスト: Microsoft 公式 / 主要言語 LSP / Linter / Formatter / Git
  • 業務許可リスト: 自社で必要な専門拡張（DB クライアント / クラウド連携など）
  • 禁止リスト: 過去にインシデント発生の Publisher / 不明 Publisher / 過剰権限要求拡張
  • 申請フロー: 新規拡張は情シスへ申請 + 1-2 営業日で承認

中堅企業は 基本 + 業務 = 30-50 拡張 が標準的なホワイトリストサイズ。

ステップ 3：開発者認証情報の保護

開発機から認証情報を OS / クラウド / シークレットマネージャ 経由に分離：

  • OS Keychain 利用: macOS Keychain / Windows Credential Manager / Linux Secret Service
  • クラウド SSO: AWS IAM Identity Center / Azure AD / Google Workspace
  • シークレットマネージャ: HashiCorp Vault / 1Password / Bitwarden の業務利用
  • `.env` を Git にコミットさせない: pre-commit hook + CI スキャン
  • gitleaks / TruffleHog の自動スキャン

最低限：`~/.aws/credentials` を平文ファイルで置かない だけでも被害規模が大幅減。

ステップ 4：EDR 連携 + 異常検知

開発機を EDR（Endpoint Detection and Response）の管理下に：

EDR 製品例開発者向け機能
CrowdStrike Falcon拡張機能の異常通信 / プロセス挙動を検知
SentinelOneBehavioral AI で開発機特化の検知ロジック
Microsoft Defender for EndpointM365 統合、拡張機能 + ブラウザ + シェル統合検知
Wazuh（OSS）OSS、中小規模での開発機監視可
検知すべき動作：
  • VSCode プロセスから `~/.aws` `~/.gitconfig` `~/.ssh` への異常アクセス
  • VSCode プロセスからの不審な外部通信
  • VSCode 拡張による `~/.bashrc` `~/.zshrc` などシェル設定書き換え
  • ブラウザ Cookie への異常アクセス

ステップ 5：SBOM + 依存スキャン

VSCode 拡張は npm 依存を持つため、SBOM + 依存スキャンが有効：

  • 拡張の VSIX ファイル取得 + 依存ツリー解析（必要に応じて）
  • 依存マルウェアスキャン（npm audit / Snyk / Socket）
  • CI/CD パイプラインでの依存チェック: Renovate / Dependabot で更新管理

ステップ 6：インシデント対応プロセス

VSCode 拡張経由の侵害が疑われた際の対応 5 ステップ：

  1. 即座に拡張アンインストール + VSCode 起動停止
  2. EDR で当該拡張のプロセス挙動 / ネットワーク通信ログ確認
  3. 認証情報のローテーション（AWS キー / Git トークン / SSH 鍵 / API キー）
  4. 影響範囲の特定（送信されたデータの追跡）
  5. JPCERT / IPA / セキュリティベンダーへの報告

中堅企業では このプロセスを 60 分以内に着手 できる体制が必要。

ステップ 7：開発者教育

全開発者向け教育プログラム：

  • 入社時 1 時間研修: VSCode 拡張のリスク / 許可リスト / 申請フロー
  • 年 1 回 30 分アップデート: 最新の攻撃事例 / 対策アップデート
  • インシデント発生時の社内共有: 失敗事例を匿名化して横展開
  • セキュリティリーダー育成: 開発組織内に 1-2 名の DevSecOps champion を配置

ステップ 8：経営報告

四半期取締役会報告に開発者セキュリティ KPI を組み込み：

  • 全開発機の EDR カバレッジ率
  • 許可リスト外拡張の検出件数 / 対応状況
  • 拡張機能経由インシデント件数
  • 開発者教育受講率
  • 認証情報ローテーション実施率

中堅企業の運用体制設計

開発組織 30-50 名向けの現実解

規模体制月次コスト
20-30 名情シス 1 名 + EDR + 顧問月 30-60 万円
30-50 名情シス 1-2 名 + 開発側 1 名 + EDR + 顧問月 50-100 万円
50-100 名専任 DevSecOps 1 名 + EDR + 顧問月 100-200 万円
中堅企業は 「専任 DevSecOps 採用」までは行かず、EDR + 顧問でカバー が王道。

CI/CD 統合での自動化

人手に頼らん仕組み：

  • Pre-commit hook: 認証情報チェック / 禁止コマンドチェック
  • CI で gitleaks / TruffleHog: シークレット混入を自動検知
  • CodeQL / Semgrep: 静的解析でマルウェアパターン検知
  • Dependabot / Renovate: 依存更新で typosquatting 早期発見

FAQ：よくある質問

Q1：許可リストにすると開発者が反発しないか？

A：「ほしい拡張を申請したら 1-2 営業日で追加」を保証 + 基本セット（30-50 拡張）の充実で抵抗は最小化できる。事故事例の社内共有で「自由は守られんと持続せん」を理解させる。

Q2：Cursor / Cline 等の AI コーディングツールは？

A：VSCode ベースの AI コーディングツール（Cursor / Cline / Continue 等）も 同じ拡張機能リスク を継承する。さらに AI への送信データ が追加リスク。中堅企業では：

  • Enterprise 契約（学習データ利用拒否 + DPA 締結）
  • API キーの集中管理（個人キーじゃなく社内発行キー）
  • 送信データの監査ログ取得

詳細は AI コーディングツール 5 強比較 を参照。

Q3：個人 PC（BYOD）での VSCode 利用は？

A：原則禁止が望ましいが、現実的には (1) BYOD 規程整備 / (2) MDM 統合 / (3) 業務リソースアクセス時は VPN + デバイス認証 / (4) EDR 強制 で許容。完全禁止より 管理下で許容 が中堅企業の現実解。

Q4：拡張機能のアンインストールは退社時にどうする？

A：退社時の PC 回収 + データ消去 + 認証情報失効 を厳格化する。開発者の 個人 GitHub アカウント などへの社内コードプッシュ禁止も併せて規程化。

Q5：オープンソース拡張の安全確認方法は？

A：4 つの観点：

  1. GitHub リポジトリの実在性（拡張ページからリンクされとるか）
  2. 過去のコミット履歴 / Issue / PR（活発なメンテナンスあるか）
  3. Publisher の信頼性（Microsoft 認証 / 著名 OSS 組織 / 個人）
  4. 拡張 manifest の権限要求（最小権限か / 過剰要求か）

Q6：自社製 VSCode 拡張を社内配布する場合は？

A：3 ステップ：

  1. 私有マーケットプレイス（Open VSX Registry セルフホスト）or VSIX 直接配布
  2. コードレビュー必須化（社内 OSS 同等のプロセス）
  3. 公開前のセキュリティスキャン（依存 / 静的解析 / 動的テスト）

まとめ

VSCode 拡張のサプライチェーン攻撃（GlassWorm 系として総称される攻撃シナリオ）は中堅企業の 開発機 1 台 → 全社ソース / 顧客データ流出 につながる致命的リスク。8 ステップ防御ガイド（棚卸し / 許可リスト / 認証情報保護 / EDR / SBOM / インシデント対応 / 教育 / 経営報告）で開発者セキュリティ基盤を整える。中堅企業 30-50 名規模では 情シス + EDR + 顧問契約 の組み合わせが現実解。

GXO は中堅企業 100+ 社のセキュリティ支援実績で、開発者セキュリティ + DevSecOps + EDR 運用 + インシデント対応 までを セキュリティ顧問契約 で一気通貫提供。情シス 1-2 名体制でも開発組織 30-50 名のセキュリティを回せる体制設計を支援します。

開発者セキュリティ / DevSecOps の専門家伴走をお考えですか？｜中堅企業 100+ 社の支援実績

VSCode 拡張ガバナンス + 認証情報保護 + EDR 運用 + インシデント対応までを月次顧問契約で伴走。サプライチェーン攻撃の影響アセスメント、許可リスト設計、CI/CD 統合シークレットスキャン、取締役会セキュリティ報告まで一気通貫。中堅企業 30-50 名規模に最適化した運用体制を提供します。

セキュリティ顧問契約の無料相談を申し込む

※ 営業電話なし ｜ オンライン対応 ｜ NDA 締結対応可

参考文献

  • VSCode Marketplace 公式 — https://marketplace.visualstudio.com/
  • Microsoft Security Response Center — https://msrc.microsoft.com/
  • npm Security Best Practices — https://docs.npmjs.com/packages-and-modules/securing-your-code
  • gitleaks — https://github.com/gitleaks/gitleaks
  • TruffleHog — https://github.com/trufflesecurity/trufflehog
  • JPCERT/CC 脆弱性情報 — https://www.jpcert.or.jp/
  • IPA「情報セキュリティ 10 大脅威 2026」 — https://www.ipa.go.jp/security/10threats/

関連記事