Dependabotのバージョン更新にデフォルトのパッケージ・クールダウンが導入される

GitHubは、Dependabotのバージョン更新に対してデフォルトのパッケージ・クールダウンを導入しました。この変更により、Dependabotがバージョン更新のプルリクエストを作成する前に、新しいリリースがそれぞれのレジストリで少なくとも3日間利用可能になることが保証され、サプライチェーン攻撃の際にユーザーが侵害されたパッケージを自動的に採用してしまうリスクを軽減します。

即時のセキュリティ更新 vs. 遅延するバージョン更新

Dependabotは、重要な修正が遅れないように、セキュリティ更新と一般的なバージョン更新を区別しています。一般的なバージョン更新には現在3日間の待機期間が設けられていますが、セキュリティ更新は引き続き即座に作成されます。このメカニズムは、標準的なリリースに導入された悪意のあるコードの急速な拡散を防ぐ一方で、重要な脆弱性パッチが可能な限り迅速に提供されるように設計されています。

サプライチェーンのリスク軽減

クールダウン期間は、コミュニティや自動スキャナーが、自動PRを通じて広く配布される前に、悪意のあるパッケージを検出し、報告するためのバッファとして機能します。最新バージョンの採用を遅らせることで、GitHubは、侵害されたパッケージリリースの影響範囲（blast radius）を最小限に抑えることを目的にしています。

クールダウンの有効性に関するコミュニティの視点

開発者の間での技術的な議論では、このクールダウンの有効性とタイミングに関して、いくつかの懸念が提起されています。

• 検出ウィンドウ: 一部の開発者は、3日間のウィンドウは不十分であるか、あるいは逆効果になる可能性があると主張しています。あるユーザーは、悪意のある攻撃者が火曜日にエクスプロイトをリリースし、金曜日にマージするようにタイミングを合わせることで、パッチ適用能力が限られている週末にペイロードをトリガーさせる可能性があると指摘しています。
• 報告の遅延: 広範なクールダウンが感染の発見を遅らせる可能性があるという懸念があります。即座に更新を行うユーザーが少なくなれば、新しいコードに対する監視の目が少なくなり、侵害の報告が遅れる可能性があります。
• バージョンの変動 (Version Churn): 一部の開発者は、常に更新を求められるプレッシャーに対して不満を表明しており、頻繁すぎる更新は安定したバージョンを維持することよりも悪るい場合があると述べています。
• 「3日間の0-day」: この変更は、冗談を交えて「0-day」を「3-day」に変えるものだと表現されており、最新の状態を保つこととセキュリティを維持することの間の固有の緊張関係を浮き彫りにしています。

エコシステムへの影響と代替案

一部の開発者は、セキュリティの責任をレジストリ自体に移すべきだと提案しています。提案には、エコシステムへの影響が大きいパッケージ（例：数百万ダウンロードされているもの）に対して、より厳格なセキュリティ要件を強制し、脆弱性がレジストリに到達するのを未然に防ぐことが含まれます。

Dependabot以外で同様のクールダウン戦略を実装したいと考えている人向けに、コミュニティメンバーは、npm、pnpm、およびyarnといったパッケージマネージャーの設定方法を使用して、手動で更新の遅延を管理する方法を指摘しています。