シャイ・フルード マルウェアがNPMを襲う！Tinycolor含む40以上のパッケージが乗っ取り被害！
引用元：https://news.ycombinator.com/item?id=45260741
AI生成の記事が多いから、参考になりそうな情報源をたくさん貼っとくよ。Socketのブログは9月15日に最初の記事、9月16日には続報。他にもStepSecurity、Aikido、Ox、Safety、Phoenix、Semgrepの記事もあるから見てみてね。
Socket:
- Sep 15: https://socket.dev/blog/tinycolor-supply-chain-attack-affect…
- Sep 16: https://socket.dev/blog/ongoing-supply-chain-attack-targets-…
StepSecurity: https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-p…
Aikido: https://www.aikido.dev/blog/s1ngularity-nx-attackers-strike-…
Ox: https://www.ox.security/blog/npm-2-0-hack-40-npm-packages-hi…
Safety: https://www.getsafety.com/blog-posts/shai-hulud-npm-attack
Phoenix: https://phoenix.security/npm-tinycolor-compromise/
Semgrep: https://semgrep.dev/blog/2025/security-advisory-npm-packages…
npmパッケージのユーザーとして、どうやって身を守ればいいか正直分からないよ。全ての依存関係を監査するのは無理だし、俺はTypeScript／JavaScriptの専門家じゃないから、巧妙なマルウェアは見抜けないだろうな。
だから、依存関係の”遅延アップデート”を考えたんだ。最新版じゃなくて、指定した期間（例えば6週間）前にリリースされたバージョンに更新する。完璧じゃないけど、昨日出たばかりよりは安全な気がするよ。既知の脆弱性があればすぐに更新したいけどね。
”全ての依存関係を監査するのは無理”って言うなら、できるだけ依存関係の数を減らして、有名で信頼できる（セキュリティ的に）開発者のものだけを使うべきだと思うよ。「Not-invented-here」症候群は普段は良くないけど、今回みたいな管理されてないエコシステムだと、むしろ賢明な選択だよね。
もし全ての依存関係を監査するのが無理なら、全部ゼロから書き直すのはもっと無理だろうね。重複した作業を避けるために、そもそも依存関係をインポートしてるんだからさ。
セキュリティ担当者として、開発者に依存関係を制限しろって言うと、いつも笑われるんだ。利益の邪魔だってね。現代の（特にJavaScriptの）コードはフレームワークやライブラリを繋ぐだけだから、コードを読んでも意味ないし、数百万行も一人で読めるわけないだろ。
根本的な解決策はないよ。せいぜい、より多くの人に厳しく検証されてると思われる、ほとんど更新されないパッケージだけに限定して、リスクを減らすくらいしかないね。
みんなleft-pad事件を忘れたのか？このエコシステムはコードの再利用を（不合理な）極限までやってるんだよ。JavaScriptが人気になり始めた頃、きっとどの開発者も依存関係システムに眉をひそめて、どうやって攻撃されるんだろうって思ったはずだ。
”解決策”は、強力な標準ライブラリを持つ言語を使って、信頼できる第三者が承認されたパッケージを手動で監査することだろうね。さらにArtifactoryを使う。でもそれは退屈で遅い。みんなパッケージを今すぐ欲しいんだ。業界全体が善意と希望の上に成り立ってるのが問題の一部だよ。
Timberlandのサイトで靴を買おうとしたら最悪だった。Amazonが強いのには理由があるってことだね。
”コードの再利用を（不合理な）極限まで推し進めたエコシステム”って言うけど、それだけじゃないよ。実際には、このエコシステムでは車輪の再発明が何度も繰り返されてるんだ。多くのパッケージは低品質で、あまり再利用に適してさえいないからね。
この問題は、些細なコードすら書くのを恐れて、ワンライナーで済む機能でもパッケージがあれば喜んで使うジュニアデベロッパーと、自分を証明したいから、npmパッケージを成功させることが一番だと考える（よくジュニアの）デベロッパーという、完璧な嵐が原因だね。
これが正しい答えだね。「最小限の」標準ライブラリを持つ言語は設計上欠陥があると言い切るよ。APIが固定されるっていう議論は、Rustのエポックとか”strict mode”で解決できるだろ。
標準ライブラリには、HTTPパース、HTTPリクエスト、JSONパースみたいに、現代のシステムとやり取りするために必要な全てが含まれるべきだ。そうじゃないって言い張るのは狂気だし、今回みたいな馬鹿げた結果に繋がるだけだよ。
フロントエンド開発って、CSS/JS/HTMLで簡単に始められるから参入障壁が低いのが良いところであり悪いところだよね。バックエンド出身のフロントエンド開発者の中には“フロントエンドは本当の開発じゃない”ってバカにするやつもいるし。
フロントエンドをバカにする開発者って、いったいどんなコードを書いてるんだろうね？
巨大な依存関係を避け、できるだけ少ないコードで仕事を終わらせるよ。JSは使わないで、CSSとHTMLを可能な限り使う感じ。
デザイナーや顧客、それにUS/EUのアクセシビリティ法は、あの考え方には猛反対すると思うな。
ほとんどの依存関係って、必要な機能よりも多すぎるものが多いよね。たいてい数個の関数しか使わないから、依存関係全体を書き直す必要はないんだ。簡単に自分で書けるなら依存関係は使わないで、自分で書くのが大変な場合にだけ使うのが良いと思うよ。
さっきの意見は自分でユーティリティを書き直す文脈では正しいけど、小さい依存関係と大きい依存関係のどちらを選ぶかって話とはちょっと違うよ。
必要な機能が多いからって、必ずしも一番小さい依存関係を選ぶべきじゃないんだ。例えばLodashの関数が5つ必要なら、Lodashを入れてビルド時に不要なコードを削除する方が、メンテも信頼性も低い新しい依存関係を5つも入れるよりずっと良いケースもあるからね。
俺は、自分の使い方に影響するバグ（脆弱性も含む）がない限り、依存関係は絶対に更新しない派なんだ。多くの開発者がプロジェクトの依存関係を定期的に更新してるのが信じられないよ。更新はバグ修正（セキュリティ問題含む）か、必要な新機能があるときだけにするべきだね。一度だけ、古いプロジェクトでPMにNodeの脆弱性警告がウチのプロジェクトには影響ないって説得したことがあったな。
プロジェクトに何かを取り込んだら、それがちゃんと動くことにはお前が責任を持たないといけないんだ。依存関係の管理方法はたくさんあるから、自分に合ったものを選べばいいけど、最終的にメンテナンスも含めて、きちんと注意する責任はお前にあるってことを忘れちゃダメだよ。
議論は、5つの関数それぞれに別の依存関係をインポートするんじゃなくて、その5つの関数を自分で書くべきって話だったんだよね。まあ、文字通り自分で書かなくても、Lodashのソースコードを見て自分のコードにコピペするだけでもいいんだけどさ。
依存関係を減らして、もっと自分でコードを書こうぜ。
アクセシビリティにJavaScriptが必要なの？知らなかったんだけど。
いや、JavaScriptは必要ないよ。むしろ今のモダンなデザインやフロントエンドフレームワークのせいで、アクセシブルなものを作るのがめちゃくちゃ難しくなってるんだ。昔はHTMLは純粋なセマンティックで、スタイルは全部CSSにするべきってルールがあったんだよ。今みたいに全部が派手じゃなくても、あれは最高だったな。
これって、適切にライセンスされたOSSモジュールの中から実際に使われてる部分だけをLLMツールが抽出して、直接コードベースに貼り付けるような仕事になりそうだね。
JavaScriptは、実はいくつかのAAレベルのWCAGコンプライアンスで必要だよ。たいていフォーカスの保持や移動、キーボード操作の提供でね。詳しいことはこのURLを見て。https://www.w3.org/WAI/WCAG22/Techniques/#client-side-script
それに、そのセマンティックHTMLのルールっていつの話？まるで大昔みたいに言ってるけど、HTML5（2008年）からだよ。
pnpmがこれについて、ちょうど新機能を追加したみたいだよ。これ読んでみて。https://pnpm.io/blog/releases/10.16
ほとんどのソフトウェアには無保証の条項があるよね。僕は弁護士じゃないけど、僕が使ったソフトウェアはどれも「動くとか何かしてくれることを期待するなら、とっとと失せろ」って平易な英語で言ってるのと同じだよ。
つまり、ソフトウェアは現状渡しで、全ての責任はユーザーにあると考えるのは甘い考えじゃない。弁護士たちが50年以上もソフトウェア企業にそう言わせてるんだからさ。
「外部ライブラリは、ほとんどのモダンソフトウェアで使われる機能のためじゃない」って言うけど、どこで線引きするんだ？君はHTTPサーバーでJSONの読み書きばかりしてるみたいだけど、みんなもそうなのか？「ほとんどの開発者がHTTPサーバーを書くから」って理由で標準ライブラリがGB単位になっちゃうのは良い解決策じゃない。
僕は逆の意見で、今の言語は大きすぎると思う。もっとコアは小さくして、ライブラリで言語を拡張できる設計にすべきだよ。Lispみたいに、全てがライブラリであるべきなんだ。
お前、明らかにLodashのソースコードを見たことないだろ。
もちろん、できるときはそうしてるんだけどさ。でも、自分でReactとかreact-hook-formとかは書かないし、stripe-jsを書き直すわけでもない。直接の依存関係が16個あって、それが全部で653個ものパッケージを引っ張ってくるなんてマジかよって思うけど、その中で自分で書くことを考えるのはjs-cookieくらいかな。依存を減らすためなんだけどね。それ以外は保守の負担が大きすぎるし、そんなことまでやる必要ないでしょ。
「標準ライブラリは現代のシステムとやり取りするのに必要なもの全てを含むべきだ」って意見、stdlibがうまく設計されてて常に最新なら最高だよね。でも実際は、全てをカバーしきれなかったり、新しい標準の採用が遅かったり、デザインの悪いモジュールを導入しちゃったり、言語の進化についていけなかったりするんだ。
一番良い方法は、ちゃんと保守できるサイズのstdlibを持って、その上で優秀な外部ライブラリを公式の「コミュニティ」モジュールみたいにして提供することだと思う。HTTP処理とJSONだけが現代システムに必要なものの一部って言ってるのがちょっと面白いな。暗号化とかも頻繁に必要になるけど、stdlibのモジュールってひどいことが多くて外部ライブラリに頼るじゃん。
あ、あとPython、Go、Rustを比較してるのが一番引っかかるかも。これらの言語は設計思想が全然違うからね。Pythonみたいに、とりあえず動くコードをサッと書きたい言語なら「電池込み」はわかる。Goも似たようなもんで、すぐに生産的になれるように設計されてるからstdlibに色々入ってるのは理にかなってる。でもRustはC++の代替で、パフォーマンスが重要だから、stdlibに無理やり詰め込むより高品質な外部ライブラリの方がいいに決まってるでしょ。
もっとコメントを表示（1）
これは新しいパッケージやバージョンが監査されないから起きるんだよ。ディストリビューションのメンテナーと開発者が同じ人物ってのが問題。
一般的な解決策はDebianがやってることを真似することだね。新しいパッケージが追加されず、バージョン変更もめったにない（セキュリティアップデートとバグ修正のみで新機能はなし）安定版ディストロを維持する。ほとんどの人がこれを使ってる。
それから、新しいパッケージや新しいバージョンを追加できるテスト/不安定版ディストロを維持するんだけど、そこでも追加するのはディストロのメンテナーだけで、パッケージの開発者じゃない。ここで監査が行われるんだ。
NPM、Python、Rust、Go、Rubyは全部、中央集権的でオープンなパッケージリポジトリだから、この問題に悩まされてるよね。
これは、何百もの（推移的な）依存関係を持つことをOKだと考えて、それらを盲目的に自動更新しちゃう開発者たちの文化的な問題だよ。これじゃ何百ものサードパーティにビルド（もしくはもっと悪いことに実行）環境へのアクセスを許してるようなものだ。
コード共有にもっと摩擦を加えても、とんでもない数のサードパーティを盲目的に信頼するという開発者の決断を帳消しにはできないでしょ。
残念だけど、それがほぼ業界全体の実情だよ。俺が見てきたソフトウェアプロジェクトはどれも、数えきれないくらいの依存関係があるんだ。npmだろうとcargoだろうと、Goのパッケージだろうと、何でも同じだね。
Goの中央集権的なパッケージリポジトリって、どこにあるか教えてくれる？
Goのアプリって、標準ライブラリの規模と質が良いおかげで、RustやNodeより外部の依存なしで作るのがずっと現実的だよ。
分散性を保ちながら、この問題を解決する方法はあるはずだと思ってるよ。
例えば、あるパッケージが長期間にわたって一日のダウンロード数がしきい値を超えたら、2つの人間が管理するアカウントでWebAuthnを使った2FA再認証/ステップアップ承認が必要になるとか。あるいは、こういう人気のパッケージは、再現性のあるビルドができる特定の自動ビルドシステムだけがNPMに直接プッシュできるようにして、マルウェアを仕込む奴はまずソースコードリポジトリを乗っ取る必要があるようにするとか。
これはNPMのDXと分散性を全部犠牲にする質問じゃないんだ。「リリース管理が必要な規模になったら、少しだけ手動のDXを受け入れる」ってことだよ。
ついこの前さ、誰かがLimbo（SQLiteのRustでの再実装版）が3135個も依存関係を持つのは合理的だって言ってたんだよね（そのうち1313個がRustの依存だよ）。
https://github.com/tursodatabase/turso/network/dependencies
例えば、総ダウンロード数が100万を超えるNPMアカウントには、WebAuthn 2FAを唯一の認証方法として義務付けるべきだと思うんだ。誰かがYubiKeyを数千個送る費用を出してくれれば、みんなもっと安全になるはずだよ。
Gitは中央集権的じゃないしパッケージリポジトリでもないよ。ちなみに、俺らのコードはGitLabにあるし。
GitHubは、Goのライブラリの大部分がホストされてる中央集権的なリポジトリだよ。
じゃあGitHubって全てのプログラミング言語の中央集権的パッケージリポジトリなの？
だったらGitとnpm、Cargo、PyPI、Mavenとかの違いって何？
そうそう。開発用依存関係もあるし、それだけで依存関係の数は約500も増えるけど、最終製品には入らないよ。
実際の数とはかなりかけ離れてるね。
GitとGitHubは違うよ。
実際、GoがGitHubを使ってるのとPythonがPyPIを使ってるのでは、ほとんど違いはないね。
Microsoftの誰かがrootアクセスを持っていれば、みんなを危険に晒せるんだ。
僕が思うに、問題はサプライチェーン攻撃を受けるほど頻繁にアップデートしすぎることよりも、既知のセキュリティホールがあるのに依存関係を十分に更新しないことの方が多いね。
GoのパッケージリポジトリはただのGitHubだよ。
結局のところ、全部URLなんだよね。
君が求めているのは、承認されたURLのセットだろ？それを維持するために誰かを説得して時間をかけさせる必要があるよ。
なんでパッケージのダウンロード数なんか載せるんだ？
NPMに提出されるもの全てに義務付ければいいじゃん。難しくないって。
多数の信頼できる依存関係の作者を信頼するのは不合理じゃないよ。私たちに欠けているのは、信頼を確立するための機関なんだ。
もしパッケージが、組織ごとのホワイトリストにある複数の検証済み作者によって暗号署名されることが配布の条件になれば、単一の開発者を侵害するだけで複数のマルウェア感染パッケージを公開できてしまうSPOFの問題が減るだろうね。
GitとGitHubは違うし、Go言語はPythonやNPMみたいな中央集権的なパッケージリポジトリがないって話ね。Goがいう“パッケージ”はソースファイルの集まりで、GitとかSVNで直接コードを引っ張ってくるんだ。GitHubに依存してる現状だと、実質そこが中央リポジトリみたいになっちゃってるけど、それは誤解だって言いたいのかな。
Debian開発者としてね、上流の変更をチェックするときに、リンターツールの更新とかスタイル変更みたいな“ノイズ”が多すぎて、本当の変更点が全然見えないのがマジ困るんだよね。これってソフトウェアのサプライチェーン問題の一部だと思うし、もっと抑えるべきだよ。
「安定版ディストロで新しいパッケージ入れない、バージョンもほぼ固定」って意見あるけどさ、実際ほとんどの人は新しいハードウェアに対応しない古いソフトウェアなんて欲しくないんだよ。だからDebian stableを使う人が少ないんだ。
だってさ、パッケージ公開が面倒になったら、新しい開発者にとって手間も費用もかかるじゃん。それに、俺たちは分散化を目指してるんだし、それはちょっと違うんじゃないかな。
そんなにGoのパッケージについてこだわるのはおかしいよ。Goパッケージの95%はGitHubにホストされてるじゃん。GitプロトコルでインストールしようがHTTPSでチェックアウトしようが、そんなのどうでもいいんだって。PythonもPyPIがメインだけど、Gitリポジトリから直接インストールできるしね。Goのパッケージがソースファイルの集まりだって言うけど、PythonやNPMのパッケージだって中身は似たようなもんだよ。
参照：
[0] https://docs.astral.sh/uv/concepts/indexes/
[1] https://thelinuxcode.com/install-git-repository-branch-using…
Rustではね、cargo vetっていうツールがあって、監査結果を共有できるんだ。GoogleとかMozillaもこの監査に貢献してくれてるよ。
アップデートしないってのも別の問題があるんだよね。ライブラリのオーナーが互換性をぶっ壊す変更を頻繁にやって、semverとか無視しまくり。だから、ユーザーは古い安全じゃないバージョンを使い続けるか、コードを書き直すかの二択を迫られるんだ。誰も金払わないで、無料でいい仕事しろって思ってるのが原因だね。
「Goのパッケージ（コード）の95%がGitHubにあるから、GitHubがすべての言語の中央リポジトリだ」なんて言ってるの？PythonだってPyPI以外のインデックスからインストールできるけど、Goとは根本的に違うんだよ。Goはソース配布しかサポートしないけど、他のパッケージはバイナリやスクリプトフックを持ってる。NPMのパッケージみたいに、ダウンロードしたtarballを加工してpublishするスクリプトとかさ。だから「すべての言語が中央集権的なリポジトリ問題で苦しむ」っていうのは違うって言いたいの。
500人もの見知らぬ人にCIインフラや開発者のノートPCにコードをプッシュさせるなんて、マジやばいことだよ。JLRが顧客の車じゃなくて工場をハッキングされたのはまだマシだけど、それでもかなり悪いケースだよね。「コードジェネレーターは最終製品に入らないから大丈夫」なんて言うなら、Ken Thompsonの“Reflections on trusting trust”を読んでみなよ。
俺はdifftasticを使ってるんだけど、これでノイズがかなり減ったよ。試してみてね！
https://difftastic.wilfred.me.uk/
Goの素晴らしい分散型依存管理って言うけどさ、今度GitHubが落ちたら、あんたのCIパイプラインがどうなるか教えてくれよ。その時にこの話はまたしようぜ。
500人の他人にCIインフラへコードをプッシュさせるなんてありえないって？でも、icu_normalizerみたいな30個の依存関係があるヤツでも、実際はGoogleとかServo、dtolnayみたいな数少ない信頼できる人たちのクレートに依存してるだけなんだぜ。30個に見えても、実質は3人の他人って話だ。
「誰も金払わないし、誰も無料で良い仕事しようとしないからこうなるんだ」って言うけどさ、俺が知ってる最悪のCVE（脆弱性）のいくつか、エンタープライズソフトウェアで起きてるんだぜ。不思議だろ？
もっとコメントを表示（2）
サプライチェーン攻撃が今のJavaScriptエコシステムに完全に組み込まれちゃってるって、残念ながら気付いちまったよ。Vendoringは一時的な対策にしかならないし、根本的な解決にはならないんだ。HTMXのおかげで、JavaScriptなしでサーバーレンダリングをもっと真剣に考えるきっかけになったぜ。アプリも速くて軽くなるだろうしな。
攻撃をJavaScriptエコシステムだけに限定するこの奇妙な見方をよく聞くけど、おかしいんだよな。セキュリティ業界でもNPM向けの対策ばかりで、PyPiやCratesには全然ないのはなぜ？同じ対策で他のエコシステムも守れるのに、放置してるのは理解できないぜ。
この攻撃は、開発者が新しい依存関係を追加する時に、きちんと吟味しないことに依存してるだけだよ。もしこの「吟味不足」がJavaScriptエコシステムだけの問題じゃないなら、RustやGolangでも同じように起こる可能性は十分にあるってことだ。
昔からのJavaScriptって、ブラウザでのサンドボックス実行のおかげで、実はめちゃくちゃ安全な環境だったんだぜ。でも、NodeJSとnpm周りのやり方は、セキュリティを根本的に見直す必要があるな。leftpadみたいな文化的な問題もあるし、簡単なスニペットはnpmに上げるべきじゃないだろ。
JavaScriptの依存関係ツリーはマジでヤバいレベルで入り組んでるよな。他のほとんどの言語は、こんなにネストされた構造にはなってないぜ。
まあ、NPMは特別で、他よりもずっと攻撃されやすいんだよ。Python+HTMXのWebアプリなら依存関係は数十個だけど、一般的なJavaScript/Reactだと数千個になる。攻撃者はTinyColorとかLeftpadみたいなパッケージを一つ見つけるだけで、たくさんのプロジェクトを危殆化させられるってわけだ。
みんなNPMのパッケージレジストリ側ばかり話してるけど、もっと大きな問題はクライアント側にあるんだぜ。npm installが常に最新バージョンにアップグレードしちゃうから、攻撃者が悪意のあるパッチバージョンを公開するだけで、多くのユーザーが悪質なコードをダウンロードしちゃうんだ。他のエコシステムにはこんな「unsafe-by-default（デフォルトで安全でない）」な挙動はほとんどないからな。
マルウェアに感染するまで、サプライチェーン攻撃はパッケージ管理やコードへの侵入経路があるあらゆる層で起きるよ。NPMが本気なら、公開時に2FAを必須にしたり、公開前のスキャン、ハードキーでのパッケージ署名、署名一致の確認をすべきだね。SemverやCRCチェックだけじゃ足りないんだ。これはパッケージとパッケージ管理に組み込むべきだ。
うーん、普通のRustプロジェクトでも1000以上の依存関係があるんだよ。Zedはリリースモードだと2000以上にもなるんだぜ。
言語自体が異常な依存関係ツリーを持つなんてありえないよ。それはコードベースの特徴だよ。
JavaScriptには標準ライブラリがないから、UUIDみたいなパッケージが毎週1億7000万回もダウンロードされるのは続くんだよ。みんなに何度も書き直せなんて期待できないでしょ。
https://www.npmjs.com/package/uuid
今のところ、サーバーサイドでテンプレート部分をレンダリングして、ブラウザでHTMXを使ってコンテンツ更新をフェッチ/ロードするのが、一番良い方法みたいだね。
そうかな？crates.ioに行って、たまたま新しく更新されたpixelfixっていうPNGの透過ピクセルを修正するクレートを見てみたんだけど、直接の依存は6つだけど、推移的な依存は数百もあったよ。left-padみたいに小さくて特化したのが多いね。
https://crates.io/crates/pixelfix/0.1.1/dependencies
このパッケージが代表的じゃないかもしれないけど、JSエコシステムとかなり似てる気がするな。
JS界隈では緩い依存関係宣言が使われてるって言うけど、JSは他のエコシステムより依存関係のバージョン管理がずっと厳格なんだよ。PyPiはPEP 440とSemVerがごちゃ混ぜだし、バージョン指定なしの依存宣言とか、ロックファイルなしのrequirements.txtに頼りすぎたりするからもっとひどい。Mavenも自動化されたpom.xmlのバージョンテンプレートとかで、Semverみたいな標準に厳密に従ってない。JS界隈も完璧じゃないけど、もっとひどいところはたくさんあるぜ。
JavaScriptを書く必要が出てくるまでは、ってこと？
npm installはデフォルトでロックファイルを使うから、バージョンは変わらないよ。推移的な依存もね。package.jsonを自分で変えるか、npm updateを呼ばないとダメなんだ。わざわざそんなひどいプロジェクトにしない限り、君が言ってるみたいにはならないぜ。
それはimageに依存してるからで、imageは色々なファイルタイプを扱うために多くのクレートに依存してるんだよ。もしimageの全機能を無効にすれば、依存関係は5つくらいに減るぜ。
PyPIみたいに他のレポも対策は必要だけど、NPMの「特別扱い」をナメんなよ。JSはフロントもバックも使うから、マルウェアを仕込みやすいし、訪問者のブラウザに直接影響を与えるから、NPMはサイバー犯罪者にとって超魅力的なターゲットなんだぜ。
普通のRustプロジェクトは1000個以上の依存は使わないよ。Zedは特別なRustプロジェクトで、たくさんの機能と独自のUIフレームワークを持ってるフル機能エディタだからね。
「何が言いたい？」って？ただRustを擁護してるだけだよ。「残りの5つの依存も多い」って言うけど、rayonとかcrossbeam、tracingとかの有名なクレートが主だよ。
npm自体は特別じゃない、ユーザーはそうかもだけど。緩和策は超簡単で99.9999%効果的、どのパッケージマネージャーでも通用するぜ。つまり、1: 依存ツリーを徹底分析、2: 全バージョンを即座に凍結、3: よほどの理由か1と2を繰り返さない限り絶対アップデートしない。要はプロになれってこと。魔法で安全なんて思ってたら痛い目見るぜ。
いや、それは違う。これが現実だろ。俺がコンパイルしたRustプロジェクトは全部1000以上の依存関係を引っ張ってきたし、最近はZedが2000以上だったぞ。
いや、これは間違い。package-lock.jsonはnode_modulesが一致するときに使うんだ（npm installで新バージョンをダウンロードしないため）。でも、GitHubからクローンしてCIとかで初めてnpm installすると、package.jsonから最新を取ってpackage-lock.jsonを更新するはず。npm ciのドキュメントも違うって言ってる。
CライブラリはNode.jsより小さいよ（HTTP機能はないけど）。Cにはもっと信頼できるライブラリがたくさんある。プロジェクトにlibcurlやfreetypeを追加しても、それだけで依存関係のジャングルは広がらないからね。
