Shai‑Huludがnpmパッケージを狙う「第二波」─開発端末からCI/CD、そして顧客環境へ伝播するサプライチェーンの現実です

今日の深掘りポイント

• 「第二波」が示すのは偶発ではなく継続的キャンペーンの兆候です。維持されたインフラ・アカウント・TTPの再投入という構図が見え、開発端末→CI/CD→本番の一気通貫での侵入を前提に対策を組み直すべき局面です。
• npmはライフサイクルスクリプトや間接依存の深さゆえ、1つのトロイ化が下流に無検知で広がる設計的リスクを抱えます。依存のピン留めとレジストリ・ミラーで「変化の入口」を狭め、ネットワーク境界で二段目取得を抑止するのが即効策です。
• 現段階の情報からは新奇性と即時性が高い事案に見えます。一方で確証的な技術詳細は限定的です。裏を返せば、検知を回避する低ノイズ手法（小粒パッケージ連鎖や条件分岐実行など）が使われた可能性が高く、行動ベース検知の強化が急務です。
• 反復されるnpmエコシステム狙いは、認証トークン・レジストリ権限・CI機密の「横断的価値」を見越した攻撃者の投資判断を示します。技術対策だけでなく、開発組織の権限設計と公開プロセス統制の再設計が必要です。

はじめに

Shai‑Huludと呼ばれるマルウェアがnpmパッケージを標的にしたサプライチェーン攻撃の第二波を仕掛けているとの報告が出ています。複数のパッケージに悪性コードが混入し、開発者端末からCI/CD、さらには顧客環境にまで影響が波及し得る状況です。npmはフロントエンドだけでなくビルド、DevOpsツール、サーバレス、Electron/デスクトップなど企業ITの広範に浸透しており、1回の汚染でも爆発的な「到達範囲」を生みやすい土壌があります。国内でもJavaScript/TypeScriptの全社横断的な利用が常態化している組織が多く、即応の必要性が高い事案です。

本稿では、公開情報が現時点で限定的であることを前提に、確認されている事実と、一般に観測されるnpm系サプライチェーンTTPをベースにした仮説を明確に区別しつつ、CISO/SOC/Threat Intel観点の実務的な示唆を提示します。

参考：報道は以下に要約されています（原典リンクが付されていない二次情報です。一次資料は追って確認すべきです）。

• Shai-Hulud malware targets numerous npm packages in second wave npm supply chain attack | malware.news

深掘り詳細

事実関係（現時点での確認事項）

• Shai‑Huludと呼ばれるマルウェアによる、npmパッケージを介したサプライチェーン攻撃の「第二波」が報告されています。複数のパッケージに悪性コードが挿入され、開発者・企業への広範な影響が懸念されています。
• 供給元（パッケージ）に手を入れることで、開発端末からビルドパイプライン、さらには顧客環境にまで侵入を拡大し得ることが指摘されています。
• 企業への影響として、機密情報の漏えい、ダウンタイム、開発環境の不安定化などが挙げられています。

上記は公開レポートの二次情報に基づく要旨であり、侵入に使われた具体のTTP（実行トリガ、C2、難読化方式、窃取対象、持続化の方式など）や、被害パッケージの網羅的リストは現時点で確認できる一次資料が限られています。以降はnpmエコシステムで反復的に確認されてきた典型的TTPと、今回「第二波」という文脈から妥当と考えられる仮説を明示して論じます。

編集部インサイト（仮説を含む考察）

• 第二波の意味合い：侵害インフラや資格情報の一部が維持されている、または再取得が容易であることを示唆します。具体的には、メンテナのアカウント乗っ取りや、アクセストークンの長期有効化、レジストリの発行プロセスに対する偵察が継続されている可能性が高いです（仮説です）。
• 低ノイズ・高到達の合わせ技：npmではpostinstall等のライフサイクルスクリプトや、間接依存経由の伝播が成立しやすいです。攻撃者は、人気パッケージのトロイ化に加え、より小規模なユーティリティ群の連鎖や、環境依存の条件分岐（CI上でのみ作動、IP/Geo条件、時間遅延など）で検知面のノイズを抑える戦術を好む傾向があります（仮説です）。
• ねらいは「開発者の鍵束」：npmトークン、GitHub/GitLab/PAT、クラウドの長寿命キー、CI/CDの環境変数やOIDCフェデレーション情報など、開発者環境に集約された横断的クレデンシャルが主戦場です。1度抜かれると横移動の踏み台として極めて価値が高いです。
• リスクの現在地（メトリクスからの示唆）：新規性・即時性が高く、実際的対処のしやすさも一定ある一方、確実な被害像の透明性はまだ十分ではない、というバランスに見えます。運用上は「まだ被害は局所」という期待よりも、「依存グラフを通じた広範な波及」を前提に、ビルド・発行・実行の各段でゲートを増設する意思決定が望ましいです。

脅威シナリオと影響

以下は、一般に観測されるnpmサプライチェーンの攻撃手口を踏まえた仮説シナリオです。MITRE ATT&CKの用語に沿って記述します（IDは参照のための代表例であり、個別事案により変動し得ます）。

• シナリオA：メンテナアカウント乗っ取りによる正規パッケージのトロイ化（仮説）

  • 侵入・準備
    • Valid Accountsの悪用（盗取/フィッシング/再利用）によりパッケージ発行権限を掌握（Valid Accounts）。
    • 署名やブランド信用を装い、Subvert Trust Controls（信頼の迂回）を図る（Subvert Trust Controls）。
  • 実行・C2
    • ライフサイクルスクリプトで第二段を取得・実行（Command and Scripting Interpreter: JavaScript、Ingress Tool Transfer）。
    • 難読化や圧縮で静的検査を回避（Obfuscated/Compressed Files and Information）。
  • 標的
    • 環境変数や設定ファイルからクラウドキー・レジストリトークン・VCSトークンを窃取（Credentials in Files/Credentials from Password Stores）。
    • exfiltration over HTTPSやWebサービスで外送（Exfiltration Over Web Service / Application Layer Protocol: Web）。
  • 影響
    • CI/CDへの横移動、さらなる依存パッケージの汚染、顧客環境での任意コード実行。

• シナリオB：タイポスクワッティング/ブランドジャックで間接依存を汚染（仮説）

  • 侵入
    • 巧妙な命名で依存解決のミスやコピペを誘発（Masquerading）。
  • 実行
    • 低機能のステージャ（例：環境により無効化/条件分岐）で痕跡を最小化。
  • 影響
    • ローカル開発環境を踏み台にCI機密へ到達、ビルド成果物の汚染。

• シナリオC：Dependency Confusion/内部パッケージ名の奪取（仮説）

  • 侵入
    • 内部と同名の公開パッケージを高バージョンで投入し、解決順序を悪用（Supply Chain Compromise: Dependencies）。
  • 影響
    • 内部ネットワークのCIランナーやビルドジョブ上で任意コード実行、内部リポジトリ/アーティファクトの汚染。

影響のまとめ

• 技術的：開発端末の機密流出、CI/CDの権限連鎖の崩壊、ビルドの再現性喪失、ランタイムへのバックドア混入です。
• 事業的：顧客環境への伝播、SLA違反、インシデント通報義務や法規制対応コスト、ブランド毀損です。
• ガバナンス：OSSの受け入れポリシー、SBOM・ビルドアテステーションの要求水準、公開パッケージ維持の責務配分の見直しが必要です。

セキュリティ担当者のアクション

即応（0〜24時間）

• 依存の固定と入口の縮小
  • すべてのビルドでロックファイル（package-lock.json/pnpm-lock.yaml/yarn.lock）を厳格適用し、浮動バージョンの解決を禁止します。
  • CIでnpm/pnpm/yarnのスクリプト自動実行を既定で無効化（例：環境変数でignore-scriptsを有効化）し、例外は厳格な許可リストで管理します。
  • 社内レジストリ/キャッシュ（ミラー）経由に強制リダイレクトし、新規パッケージや未知バージョンの取り込みを隔離キューに入れます。
• ネットワーク遮断と検知の強化
  • 開発・CI環境のEgressを最小権限化し、パッケージ取得先レジストリおよび社内アーティファクト以外の外向き通信をブロックします。
  • EDR/NDRでnode/npm/pnpm/yarnからの以下挙動を高優先度アラートにします（検知ロジックの例）：
    • シェル/PowerShell/コマンドプロンプトの子プロセス生成
    • curl/wget/Invoke-WebRequest等の外部取得
    • 不審なDNS（ダイナミックDNS、短寿命ドメイン）へのTLS接続
• サプライチェーン衛生
  • すべてのnpmトークン/PAT/クラウドキーの棚卸しとスコープ確認、不要トークンの失効を即時実施します。
  • 重要リポジトリの保護ブランチで未知の依存更新をブロックし、依存差分のレビューを必須化します。

短期（24〜72時間）

• 資格情報の強化と回転
  • npm/レジストリアカウントに強制2FA、SSOの適用、パブリッシュ権限の最小化（チーム/ロール分離）を徹底します。
  • CIシークレットのローテーション（クラウドアクセスキー、VCSトークン、署名鍵）。長寿命トークンを短寿命/OIDC連携に置換します。
• 検索と封じ込め
  • リポジトリ全体でpackage.jsonのscripts（preinstall/postinstall/prepare/publish）に不審な追加がないか一括スキャンします。
  • 開発端末とCIランナーで「npmrc/環境変数」からのクレデンシャル持ち出し痕跡、nodeプロセスの外部接続ログを横断検索します。
• ビルドの再現性と隔離
  • リリースブランチのビルドを再現可能なクリーン環境で再実施し、ハッシュ/アテステーション差異を確認します。
  • 本番リリースに入る新規依存を一時凍結し、緊急例外はリスク受容プロセスで承認します。

中期（7〜30日）

• 供給元の検証強化
  • 署名/由来アテステーション（provenance）を発行・検証するゲートをCIに追加し、出自不明のパッケージを拒否します。
  • SBOM（ソフトウェア部品表）を生成し、アーティファクトごとに保存・照合します。リリース前にSBOM差分を自動審査します。
• ガバナンスと監査
  • 社内で公開しているnpmパッケージのメンテナ運用を棚卸し（共同所有、バックアップメンテナ、発行鍵の保管、解任プロセス）。
  • 依存リスクのしきい値（DL数やGitHubスターではなく「メンテナ数」「更新頻度」「スクリプト有無」「脆弱性履歴」を含む）に基づく受入基準を策定します。
• 演習
  • 「依存に後から悪性スクリプトが混入した」想定で、開発端末の封じ込めからCI鍵ローテーション、本番ローリングリカバリまでの卓上/技術演習を実施します。

検知・狩りの観点（行動ベース）

• プロセス
  • parent: node/npm/pnpm/yarn → child: cmd.exe/powershell/bash/sh/zsh/curl/wget の組み合わせを相関検知します。
• ネットワーク
  • ビルドジョブ時間帯におけるレジストリ以外への外向きTLS、短時間に複数の新規ドメインへの接続を高感度で監視します。
• ファイル/設定
  • package.jsonのscriptsや.npmrc、CI定義（GitHub Actions/他）の直近変更に、base64/hex混入や難読化パターンがないか差分監査します。

アトリビューションについて

• 「国家・犯罪双方の関与が疑われる」との指摘がありますが、現時点の公開一次情報は限定的です。技術的な兆候（運用品質、インフラの持続性、目的性）からの推測は可能でも、断定は避けるべきです。防御観点ではアクター名よりもTTPに基づくコントロール設計の優先度が高いです。

最後に

• 第二波という継続性、エコシステムの接着面を突いた攻撃、検知回避に寄与する低ノイズ運用という三点の掛け算で、組織の“デフォルト安全仮定”が破られやすい領域です。開発体験を必要以上に損なわずに「入口の数を減らし、外への回線を細くする」構えを整えることが、短期・中期の最大効率の投資になります。

参考情報

• Shai-Hulud malware targets numerous npm packages in second wave npm supply chain attack | malware.news