2025年10月13日、 新しいトークンのライフタイム制限(90日間の最大、7日間のデフォルト)、古代の古典トークンを置き換える義務付けられた粒子アクセスのトークン、およびTOTP 2FA制限はWebAuthnに有利です。 npm認証の重要なセキュリティ変更が有効になりました。 これらの変更は、AWS、Google Cloud、GitHub による最新のセキュリティ実践と一致していますが、セキュリティコミュニティが十分に大きな声で尋ねていない不快な質問があります:これらの攻撃は、私たちが実際に目撃した攻撃を防ぐことができますか? 答えはノー。 本物の攻撃ベクター 2025年9月8日、npmの発表の数日前に、最近の歴史における最大のnpmサプライチェーン事件の1つは、デバッグやシャルクなどの一般的な図書館と16の他のユーティリティがハイジャックされ、暗号通貨の財布をターゲットとする悪意のあるコードでnpmに押しつけられたときに起こった。 どうして起こったのか? メンテナントは、彼らのnpmアカウントが偽ドメイン(npmjs.help)から送信された非常に説得力のある2FAリセットメールを通じてフィッシングされたことを確認しました。 攻撃者は長期にわたるトークンを盗む必要はありませんでした。 彼らは弱いトークンの許可を悪用しませんでした。 彼らは単に説得力のある電子メールを送信し、ユーザ名、パスワード、およびライブTOTPコードを収集し、これらを完全にアカウントを奪い、悪意のあるバージョンを公開するために使用しました。 悪意のあるバージョンはわずか2時間生存していたが、悪意のあるバージョンがnpmで利用可能だった短い2時間の期間中、悪意のあるコードは10のクラウド環境のうち1に成功した。 XZ Utilsのバックドアには、Jia Tanという貢献者としての信頼性を構築するために約2〜3年を費やした脅威俳優が参加し、徐々にソーシャルエンジニアリングを通じてメンテナンス責任を獲得しました。 一度信頼されると、Jia Tanは2024年2月と3月にバックドアコードを導入し、XZ Utilsのビルディングプロセスをターゲットにし、バックドアコードを主要なLinuxディストリビューションに押し込むことを目的とした。 攻撃には盗まれたトークンも含まれていませんでした。 npm は実際に何を修正しているのか 明確に言えば、npm の変更は無価値ではありません。長期的なトークンはサプライチェーン攻撃の主なベクターであり、短期的なライフタイムは暴露のウィンドウを制限します。TOTP から WebAuthn ベースの認証への移行は本当に良い - パスキーは一度のコードよりもフィッシュしにくい。 しかし、これらは、基本的なセキュリティ変革ではなく、衛生の改善である。 攻撃者はCI/CDシステムからトークンを盗む トークンは書く許可を持っています。 メンテナンスは何ヶ月も気付かない。 攻撃者は、その特定のトークンを悪意のあるパッケージを公開するために使用します。 これは、病気よりも症状(トークン曝露)を扱っています(コードレビューの欠如、不十分な起源、メンテナンスアカウントのセキュリティ、そして基本的に、悪意のあるコードが公開される容易さ)。 The Hard Problems NPM Is Not Solving(NPMの難しい問題は解決しない) 2025 年 9 月の npm 攻撃は、コアの脆弱性を示しています: 1 つの妥協が数時間で生態系を覆い、一つのターゲットフィッシング攻撃がオープンソースのサプライチェーン全体に広がる可能性を示しています。 しかし、npmのセキュリティ修正は対応しません: アカウントのフィッシングによるアカウント取得:9月の攻撃は、メンテナントが2FAを有効にしたにもかかわらず成功しました. 説得力のある偽ドメイン(npmjs.help 代わりに npmjs.com)は十分でした. 攻撃者がアカウント自体をコントロールする場合、より短いトークン寿命は無関係です。 ソーシャルエンジニアリング攻撃:XZ Utils事件は、ソーシャルエンジニアリング技術は、サプライチェーン攻撃よりも開発環境への完全なアクセスを獲得するための技術的要件がはるかに低いことを示した。 悪意のあるコード検出:適切な認証を持つ正当なメンテナンスは何でも公開することができます. 侵害されたnpmパッケージに注入された悪意のあるコードは、仮想通貨の財布をターゲットにし、リアルタイムでウェブトラフィックと財布の相互作用を遮断するために重要な機能を接続するために特別に設計されました. 公開前にこれをキャッチするための体系的なレビューはありません. 管理者の信頼の問題:オープンソースは信頼に基づいています. 一般に「qix」として知られる開発者Josh Junonは、過去1年間で1800件を超えるGitHubの貢献がありました - 信頼され、検証された開発者です。 しかし、彼は「非常に正当な」ように見えた2要因認証をリセットする電子メールを受け取りました。 誰が公開できるかを根本的に変えることなく、どのようにしてこれを防ぐことができますか? 何が実際に役立つのか サプライチェーンのリスクを大幅に減らすソリューションは高価で、論争的であり、npmの「即座に何でも公開する」というコア価値の提案を根本的に変える。 強力なパッケージのための強制的なコードレビュー: 毎週ダウンロードの限界を超えるパッケージは、新しいバージョン、特に依存性を追加したり、アーキテクチャの変更を行うバージョンをレビューする必要があります。 発行時における行動分析: 異常なパターン - 新しい依存性、曖昧なコード、予期せぬドメインへのネットワーク呼び出し、暗号財布のハック - を示す自動化されたシステム。 Maintainer Identity Verification: 広く使われているパッケージのメンテナンスのための実際のアイデンティティの要件 何年もかけて慎重に栽培された偽名ではなく、検証可能な人間です。 起源要件:パッケージを誰が出版したかだけでなく、どこで構築が行われ、どのソースからコミットし、どのような依存性を示す義務的な署名と証明書。 ブレイクポリシー:大規模なバージョン変更や人気のパッケージにおける新しい依存性は、即時公開ではなく、追加の検証を引き起こすべきです。 npm の変更は段階的に展開し、10 月上旬にトークンのライフタイム制限が効力を生ず、11 月中旬にクラシックなトークンが廃止されます。これらの変更は、AWS、Google Cloud、その他のプラットフォームが数年前に短期間の認証に移行しましたが、クラウドプロバイダーのセキュリティモデルとの調和は、オープン パッケージ レジストリのユニークな課題を解決しません。 不快な真実 npm は「npm を確保することは共通の責任である」とし、「これらの変更は一時的な摩擦を引き起こす可能性がある」と認識していますが、摩擦は維持者に置かれています - 常にトークンの回転、新しい認証方法への移行 - 実際の攻撃表面は大半が未解決です。 9月の攻撃はそれを証明した:数千人の開発者が妥協ウィンドウ中に悪意のあるパッケージをインストールした可能性があり、妥協が確認された4時間後、npmは影響を受けたパッケージのすべてのバージョンをダウンロードした。 npm には、数千人のソロ開発者によって維持されている約 2 百万のパッケージがあり、多くは副プロジェクトとしてオープンソースをジョギングしています。このプラットフォームは、CI/CD プロバイダーからの一時的、職務特有の資格を使用して、長期にわたるトークンを完全に排除する信頼できる出版(OIDC)の採用を強く奨励しています。これは良いことです。しかし、完璧な認証衛生にもかかわらず、適切な OIDC 資格を持つ正当なメンテナーはまだバックドアを公開することができます。 硬い真実は、トークンの回転とWebAuthnの移行は、Changelogの投稿で良いように見える見えるセキュリティの改善である。それらは実際の弱点に対処し、npmを現代のセキュリティの実践と一致させます。しかし、彼らは根本的な問題を解決しません:誰でもすぐに何でも投稿できるエコシステムでは、弱いリンクは一生の間トークンではありません。 NPMがコードの体系的なレビュー、行動検出、そして「即時公開」が「安全に公開」と衝突する現実に直面するまで、我々は病気が広がる間に症状を治療している。