TrapDoorサプライチェーン攻撃がnpm、PyPI、Crates.ioを通じて認証情報を盗むマルウェアを拡散
TrapDoorと呼ばれる新たなサプライチェーン攻撃キャンペーンが、npm、PyPI、Crates.ioを標的にして認証情報を盗むマルウェアを配布しています。この攻撃は、384以上のバージョンにわたる34以上の悪意のあるパッケージを含んでおり、開発者の秘密や暗号通貨ウォレット、SSHキー、クラウド認証情報などを狙っています。特に、攻撃者は開発者のワークフローを利用し、AIアシスタントを騙して秘密情報を発見・流出させる手法を用いています。
メトリクス
このニュースのスケール度合い
インパクト
予想外またはユニーク度
脅威に備える準備が必要な期間が時間的にどれだけ近いか
このニュースで行動が起きる/起こすべき度合い
主なポイント
- ✓ TrapDoor攻撃は、npm、PyPI、Crates.ioを通じて認証情報を盗むマルウェアを配布しています。
- ✓ 攻撃者は開発者のワークフローを利用し、AIアシスタントを騙して秘密情報を流出させる手法を採用しています。
社会的影響
- ! この攻撃は、開発者の信頼を損ない、オープンソースエコシステム全体に対する脅威を高める可能性があります。
- ! 特に、AI技術の進展に伴い、攻撃者が新たな手法を用いることで、開発者のワークフローがさらに危険にさらされることが懸念されます。
編集長の意見
解説
TrapDoor: npm・PyPI・Crates.ioを横断するサプライチェーン侵害──開発者秘密からCI/CD・クラウド特権へ連鎖する現実的リスクです
今日の深掘りポイント
- 言語・エコシステム非依存の「インストール時実行」を突く攻撃で、npm・PyPI・Crates.ioの三大レジストリをまたぐ同時多発です。開発端末からCI/CD、クラウドまで一直線に侵害が伸びる設計です。
- 34以上の悪性パッケージ、384以上のバージョンという“細切れ大量投下”で検知の網を潜るやり口です。単一IoCで塞げる類ではない前提で動くべきです。
- 秘密情報の探索と流出にAIアシスタントを「騙して使う」手口が加わりました。IDE/リポジトリに潜むプロンプト汚染が、新たなサプライチェーン面として顕在化しています。
- いま必要なのは「新規依存の凍結」「インストール時スクリプト無効化(少なくともCI)」「社内ミラー経由の取得」「開発端末の秘密情報最小化と短命化トークン化」です。
- 公開情報は増加途上で一次情報の確度はなお評価途中ですが、被害波及ポテンシャルと着手容易性は高く、可逆・低リスクの緊急緩和策を即時に打つ価値が大きい状況です。
はじめに
開発者が毎日実行する「依存の取得・ビルド」に、攻撃者は粘り強く入り込みます。TrapDoorと呼ばれる今回のキャンペーンは、npm、PyPI、Crates.ioを同時に狙い、インストールやビルドのフックを悪用して秘密情報を刈り取り、CI/CDやクラウド権限に達する“連鎖侵害”を現実にしています。新規性は、AIアシスタントを騙して秘密探索・流出を補助させる点です。開発ワークフローに統合されたAIが新しい攻撃面になる、という予感はこの1年で共有されつつありましたが、実運用のサプライチェーン文脈で可視化したのは無視できないシグナルです。
オープンソース依存は各国の公共・基幹領域にも深く根差します。供給網の韌性は、もはやセキュリティ部門だけの論点ではなく、国家安全保障まで射程に入る経営アジェンダです。今日のPickUpでは、事実関係と、CISO・SOCが明日から動ける現実的な緩和策を掘り下げます。
深掘り詳細
事実関係(確認できていること)
- TrapDoorは、npm・PyPI・Crates.ioで配布される悪意あるパッケージを媒介に、開発者の秘密(暗号通貨ウォレット、SSHキー、クラウド認証情報など)の窃取を狙います。
- 少なくとも34以上の悪性パッケージが384以上のバージョンにまたがって観測され、広域・分散的に拡散しています。
- 悪性コードは、インポート時に実行されるリモートJavaScriptペイロードや、ビルドスクリプト(npmのpre/postinstall、PyPIのビルドバックエンド/setup、Rustのbuild.rsなど)を介して走る形で投下されます。
- 攻撃者は開発者のワークフローを踏まえ、AIアシスタントを騙して秘密情報の探索・流出を助長する手法をとっています。
出典: The Hacker Newsの記事 に基づく整理です。
編集部のインサイト(なぜ今、なぜ効くのか)
- 多言語横断の「ビルド/インストール時実行」は、歴史的に設計上の利便性として残り続けた“正当な実装経路”です。これを正規のパッケージに偽装して踏み台化する発想は新しくありませんが、今回のポイントは三大レジストリを同時に突く“非対称化”です。運用側の検知・封じ込めを、技術・組織・ツールのサイロごとに分断させる効果があります。
- 34×384という「小粒・多数・頻繁更新」は、ハッシュや単発のパッケージ名ブロックでは追いつかない規模感です。検知をバージョン境界に依存させない、挙動ベース(インストール中のネットワーク外向き通信、秘密ディレクトリ走査など)への寄せ替えが要件化します。
- AIアシスタントの悪用は、防御側の「人手の置き換え」を逆手にとる動きです。リポジトリ内のREADMEやコメントに仕掛けたプロンプト汚染で、AIに秘密捜索を提案・実行させる、といった経路が懸念されます。生成AIの利便と安全のトレードオフを、IDE拡張・ネットワークポリシー・権限境界で再設計するタイミングに来ています。
- 現時点で確認情報の公開は限定的で、個別のIoCや侵害面の完全像はこれから詰まる可能性があります。それでも、「開発端末→CI/CD→クラウド特権」という連鎖は、過去事例と攻撃設計の合理性から見てもっともらしく、緊急緩和を後回しにする理由は薄いです。可逆的コントロールから順に速く打つ、が最適解です。
脅威シナリオと影響
以下は公開情報と一般的な攻撃設計に基づく仮説です。実環境への当て込みは自組織のスタックに即して再検証してください。
-
シナリオ1:開発端末からの連鎖侵害
- 入口: 悪性パッケージをインストール(npm/pip/cargo)。インストール時スクリプトが実行。
- MITRE ATT&CK: Initial Access - Supply Chain Compromise(T1195, 仮説)、Execution - Command and Scripting Interpreter(T1059, 言語別サブ技術含む, 仮説)
- 資格情報窃取: ~/.ssh、クラウドCLI(~/.aws/credentials, gcloud, azure)、ブラウザストア等を探索・収集。
- Credential Access - Unsecured Credentials: Private Keys(T1552.004, 仮説)、Credentials in Files(T1552.001, 仮説)、Credentials from Password Stores(T1555, 仮説)
- 送出: HTTPSベースのC2/ストレージへ流出。
- Exfiltration - Exfiltration Over C2 Channel(T1041, 仮説)または Exfiltration Over Web Services(T1567, 仮説)
- 横展開: 窃取したSSH鍵/PATでGit/CIに侵入、シークレット参照・コード改ざん・パイプライン設定変更。
- Lateral Movement - Remote Services(T1021, 仮説)、Defense Evasion - Masquerading(T1036, 仮説)
- 入口: 悪性パッケージをインストール(npm/pip/cargo)。インストール時スクリプトが実行。
-
シナリオ2:CI/CDハイジャックからクラウド権限へ
- 入口: 開発者のPATでリポジトリ/パイプラインにアクセス、ビルドジョブに悪性ステップを追加。
- Persistence - Modify Existing Service(T1078/設定変更系に相当, 仮説)
- クラウド到達: CIに保存された長寿命クラウドキーや環境変数を搾取、管理プレーン操作。
- Credential Access(T1552系, 仮説)、Discovery(T1083, 仮説)
- 影響: アーティファクトの後続ユーザへ拡散、顧客環境までサプライチェーン経由で波及。
- Impact/Collection/Exfiltrationの連鎖(仮説)
- 入口: 開発者のPATでリポジトリ/パイプラインにアクセス、ビルドジョブに悪性ステップを追加。
-
シナリオ3:AIアシスタントを経由した秘密流出(プロンプト汚染)
- 入口: 悪性パッケージのREADME/コメント/サンプルコードにAI向け指示を埋め込み、IDE統合AIが指示に従い秘密探索・貼り付け等を提案。
- 送出: AIプラグインが外部サービスに内容を送信、あるいは開発者の操作で「共有」される。
- 備考: これは生成AI特有の脅威で、従来のATT&CKだけでは表現しきれない面があります。少なくともUser Execution(T1204, 仮説)的な要素を含み、IDE拡張の権限設計が重要です。
組織的影響は、機密コード・鍵・顧客データの露出だけでなく、アーティファクト供給者としての信頼毀損、監査・規制対応コスト、インシデントコミュニケーション負債に及びます。特に開発者依存が大きい事業では、復旧のボトルネックは“技術的封じ込め”より“権限・鍵の全面ローテーションとSaaS連携の整合性回復”に現れがちです。
セキュリティ担当者のアクション
-
まず72時間(可逆・即効の緊急緩和)
- 新規依存の追加・更新を一時凍結し、例外は二人承認+検品経路に限定します。
- CIではインストール時スクリプトを無効化します。
- 例: npmは環境変数 NPM_CONFIG_IGNORE_SCRIPTS=true を設定し npm ci を使用します。
- 例: Pythonは pip install --only-binary :all: --require-hashes を徹底し、sdist由来のビルド実行を避けます。
- 例: Rustは cargo build --locked を基本にし、可能なら cargo vendor を使い社内ミラーから取得します。
- 開発端末・CIでの“ビルド時の外向き通信”を監視・遮断します。npm/pip/cargo/rustc/python/node等の子プロセスが curl/wget/PowerShell/Invoke-WebRequest 等を起動、または未知ドメインへHTTPS接続する挙動を検知・ブロックします。
- 秘密情報の即時棚卸しとローテーション計画を開始します。~/.ssh、クラウドCLI資格情報、Git PAT(特に長寿命・広権限)を優先し、短命化トークンと端末側保存の廃止へシフトします。
- SOCハントクエリ(例)
- 観測対象: プロセス=python|node|npm|pip|cargo|rustc の子が外部へ接続、かつ1時間以内に ~/.ssh, ~/.aws/credentials, gcloud/azure設定ディレクトリを読み取るファイルI/Oを伴う事象。
- 観測対象: npm install/pip install/cargo build 実行コンテキストで新規作成されたzip/tar(秘密収集のアーカイブ化の疑い)。
-
1〜2週間(構造的な摩擦の設計)
- 社内アーティファクトミラーを前提とした取得経路に切り替え、外部レジストリへの直接到達を原則禁止します(社内での検品・署名・復元検証を通すゲートを設置します)。
- 依存の“人・組織起点リスク”を評価し、メンテナ未検証・メンテナ移管直後・新規公開から日が浅いパッケージの導入にゲートを設けます。
- SCA/コンフィグ監査を、ランタイムの挙動監視(インストール時スクリプトのネットワーク通信用途、秘密ディレクトリ参照)と組み合わせ、署名やハッシュだけに依存しない多層検知にします。
- CI/CDのシークレットを全面棚卸しし、長寿命キーは廃止、OIDC等のフェデレーションによる短命化に寄せます。クラウド側は権限境界(最小権限・条件付き境界:ソースIP/デバイス態様)を再構成します。
- AIアシスタントのガバナンスを整備します。
- IDE拡張の権限を最小化し、自動ファイルスキャンや自動送信をオフにします。
- プラグインの外向き通信をプロキシで制御し、社内許可先のみに限定します。
- リポジトリのREADME/コメントに対するプロンプト汚染検査を導入し、機密に触れる提案はレビュー必須とします。
-
30〜90日(供給網の韌性を制度化)
- 依存管理の方針を「ハッシュ固定」「ロックファイルの厳密運用」「再現可能ビルドの担保」に更新し、ビルド成果物への署名検証をパイプラインに標準実装します。
- “ビルド時のネットワーク禁止”を原則とし、例外は検証済みミラーへのGETのみ、といった明文化ルールを設定します。
- セキュリティ運用KPIに「新規依存の検品リードタイム」「インストール時スクリプト実行率」「長寿命秘密の撲滅率」を入れ、継続的に可視化します。
- インシデント対応手順に「開発者資格情報の一括ローテーション」「Git/CIの権限棚卸し自動化」「顧客・パートナーへのコミュニケーション雛形」を組み込みます。
-
現場の小さなコツ
- Pythonは“wheel優先・sdist回避”でリスクが一段下がります。requirements.txtで --hash を必須化すると、横展開の抑止に効きます。
- npmは“npm ci + ignore-scripts(少なくともCI)”をデフォルトにします。postinstall依存のビルドが必要なパッケージは、社内ビルド済みアーティファクトに置換します。
- Rustは build.rs がネットワークやシェルを叩くケースを弾く簡易Lint(静的に std::process::Command/reqwest の利用検出等)でも初期抑止に有効です。
-
リスクコミュニケーション
- 今回の件は“高い即時性と実装容易性”が目立つ一方、公開根拠の広がりは途上です。事実関係の確度が増すまでは、可逆・低摩擦の対策から速やかに着手し、IoC確定を待つブロックは段階適用に留める、といったバランスが現実的です。
参考情報
- The Hacker News: TrapDoor supply chain attack spreads credential-stealing malware via npm, PyPI, and Crates.io(2026-05-25)
https://thehackernews.com/2026/05/trapdoor-supply-chain-attack-spreads.html
編集後記: サプライチェーンの「面」は年々広がりますが、対策の肝は案外変わりません。ビルド時の実行を減らす、秘密を短命化する、入出庫を自前で検品する。AIが加わったからこそ、原則に立ち返るタイミングでもあります。明日の障害を今日の摩擦に変えられるか——そこがCISOとSOCの腕の見せどころです。
背景情報
- i TrapDoor攻撃は、npm、PyPI、Crates.ioのエコシステムを利用して、開発者を狙った認証情報を盗むマルウェアを配布する新たなサプライチェーン攻撃です。この攻撃は、悪意のあるパッケージを通じて、開発者の秘密や暗号通貨ウォレット、SSHキーなどを狙っています。
- i 攻撃者は、パッケージのインポート時に実行されるリモートJavaScriptペイロードや、悪意のあるビルドスクリプトを使用して、開発者の環境に侵入します。特に、AIアシスタントを騙す手法が注目されており、これにより秘密情報の発見と流出が可能となります。