CyberSecurityAction

サプライチェーン/依存関係 / サイバー攻撃トレンド

北朝鮮Sapphire Sleetが週20億DLのnpmパッケージ「debug」「chalk」を汚染—サプライチェーン攻撃

北朝鮮Sapphire Sleetがnpmのdebugとchalkを汚染。週20億DLのパッケージへの攻撃。Node.js開発者はSCAツール導入とMFA強制化を急げ。

喜村 圭佑（編集責任者）更新 約4分

SHARE

XB!in
北朝鮮Sapphire Sleetが週20億DLのnpmパッケージ「debug」「chalk」を汚染—サプライチェーン攻撃

THREAT GAUGE算出基準

IMPACT（影響範囲）9.5
URGENCY（対応緊急度）7.5
EXPLOIT（悪用の容易さ）7.0

“週20億DL規模の基幹npmパッケージが汚染された事案。国家支援グループの関与が確定し、サプライチェーン攻撃の高度化を示す。”

01 · Overview

ニュースの概要

Amazonは、2025年9月に発生したnpmパッケージ「debug」「chalk」の乗っ取り事案が北朝鮮の国家支援グループ「Sapphire Sleet（別名DEV-0139）」によるものだったと結論付けた。両パッケージは合計で週20億回以上ダウンロードされており、世界最大規模のソフトウェアサプライチェーン攻撃の一つとして位置付けられている。

The Hacker Newsによると、Amazonはこの帰属分析を2026年7月30日に公表した。2025年9月のインシデントでは、攻撃者がnpmの偽ドメインを使ったフィッシング攻撃でパッケージメンテナーのアカウントを乗っ取り、少なくとも18のパッケージに暗号資産ウォレットを狙うスクリプトを注入した。

「debug」はNode.jsデバッグユーティリティとして、「chalk」はターミナル文字列の着色ライブラリとして、ほぼすべてのNode.jsプロジェクトが依存する基幹パッケージである。これらへの悪意あるコードの注入は、ビルドパイプラインを経由して下流の無数のアプリケーションに感染をもたらすリスクがあった。

北朝鮮はこれまでも多くの暗号資産関連のサイバー攻撃を行ってきており、今回のnpmサプライチェーン攻撃はその手口の高度化を示している。国内のNode.js開発者および依存関係管理担当者は、npmパッケージの整合性検証とSCA（ソフトウェアコンポジション解析）ツールの導入を強く推奨する。

Amazonの2026-07-30帰属発表報告（The Hacker News要約・URLのみ使用）を基に作成。当該パッケージはすでに修正済みだが、過去インストール環境での被害確認が推奨される。

02 · Analysis

詳細な原因解説

本事案の起点は脆弱性ではなく、パッケージメンテナーのアカウント乗っ取りである。攻撃者はnpmの偽ドメインを用いたフィッシングでメンテナーの認証情報を窃取し、正規の公開権限を使って少なくとも18のパッケージに暗号資産ウォレットを狙うスクリプトを注入した。

被害が大規模化した構造的な要因は、汚染された「debug」「chalk」が他の無数のパッケージから依存される基幹ライブラリであった点にある。両者は合計で週20億回以上ダウンロードされており、直接インストールしていないプロジェクトも推移的依存として取り込む。汚染は一度の公開でビルドパイプラインを通じて下流へ自動的に伝播する。

npmエコシステムでは個人メンテナーが極めて広く使われるパッケージの公開権限を単独で保持していることが多い。信頼が個人のアカウント管理に集約されており、そのアカウントが破られた時点で技術的な防御が働かない構造になっている。

Amazonによる帰属分析で北朝鮮の国家支援グループ Sapphire Sleet（DEV-0139）の関与が結論付けられた点も重要である。金銭目的の攻撃者だけでなく、国家支援グループがサプライチェーンを標的として選ぶ段階に入っていることを示している。

03 · Action

今からできる主な対策

明日からすぐ

1週間以内

05 · Forecast

今後起こりうる展開と対策

SCAMPER分析：オープンソースサプライチェーン攻撃への対策

Q. 依存パッケージの信頼をメンテナー個人に委ねない仕組みをどう作れるか？

**S(代替)**：外部npmパッケージの代わりに、主要な汎用ライブラリを社内実装またはベンダーが安全性を保証した代替品に置き換えることを検討する。**C(組み合わせ)**：SCAツールとソフトウェアBOM（SBOM）管理を組み合わせ、依存関係の可視化と変更監視を自動化する。**A(適応)**：SLSA（Supply chain Levels for Software Artifacts）フレームワークをビルドパイプラインに適用し、アーティファクトの完全性を保証する。**M(変更)**：npmの公開プロセスに署名（npm provenance）を必須化し、悪意あるコード注入を検知しやすくする。**P(他用途)**：本インシデントを社内の開発者セキュリティ研修の事例として活用する。**E(排除)**：依存関係の数を定期的に棚卸しし、不要なパッケージを削除する（依存関係のデット解消）。**R(逆転)**：攻撃者の視点で自社のnpmサプライチェーンの弱点を洗い出す「ソフトウェアサプライチェーン脅威モデリング」を実施する。

システム思考：オープンソースエコシステムの信頼と脆弱性

Q. 基幹パッケージ1件の汚染は、下流のプロジェクトへどのように連鎖するか？

npmエコシステムは「共有と再利用」という強化ループによって急成長し、debugのように1つのパッケージが何十億もの依存関係を形成する高度に相互接続されたシステムを生み出した。この利便性の裏側には「メンテナー個人への依存」「パッケージ公開プロセスの脆弱性」という集中的なリスクがある。国家支援グループがこの構造を悪用する動機は明確であり、最小コストで最大のインパクトを実現できる。OSSエコシステム全体としてのセキュリティ強化（署名検証の義務化、メンテナー支援プログラム等）がシステムレベルの解決策となる。

npmサプライチェーン攻撃への実務的な備え

まず着手すべきは、汚染期間中に該当バージョンを取り込んでいないかの確認である。package-lock.json や yarn.lock を用いて実際に導入されたバージョンを特定する。lockファイルを用いない運用ではビルドごとに取得内容が変わるため、影響判定そのものができない点に注意が必要である。

該当バージョンの導入が判明した場合は、暗号資産ウォレットの秘密鍵・APIキー・npm認証情報の漏えいを前提として対応する。攻撃コードが暗号資産ウォレットを標的としていたため、開発端末やCI環境に保管された鍵は失効・再発行を検討する。

恒久策としては、SCA（ソフトウェアコンポジション解析）ツールの導入と lockファイルによるバージョン固定を組み合わせる。あわせて `npm ci` を用いた再現可能なビルドと、依存更新時のレビュー手順を定めることで、汚染バージョンが無検証で本番へ流れ込む経路を塞ぐ。

06 · AI Prompt

AI対策プロンプト

私は[組織名]の[業種]企業のソフトウェア開発チームのリードです。北朝鮮Sapphire Sleetによるnpmパッケージのサプライチェーン攻撃を受けて、自社のNode.jsプロジェクトのリスクを評価してください。現状：プロジェクト数[N]個、npmパッケージ総数（dependencies + devDependencies）約[N]個、CI/CD環境[GitHub Actions/Jenkins/GitLab CI等]、SCAツールの導入[あり（ツール名）/なし]、プライベートレジストリ[あり/なし]、npmアカウントMFA[全員適用済み/部分的/未設定]。これを基に①現在のサプライチェーンリスクレベル②即時実施すべきセキュリティ対策（優先順位付き3〜5項目）③中長期的なサプライチェーンセキュリティ改善ロードマップを提示してください。

プロンプトのカスタマイズ

以下を入力すると、上のプロンプトに反映されます。

キーワード

  • Sapphire Sleet
  • npm
  • サプライチェーン攻撃
  • debug
  • chalk

SOURCES · 参考情報源