「これを防ぐ方法はない」と語る、これが定期的に発生する唯一のパッケージマネージャー

同じ雰囲気: https://www.youtube.com/watch?v=lOTyUfOHgas

オニオンの記事はまだ残ってるから、リンクできるよ。

goのgo:generateワークフローも、npm経由で広がるワームを作るのに悪用される可能性があると思う。例えば、ハードドライブ全体をスクレイピングしてgitプロジェクトを探し出し、go.modの依存関係をパッチするプログラムを作れるし、これをツールチェーンスクリプトとしてgoで書くこともできる。NPMの弱点は、ユーザーが介入できない任意のコマンドやシェルスクリプトを実行できるpre/postinstallステップだね。依存関係は隔離されたchrootサンドボックス、もしくはコンテナ内で実行するべきだ。それがこの問題を軽減する唯一の方法だと思う。オペレーティングシステムのファイルシステムと開発ワークフローのファイルシステムを分離する必要があるからね。それに、ほとんどのホストベースのファイアウォールはバイナリごとに設定されていて、コマンドラインごとではない。だから「python」や「nodejs」がネットワークアクセスを許可される一方で、「nodejs myworm.js」みたいな具体的なコマンドには対応できない。だから、ファイアウォールはこの手のマルウェアに対してはあまり役に立たないよ。

Python/npmが狙われやすいだけなのかな？ 攻撃者は被害者がいるところに行くんだ。フロントエンドはほとんどがNPMを使ってるモノカルチャーだし、バックエンドはそうでもない。これはNPMの言い訳にはならないけど、また一つの弱点だね。フロントエンドとバックエンドの開発者の違いについて深いポイントを指摘することもできるけど、そこには触れないよ。

最後に確認したとき、npmには公開用の2FAがあったけど、cargoにはなかった。cargoはnpmより良いとは思わないけど、単に魅力的なターゲットじゃないだけだね。

正直なところ、Rustも同じ供給チェーン攻撃のパターンを持ってるよ。今は新しくてメンテナンスもされてるけど、10年後にはどうなるかわからないね。

一般的に、他のパッケージマネージャーもあまり良くないよね。特に、crates.ioやcargoはNPMと同じような問題を抱えていて、その言い訳の文言も妙に似てる。プログラミング言語やその周辺エコシステムのデザインやアーキテクチャについて面白いのは、「コアチーム」に与えられる大きな影響力だよね。コア言語の開発者が1人いると、1,000人の人気パッケージ開発者がいて、その下には1,000,000人のソフトウェア開発者がいて、さらに1,000,000,000人のユーザーがいる。つまり、ピラミッドの頂点で手を抜くと、下の層でその影響が大きくなるってこと。log4jみたいな「トップ1000」のパッケージにセキュリティの脆弱性があれば、数十億ドルの経済的損害や、何世代にもわたる修正作業が必要になることもある。でも、奇妙なことに、上の2つのレベルの資金はほとんどゼロに近い！ほとんどのプロジェクトは慈善事業で、道端で小銭を乞うような状態。最も使われているライブラリの中には、ボランティアの努力によるものも多いのに、グローバルなeコマースを支えているんだよね！ cough-OpenSSL-cough。結果的に、問題を解決する力を持っている人たちが、解決するための資金が最も少ないってこと。だから、NPMやCrates.ioは、GoogleやMicrosoftなどの主要な出版社のアイデンティティを確認したり、名前空間を追加するような基本的なセキュリティチェックすら拒否しているんだ。これは一定の労力がかかるし、技術的には簡単で、今は監視も安くできるけど、彼らの小さな予算を圧迫する可能性が高い。例外として、NuGetのようにしっかりした資金提供があるパッケージマネージャーがあって、Microsoftからの安定した資金で内部（営利！）のワークフローを支えているのと同じくらい、外部の「無料」ユーザーもサポートしている。「無料でオープン」って素晴らしいけど、結局は払った分だけの価値があるってことだね。[1] ほとんどの人がすぐに思い浮かべられる名前だよね：Guido van Rossum、Larry Wall、Kerningham & Richieとか。

パッケージや名前空間の所有権をどう管理するかは、パッケージマネージャーの管理者次第だよ。Maven Centralは何十年も存在していて、名前空間を盗まれる事件はほとんどない。例えば、「com.ycombinator」というgroupIdでパッケージを公開するには、ycombinator.comのドメインを所有していることを確認する方法が必要なんだ。そして、一度パッケージが公開されると、それは100%不変で、たとえ悪意のあるコードが含まれていても変更できない。確かに、そのライブラリは脆弱性があるとしてどこでも警告されるけど、NPMがMaven Centralのようなガードレールを長い間再現できなかったのは本当に不思議だよ。

なし。ターゲットとなる人口が少ないだけ。

記事が指摘しているポイントの一部は、他の人気のある言語は包括的な標準ライブラリを持っているってことだよね。JSは驚くほど小さいライブラリしかない。言語に付属する検証済みのライブラリセットがないから、アプリケーションは自分で作るか、サードパーティのパッケージリポジトリから引っ張ってくる必要がある。人々にNIH（自分でやらなきゃ）を叩き込んできたから、パッケージを手に取る傾向があるんだ。それ自体は悪いことじゃないけど、必要以上のコードを引っ張ってくることが多い。JSエコシステムは小さなモジュールを好むから、たくさんのモジュールが必要になるし、みんながその上に構築することで依存関係のグラフが膨れ上がる。意図的であれそうでないにせよ、問題が起こる可能性が高いんだ。ほかの言語では、最初から多くの機能が揃っている。確かにバグやセキュリティの問題はあったけど、JSエコシステムで見るものに比べればほんの少しだよ。他の言語では、外部の依存関係グラフがずっと小さくて、コア機能は信頼できるサードパーティから提供されている。