2025年秋、主要なNPMサプライチェーン攻撃により、現代のソフトウェア依存関係がいかに脆弱になり得るかが明らかになった—特に暗号通貨ユーザーや開発者にとっては重要な問題だ。
この攻撃はJavaScriptエコシステムを標的とし、何百万ものウェブおよびソフトウェアプロジェクトがサードパーティのパッケージに依存している。いくつかの悪意のあるパッケージは、暗号通貨取引に干渉するように設計されており、ブラウザベースのフローでウォレットアドレスを監視または置き換えることも含まれていた。後のワームのようなキャンペーン、「シャイ・フルード」として知られるものは、開発者やCI/CDの資格情報を盗み、侵害されたパッケージ管理者アカウントを通じて拡散した。
この直後の事件は過ぎ去ったが、リスクは依然として存在する。AI支援のコーディングや自動化された脆弱性発見の加速により、攻撃者はソフトウェアサプライチェーンの弱点を従来よりも早くスキャン、武器化、悪用できるようになっている。
すべての暗号ウォレットが影響を受けたわけではない。特にビットコインに焦点を当てたウォレットのいくつか、例えばNunchukやBlockstream（ジェイドハードウェアウォレット）は、この特定のNPM攻撃に対してアプリが曝露されていないと公に声明を出している。
一つの教訓は、セキュリティと機能の幅の長年にわたるトレードオフがますます重要になる可能性があるということだ。セキュリティ強化を最優先し、多くの資産や統合、ソフトウェア依存関係をサポートすることを控えるウォレットは、一般的に複雑さが低く、攻撃面も狭い。
AIの進展により、ソフトウェア開発と脆弱性発見の両面で加速が続く中、複雑さを最小限に抑えることは、ユーザー、開発者、サービス提供者にとって最も効果的なセキュリティ戦略の一つとなり得る。
何が起こったのか？
2025年秋、JavaScriptエコシステムとそのパッケージレジストリNPMに対して一連のサプライチェーン侵害が発生した。攻撃者は信頼されたパッケージ管理者アカウントにアクセスし、何千ものアプリケーションで使用されているソフトウェアライブラリに悪意のある更新を公開した。
これらの侵害されたパッケージは、インストールされると、資格情報の窃盗や開発者環境の侵害、暗号通貨関連の取引の操作など、さまざまな悪意のある行動を実行できた。
これらの事件が特に懸念される理由は次の通りだ：
- 人気のNPMパッケージは、週に何百万回もダウンロードされることが多い。
- 現代のアプリケーションは、何百または何千ものサードパーティライブラリに依存していることが多い。
- 信頼された依存関係の一つが侵害されると、大規模なソフトウェアエコシステム内に急速に拡散する可能性がある。
- 一部の悪意のあるパッケージは、ウォレットアドレスや取引データの改ざんを試み、暗号通貨ユーザーを標的とした。
教訓はシンプルだ：複雑さにはセキュリティコストが伴う。余分な依存関係、統合、機能は、それを信頼し維持し防御しなければならないコードの一片を増やすだけだ。
攻撃者が自動化やAI支援ツールをますます利用する中、システムをシンプルに保つことは、ウォレット提供者や暗号サービスにとって最も強力なセキュリティ戦略の一つになる可能性が高い。
なぜJavaScriptエコシステムはこれほど魅力的な標的なのか？
現代のJavaScript開発は、NPMに大きく依存している。NPMは、多くのWebアプリケーション、開発者ツール、ソフトウェアプロジェクトで使用されているパッケージレジストリだ。
単一のアプリケーションは依存できる：
- 何百もの直接パッケージ
- 何千もの間接依存関係
多くの開発者は、自分のアプリケーションが最終的にどんなライブラリを読み込むのか全てを把握していない。弱いエンジニアリング環境では、何かが壊れるまで気にしないこともある。
これにより三つの主要なリスクが生じる：
- 手動レビューが不可能なほど多くの依存関係：依存ツリーは現実的な行ごとのレビューには大きすぎることが多い。
- 評判による信頼：人気のパッケージは、「皆が使っているから安全」と仮定されがちだ。
- 自動ビルドパイプライン：依存関係の更新が固定されていなかったり、レビューや監視が行われていなければ、CI/CDシステムは侵害されたパッケージを素早く取り込むことができる。
これがNPMサプライチェーン攻撃が非常に危険な理由だ。攻撃者はすべてのターゲットに直接侵入する必要はない。
信頼された単一のパッケージを侵害するだけで、多くの下流プロジェクトに到達できる。
なぜこれは非常に危険な脅威なのか？
ユーザーは正しいことをしていても曝露されることがある
ほとんどのサイバー攻撃は、被害者がミスを犯すことを前提としている。悪意のあるリンクをクリックする。感染したソフトウェアをインストールする。偽のウェブサイトを訪れる。
サプライチェーン攻撃は異なる。
ユーザーはすべての推奨されるセキュリティ対策を講じていても、アプリケーション自体が知らず知らずのうちに信頼されたソースから侵害されたコードを読み込んでしまうため、曝露される可能性がある。
信頼が攻撃のベクトルになる
従来のセキュリティモデルは、公式ソースからダウンロードされたソフトウェアは、他の場所から入手したものよりも信頼できると仮定している。
サプライチェーン攻撃は、その仮定を悪用する。
悪意のあるコードは、正当なアップデートメカニズム、信頼されたパッケージリポジトリ、そして開発者が日常的に使用しているソフトウェアコンポーネントを通じて到達する。
検出は困難
侵害されたパッケージはしばしば正当なものに見える：
- 公式リポジトリからダウンロードされる。
- 信頼された管理者によって署名または公開されている場合がある。
- 悪意のあるコードは頻繁に隠されている、暗号化されている、または難読化されている。
- 影響を受けたソフトウェアは正常に動作し続けることもある。
その結果、侵害は長期間見逃され、大量のユーザーやシステムに到達する可能性がある。
影響は単一のアプリケーションを超える
広く使われている依存関係が侵害されると、その影響は元のターゲットをはるかに超えて拡散することがある。
一つの悪意のあるパッケージは最終的に次のようなものに到達する可能性がある：
- ウェブサイト
- ブラウザ拡張機能
- ウォレットアプリケーション
- 開発者ツール
- 内部業務システム
- バックエンドサービスやAPI
これがサプライチェーン攻撃がシステムリスクとなる理由であり、孤立したセキュリティインシデントではない理由だ。
侵害されたパッケージは暗号ユーザーにどのような影響を与えるか？
- アプリケーションが侵害された依存関係を読み込む
信頼されたNPMパッケージが悪意のある更新を受け取り、アプリケーションのソフトウェアスタックの一部となる。
- 悪意のあるコードが信頼されたアプリ内で実行される
コードはアプリ自体によって読み込まれるため、他のソフトウェアと同じ権限と信頼を継承する。
- 取引データが監視または改ざんされる
一部の悪意のあるパッケージは、暗号通貨の取引を監視し、特定の状況下でウォレットアドレスを攻撃者がコントロールするアドレスに置き換えようとする設計になっていた。
- ユーザーが取引を承認する
操作が気付かれずに取引が承認されると、資金は意図した受取人ではなく攻撃者のコントロール下にあるアドレスに送られる可能性がある。
- 信頼できる画面での検証が攻撃を破る
ハードウェアウォレットの画面で宛先アドレスを検証するユーザーは、取引を承認する前に操作を検出する機会を得る。
ハードウェアウォレットの検証が依然として重要な理由
この事件が暗号コミュニティで注目された一つの理由は、悪意のあるパッケージの中には、コンピュータ画面に表示される取引データを改ざんしようとするものもあったからだ。
これこそ、ハードウェアウォレットが設計された目的と一致している脅威の種類だ。
ハードウェアウォレットは独立した検証画面を提供する
- 秘密鍵はデバイス内に留まる。
- 取引にはハードウェアウォレット自体での確認が必要。
- 宛先アドレスは別の信頼できる画面で検証できる。
コンピュータやブラウザ、ウォレットアプリが侵害された場合でも、ハードウェアウォレットは署名される取引の詳細を実際に表示し続けることができる。
残るリスクは人間の行動
ハードウェアウォレットは、ユーザーが検証する内容だけを保護できる。デバイスが攻撃者コントロールのアドレスを表示し、それを確認せずに承認した場合、保護メカニズムは事実上バイパスされてしまう。
ソフトウェアウォレットの方がより多くのリスクにさらされる理由
ソフトウェアウォレットは、通常、ブラウザやOS、アプリケーションコードと同じインターネット接続されたデバイス上で動作し、侵害された依存関係の影響を受けやすい。
多くの場合、ウォレットのインターフェースと取引詳細を構築または表示するコードは、同じ信頼境界を共有している。
これはすべてのソフトウェアウォレットが自動的に安全であることを意味しない。ただし、独立した検証画面がなければ、取引の改ざんをユーザーが検出するのは難しくなる。
特に、ブラウザベースのウォレットやWeb3アプリ、複雑なスマートコントラクトのやり取りでは、ユーザーはしばしばアプリのインターフェースが示す内容を信頼しなければならない。
サプライチェーン攻撃のリスクを減らす方法
エンドユーザーがサプライチェーン攻撃を完全に避けることはできない場合もある。しかし、ユーザーは、AI支援の脅威アクターが未曾有の速度で脆弱性を発見、武器化、悪用できる時代において、すべてのインターネット接続されたデバイスやウォレットインターフェースが最終的に曝露されると仮定すれば、被害を限定できる。
ホットウォレットは使い捨てとみなす
インターネットに接続されたデバイスは、潜在的に侵害されているとみなすべきだ。
それは、モバイルウォレットやブラウザ拡張、デスクトップアプリを使わないという意味ではない。これらは便利なツールだが、長期的な資産保管場所としてではなく、日常の取引に利用すべきだ。
利便性とセキュリティを分離する
最も効果的な防御策は、取引承認をインターネット接続されたデバイスから分離することだ。
Blockstream JadeやColdcardのようなハードウェアウォレットは、この原則に基づいて設計されている。たとえコンピュータやブラウザ、ウォレットアプリが侵害されても、ユーザーは独立したデバイスで取引内容を検証できる。
署名内容を確認しよう
最終的には、セキュリティデバイスはユーザーの注意を置き換えることはできない。
ハードウェアウォレットは、ユーザーが実際に検証した内容だけを保護できる。攻撃者コントロールのアドレスがデバイス画面に表示され、それを確認せずに承認した場合、保護メカニズムは事実上バイパスされてしまう。
取引内容を慎重に確認しよう
取引操作のマルウェアの中で最も危険な側面の一つは、実際に起こっていることを変えずに、あなたのコンピュータ画面に表示される内容を改ざんできることだ。
取引を承認する前に：
- ウォレット画面のアドレスを確認： ハードウェアウォレットを使っている場合は、常にデバイスに表示される宛先アドレスと送金先のアドレスを比較しよう。
- 最初と最後の文字だけでなく確認： 高度な攻撃者は、意図した宛先に似せたアドレスを生成することもある。最初、中間、最後の部分を確認しよう。目視だけでは不十分なこともある。
- 大きな送金には別の検証チャネルを利用： 重要な金額の場合、受取人と別の通信手段で宛先アドレスを確認してから送金しよう。
数秒の検証時間をかけるだけで、取り返しのつかないミスを防げることもある。
自己管理とマルチシグの支援によるハンズオン管理
自己管理は、リスクを理解し、「プルーフ・オブ・ワーク」に時間を投資できる人にとって非常に効果的だ。最も高い自己主権の解決策であり、適切に管理できるユーザーには推奨される方法だ。
ただし、すべての人が時間や自信、サイバーセキュリティのスキルを持っているわけではない。特に資産が人生の貯蓄の重要な部分を占める場合はなおさらだ。
避けられるミスは避けるべきだし、避けなければならない。
大きな個人資産や家族の資金、ビジネストレジャリーには、複数署名の設定が有効だ。複数のデバイスや場所、人物に承認権限を分散させることで、単一障害点を排除できる。多くの経験豊富なユーザーは自分でシステムを構築・管理しているが、他の人は設定や運用のサポートを望むこともある。
大きな資産を持つユーザーや、経験豊富なガイダンスを求める場合、私たちの社内コンサルティングチームが、堅牢な設定を構築し、一般的な落とし穴を避けるお手伝いをします。
当社はこの業界で10年以上活動しており、その間に「ピッグブッチャリング」投資詐欺、国家支援の脅威アクター、誤ったバックアップ、フィッシング攻撃、鍵の紛失、デバイスの侵害、そして高度化するサイバー犯罪をすべて見てきました。その生存実績は、ひとつの証明だと考えています。
現在も、デジタル資産の盗難や危険にさらされているケースに対し、専門のサイバー脅威・介入パートナーと密接に連携しながら、業界の新たな攻撃パターンを監視し続けている。
ビットコインの性質上、許可不要で構築できるが、資産の一部や家族の資金、ビジネストレジャリーには、支援付きマルチシグ設定が適している場合もある。
目的は、避けられるリスクを減らし、実用的な範囲で単一障害点を排除することだ。
一つの不用意なミス、一台の故障、または一台の侵害されたコンピュータが、世代を超えた資産へのアクセス喪失の原因となるべきではない。
結論
NPMの事件はやがて記憶から薄れていくだろう。しかし、その教訓はそう簡単には消えない。
何十年も前から、ユーザーは怪しいダウンロードや偽サイト、明らかな詐欺を避けるよう教えられてきた。サプライチェーン攻撃は、その明白なリスクを回避しながらも、ソフトウェアが正当であること、ソースが公式であること、開発者自身も被害者である可能性があることを利用しているため、非常に危険だ。
ますます複雑化するソフトウェアの世界では、セキュリティはもはや悪意のある者を避けるだけではなく、不必要な信頼を減らし、複雑さを最小限に抑え、重要な行動を独立して検証することにある。
ビットコインでは、「信じるな、確認せよ」は、ソフトウェアにも適用される原則だ。
