すべてのプログラミング言語のパッケージマネージャーは脆弱だよ。Arch Linuxのユーザーレポジトリと全く同じ注意点がある。信頼できるメンテイナーが責任を持っているわけじゃないから、誰でもアカウントを作ってパッケージをプッシュできちゃう。

今日の大規模な攻撃は、いくつかのパッケージエコシステムに広がってる：TrapDoorやShai-Huludがnpm、pypi、composer、cratesを同じマルウェアで攻撃してる。

PyPIとCargoは、100%この同じ種類の妥協に脆弱だよ。NPMがダメだって言うのは、他の全てがダメだってことじゃないからね。

このジョーク、よく聞くよね。パッケージマネージャーの話で、インストールの緩さが問題なんだよ、NPMだけじゃない。CargoやPyPi、Nuget、PHPも最近はそうだし。NPMだけの問題じゃないんだよね。ここでよく言われるのは、Nodeに対する偏見があるからだと思う。でも、この問題はNPMだけに限ったことじゃないよ。

ちょっと背景を説明するね。「どのパッケージマネージャーも攻撃される可能性がある！」って言ってる人が多いけど、npmは設計上、すべてのパッケージが更新後にログインユーザーとして任意のコードを実行できるんだ。これって、めちゃくちゃ危険なデフォルトだよ。pnpmは、必要なパッケージだけを「オプトイン」できるようにしてる（例えば、うちのプロジェクトでは30個中4つとか）。それに、最小年齢や信頼のダウングレード禁止みたいな他のセキュリティ設定もたくさん追加されてる。攻撃者はパッケージの機能を更新することで攻撃できるけど、npmは特に問題で、呼び出しユーザーとしてサンドボックス外のスクリプトを実行しちゃう。これって、プロジェクトだけじゃなくて、マシンやネットワーク全体を危険にさらすことになる。こういうことは何年も前から知られてたのに、何の対策も取られてないんだよね。

正直、今は多くのパッケージマネージャーでこういうことが起きてるよね。pypiやcomposerも含めて。

これを削除して書き直してるんだけど、もっと明確にするためにね。HNが最初のコメントをひどくダウンモッドしたけど、俺が正しいって分かってるし、みんなが間違ってると思うから。だから、明確に言うと：- pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer（制限あり） - Maven ...これらは全部スクリプトを許可してる。俺たちはその参照を理解してるけど、正確じゃないよ：ほとんどのパッケージマネージャーはスクリプトを許可してるし、npmは最も成功したパッケージマネージャーなんだ。npmはスクリプトを許可すべきじゃないけど、悪用はどこにでもあるからね。

実は、そのタイトルのブログ記事があるよ。 https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://news.ycombinator.com/item?id=48155690

PyPI、5月11日。[1] Crates.io、5月22日。[2] Composer、5月22日。[3] [1] https://www.tenable.com/blog/mini-shai-hulud-frequently-aske... [2] https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra... [3] https://phoenix.security/laravel-lang-composer-supply-chain-...

みんながこのポリシーを採用したらどうなるの？ 2週間に変更するだけ？

uvは、Python開発者向けにも同じことをサポートしてるよ。

常に最新のパッケージを維持する必要があるっていうのは、ちょっと考えものだよね。マイナーバージョンのアップデートは、すぐに適用する必要はないし。重大な脆弱性があっても、マイナーバージョンのアップグレードが必要とは限らないと思う。

pnpmもそれに対応してて、v11からデフォルトでオンだよ。 https://pnpm.io/settings#minimumreleaseage

pnpmもこれをサポートしてるよ。

小規模な企業（従業員数が1,000人未満のことね）にとっては、これが実行可能な状態じゃないよ。うちのエンジニアリングチームは約10人だけど、ツールやクールダウン期間、最小リリース年齢を使ってできる限り対策してる。悪意のあるパッケージがある程度検出可能な限りはこれでやっていけると思う。これが適切なバランスだと思うし、リスクを取る日数を検出ツールの最新状態に合わせて調整できるからね。

サプライチェーンはソースリポジトリと関連するコミットハッシュに基づくべきだっていう考え方は正しいと思う。ツールを使って、定義されたソースから製品を自動的に組み立てるプロセスを作れるし、いくつかの言語やシステムでは既にサポートがあるよ。例えば、GolangやRustなんかね。「バイナリ」アーティファクトの概念は今や死んでるし、みんなgitを使ってビルドも早いから。npmやdocker hubのようなところではまだ生き残ってるけど、実際には必要ないと思う。

自動化できないことなんてないよね。Goの世界では、これを（議論の余地はあるけど）ベンダリングって呼ぶんだよね。サードパーティの依存関係ホスティングから依存を減らしたり、自分のコードレビュー用ツールに依存を取り込んだり、長期的に再現可能なビルドを確保するのにいいよ。

問題は、あなたの依存関係の依存関係で、さらに多くのレベルに続くことだね。

それで確率が変わるかもしれないけど、ちゃんとフォークしない限り（そして未来の脆弱性をすべてモンキーパッチしないと）、ずっと妥協したフォークを出荷することになるかもね。

Yarn 4がこれを自動化できるよ。

自分はpnpmを使って、リベラルなminimumReleaseAgeを設定してるよ。 https://pnpm.io/settings#minimumreleaseage 幸いなことに、v11からデフォルトでオンになってる。

npm（v11.10.0以上）をそのまま使うなら、プロジェクトのルートにある.npmrcにこれを追加するだけでOK: min-release-age=5

一部のパッケージはネイティブ依存関係をビルドする必要があるんだ。例えば、sharpはシステムにlibvipsをビルドしないと動かないよ。[0] https://github.com/lovell/sharp/blob/main/install/build.js

インストール時にスクリプトを実行しないようにしてるよ。今のところ、不便はないね。

そうだね。それに、タイトルにある「Red Hat」のスペルが間違ってるよ。