Package Managers Need to Cool Down｜パッケージマネージャーは冷静になる必要がある

この投稿は、Seth Larsonからのリクエストに応じたものです。彼は、各種パッケージマネージャーにおける依存関係クールダウンの比較分析を依頼しました。彼の主張は次の通りです：すべてのツールは、グローバルに設定可能な `exclude-newer-than= ` をサポートすべきである。 攻撃者がメンテナの認証情報を侵害したり、休眠中のパッケージを乗っ取ったりした場合、彼らは悪意のあるバージョンを公開し、自動化ツールがそれを何千ものプロジェクトに取り込むのを、誰にも気付かれる前に待ちます。William Woodruffは2025年11月に依存関係クールダウンの必要性を提唱し、その1か月後に改めて主張しました。すなわち、パッケージのバージョンは、レジストリに公開されてから一定の最低期間が経過するまでインストールすべきではない、と。これにより、自らのビルドが問題のあるパッケージを取り込む前に、コミュニティやセキュリティベンダーが問題を発見する時間を確保できます。彼が調査した10件のサプライチェーン攻撃のうち、8件は攻撃可能な期間（ウィンドウ）が1週間未満でした。したがって、たとえ7日間という控えめなクールダウンでも、それらの大半がエンドユーザーに到達するのを阻止できたでしょう。 この概念はツールによって呼称が異なります（クールダウン、minimumReleaseAge、minimumReleaseAgeExclude、npmMinimalAgeGate、npmPreapprovedPackages、minimumReleaseAge、min-release-age、--minimum-dependency-age）。 JavaScriptエコシステムは他に先駆けてこの機能に対応し、pnpmが `minimumReleaseAge` を実装しました。uvは `--exclude-newer`、`exclude-newer-package`、`--uploaded-prior-to` を備えています。 BundlerとRubyGemsにはネイティブのクールダウンサポートはありませんが、コミュニティ運営のgemサーバーであるgem.coopがクールダウンのベータ版を開始し、新規公開されたgemを別のエンドポイントから提供する際に48時間の遅延を強制しています。クールダウンをクライアント側ではなくインデックス（サーバー）レベルで実施するのは興味深いアプローチです。なぜなら、gem.coopエンドポイントを参照するように設定したBundlerユーザーは、ツールやワークフローを一切変更することなく、クールダウンの恩恵を受けられるからです。 Rust、Go、PHP、.NET これらのエコシステムはまだ議論の段階にあります。Cargoには未解決のイシューが存在し、当面の間、概念実証として開発者マシン上で設定可能なクールダウン期間を強制するサードパーティのラッパーである `cargo-cooldown` が利用できます（CIパイプラインでは、コミット済みのロックファイルに対しては従来通りプレーンなCargoを使用し続けることが想定されています）。Goには `go get` に関する公開提案があります。 依存関係更新ツール Renovateは `minimumReleaseAge`、`security:minimumReleaseAgeNpm`、`semver-major-days`、`semver-minor-days`、`semver-patch-days` をサポートしています。 設定の確認 zizmorは `dependabot-cooldown`、`AddDependabotCooldown`、`--cooldown-days` を追加しました。 Cargo、Go、Bundler、Composer、pipはまだネイティブのクールダウンサポートを有していません。これは、更新の遅延を実施するためにDependabotやRenovateに依存する必要があることを意味します。これらは自動更新をカバーしますが、誰かが手動で `cargo update` を実行するのを阻止するものではありません。

パッケージマネージャーは冷静になる必要がある

背景や根拠まで確認しますか？

調べる

選ぶ

サイト