GitHubのCISO（最高情報セキュリティ責任者）Alexis Walesは2026年5月21日、同社内部リポジトリ約3,800件が不正アクセスを受けた経緯を公式ブログで明らかにした。侵害の起点はVisual Studio Code（VS Code）Marketplaceに混入した悪意ある「Nx Console」拡張機能であり、TanStack npmサプライチェーン攻撃の一環として仕込まれたものだった。

事件の全容：「18分間の感染窓口」が引き起こした大規模侵害

Nx Consoleは、モノレポ管理ツール「Nx」の公式VS Code拡張機能だ。攻撃者はバージョン18.95.0に悪意あるペイロードを埋め込み、VS Code Marketplaceに公開した。この改ざん版が入手可能だった時間はわずか18分（OpenVSXでは36分）にすぎなかったが、GitHubの従業員がインストールしてしまった。

埋め込まれたペイロードは、以下のプラットフォームの認証情報・シークレットを窃取するよう設計されていた：

  • npm / GitHub CLI
  • AWS / GCP / Docker
  • Kubernetes

窃取されたGitHub CLIの認証情報を使って攻撃者はリポジトリに「コントリビューター」として侵入し、内部ワークフローを実行できる状態になった。

TeamPCP：連鎖するサプライチェーン攻撃の主犯グループ

この攻撃を主導したのはTeamPCPと呼ばれるサイバー犯罪グループとされている。同グループはTanStack・Mistral AIのnpmパッケージを起点に侵害を開始し、CI/CD認証情報を悪用してUiPath・Guardrails AI・OpenSearchにも攻撃を拡大した。

さらに過去の攻撃との関連も報告されている：

  • PyPI・npm・GitHub・Dockerを狙ったサプライチェーン攻撃
  • OpenAIの従業員2名も被害を受けた「Mini Shai-Hulud」キャンペーン

TeamPCPは「Breached」フォーラム上でGitHubのソースコードと「約4,000件のプライベートリポジトリ」へのアクセスを主張し、少なくとも5万ドルを要求している。

GitHubの対応状況

GitHubは侵害確認後、以下を実施した：

  • 侵害されたデバイスを隔離・保護
  • 高影響度の認証情報を優先的にローテーション（月曜〜火曜にかけて実施）
  • ログ解析とインフラ監視を継続

現時点では、影響を受けたリポジトリ外の顧客データが流出した証拠は見つかっていないとGitHubは説明している。

VS Codeマーケットプレイスの構造的問題：繰り返される歴史

今回の事件は孤立した出来事ではない。VS Code Marketplaceでは過去にも深刻な事案が繰り返されている：

  • 2025年: 900万インストールを超える拡張機能がXMRigクリプトマイナーを仕込んで削除される
  • WhiteCobraグループが仮想通貨窃取を狙った24本の拡張機能を一括投稿
  • 2026年1月: AI系コーディングアシスタントを装った2本（合計150万インストール）が開発者データを外部サーバーへ送信

Marketplaceは膨大な数の拡張機能を擁しており、その審査体制の限界は無視できない段階に来ている。

実務への影響——日本の開発現場が今すぐやるべきこと

開発者・エンジニア向け即時対応

拡張機能の運用見直し：

  • VS Code拡張機能の自動更新を無効化し、更新前にリリースノートを確認する習慣をつける
  • 組織管理のデバイスでは、許可リスト（Allowlist）方式で拡張機能インストールを制限する

認証情報の管理強化：

  • GitHub CLI・AWS CLI・Kubeconfigなどの認証情報を定期的にローテーションする
  • OIDC（OpenID Connect）フェデレーション認証を採用し、静的なCI/CDシークレットを排除する。GitHub ActionsであればOIDCによるAWS/GCP連携が既に標準化されている
  • permissionsフィールドでジョブごとに最小権限を明示する

監視・検知の整備：

  • リポジトリへの異常なコントリビューター追加やワークフロー実行をアラートとして検知する
  • シークレットスキャナー（GitHub Secret Scanning、truffleHogなど）をパイプラインに組み込む

筆者の見解

今回の事件が示す本質は「開発ツールそのものが攻撃面（Attack Surface）になった」という事実だ。VS Code拡張機能は開発者のローカル環境で動作し、機密性の高い認証情報に直接アクセスできる。それを「信頼できるもの」として何の確認もなくインストールするのは、構造的なリスクを放置しているのと同じだ。

特に気になるのは、CI/CDの認証情報が静的な状態で長期間存在し続けている現場が多い点だ。今回の攻撃が成功した一因はまさにここにある。GitHubが「侵害後に緊急ローテーションした」と報告しているが、本来それは平時に仕組みとして実装されているべきものだ。

Just-In-Time（JIT）アクセスとOIDCフェデレーション認証の組み合わせは、静的シークレットの長期保存リスクを根本から断つ手段として実績がある。Non-Human Identities（NHI）の管理を適切に設計できれば、業務の自動化を進めながらセキュリティも担保できる。「やった方が良い」ではなく、いまや「やらなければ危ない」フェーズに入っている。

開発エコシステムへのサプライチェーン攻撃は今後も続くだろう。「インストールしたものは安全だ」という前提を捨て、ツールチェーン全体にゼロトラストの考え方を適用する時代が来ている。正直なところ、この手の事件が繰り返されるたびに「なぜ業界全体として対策が追いつかないのか」と感じる。技術的な手段はすでにある。あとは運用に落とし込む意志と体制の問題だ。

出典: この記事は GitHub links repo breach to TanStack npm supply-chain attack の内容をもとに、筆者の見解を加えて独自に執筆したものです。