Dependabot、更新前に待機時間を導入

2025 年 9 月、ある npm のメンテナの認証情報がフィッシング攻撃によって盗まれ、chalk や debug など、週に合計 20 億回以上ダウンロードされる約 dozen のパッケージに仕掛けられた偽バージョンが公開されました。このコードは、それを読み込んだブラウザアプリ内の暗号化ウォレットのアドレスを書き換えるものでした。悪意のあるバージョンは約 2 時間公開されていましたが、コミュニティによって発見され、npm 側で削除されるまででした。

2 時間の対応は迅速です。しかし、自動化された更新ツールにとっては、新しいバージョンを認識し、プルリクエストを開いてチームに提示するまでに十分な時間でもあります。なぜなら、バージョン更新ツールはリリースが公開された瞬間に最新版を取得するように設計されているからです。

このパターンは、サプライチェーン攻撃の増加した割合の背後にある要因です。悪意のあるコードは新リリースに乗って公開レジストリに載り、人間やスキャナーが確認する前に数分以内にビルドパイプラインに取り込まれてしまいます。

コールドダウン（待機期間）はこの計算を変えます。新しいリリースを採用する前に数日待つことで、メンテナ、セキュリティ研究者、自動化されたスキャナーが悪意のあるバージョンを特定し、プルリクエストに到達する前に削除する時間を確保できます。

セキュリティ上の問題ではないバージョンアップの場合、Dependabot は現在、リリースが公開されてから少なくとも 3 日後にプルリクエストを開くようになります。ただし、dependabot.yml のコールドダウン設定オプションは依然として動作を制御するため、プロジェクトに合わせて異なる待機期間パラメータを選択することも可能です。

Dependabot の更新には 2 つのタイプがある

Dependabot は GitHub に標準搭載されたツールで、依存関係のセキュリティ維持と最新状態の保ちを担っています。このツールは大きく分けて 2 つの役割を果たします。

1 つ目は「セキュリティ更新」です。これは既知の脆弱性に対応するもので、利用しているパッケージに関する注意報が発表されると、Dependabot が即座にアラートを発行し、パッチ適用版へ移行するためのプルリクエストを起票します。

2 つ目は「バージョン更新」です。これは現在の依存関係の状態に関わらず、新しいリリースが出た時点で常に最新状態を保つためのものです。

今回導入された 3 日間の待機期間（クールダウン）のデフォルト設定は、「バージョン更新」のみを対象としています。「セキュリティ更新」については依然として即座に起票されます。なぜなら、すでに公知となっている欠陥に対する修正を遅らせることは許されないからです。本記事で取り上げているのは「バージョン更新」です。ここでは目標が最新状態の維持であり、リスクとなるのが未検証のリリースを採用してしまうことです。

事例と GitHub Advisory Database のデータ

攻撃者が人気のあるパッケージを乗っ取った場合、悪意あるバージョンは短命である傾向があります。公開され、インストールを通じて拡散し、通常は数時間以内に検出されます。前述の例では、その悪意あるバージョンはわずか 2 時間の稼働でした。他の広く使われているパッケージでも同様の経過をたどっており、Solana の web3.js、Axios、ua-parser-js などに対する改ざんされたビルドも、公開から数時間以内に検出されています。

より一般的に、GitHub は GitHub Advisory Database を通じてこのパターンを直接把握しています。これはさまざまなエコシステムにおけるオープンソースのセキュリティアドバイザリをカタログ化したデータベースです。2026 年 5 月までの 1 年間には、npm のマルウェアに関する advisories が前年の約 6,200 件から増加し、6,500 件以上が登録されました。これは、毎日およそ 18 件の新しい悪意のある npm パッケージがカタログに追加されていることを意味します。

コールドダウン（待機期間）を設定することで、こうした攻撃の隙間を避け、リリースがあなたの手元に届く前に十分な検証が行われる時間を確保できます。

なぜ 3 日間なのか

人気のあるパッケージを狙った公開されたマルウェアは、通常すぐに検出されます。2018 年から 2026 年にかけて報告された 21 の広範なサプライチェーンインシデントをレビューした結果、同じパターンが確認されました。axios、Solana web3.js、ua-parser-js、Ledger Connect Kit などの悪意のあるバージョンは、公開から数時間以内に削除されています。もしコールドダウンの仕組みがあれば、これらの一時的な公開の大半は、誰かがインストールする前にフィルタリングできたはずです。

デフォルトの 3 日間という設定は、2 つの目標をバランスよく達成するためのものです。つまり、攻撃が最も頻繁に起こる期間を過ぎさせる一方で、依存関係の更新を必要以上に遅らせることはありません。

他のコミュニティメンバーも同様に 3 日間のコールドダウンを採用しており（一部はさらに長い期間を設定している）、これにより開発者がツール間を移動しても Dependabot の挙動が一定に保たれます。

なお、Dependabot の設定オプションで、より長くまたは短い待機時間を指定することも可能です。

多層防御の考え方

コールドダウン（待機期間）は、悪意あるバージョンが公開され、瞬く間に拡散して検知されるという特定の攻撃パターンを想定した機能です。しかし、リリースに仕掛けられたバックドアが休眠状態のまま放置されるような長期戦や、メンテナによる破壊行為、ビルドシステムの乗っ取りなどに対しては、単独では大きな効果を発揮しません。

このデフォルト設定の目的は、時間的制約のある一般的な脆弱性を排除することであり、他の防御策を代替するものではありません。コールドダウンは高速な攻撃への対策に過ぎないため、複数の防御層の一つとして位置づけるべきです。

具体的な追加対策としては、ロックファイルによる依存関係の固定、CI 環境でのインストールスクリプト無効化（可能な場合）、ビルドパイプラインにおけるトークンの範囲限定、マージ前の更新内容レビューなどが挙げられます。

信頼性の高い内部パッケージとパブリックレジストリで待機時間を切り替えたい場合は、Dependabot の設定に関するドキュメントをご覧ください。また、コールドダウンパラメータの全リストについては、Dependabot 設定オプションのリファレンスを参照してください。

ここから先へ

これは、GitHub で開発するすべての人のソフトウェアサプライチェーンを強化するために私たちが取り組んでいる複数の施策の一つです。デフォルトで有効になっているため、アクティブ化のために特別な変更は不要です。また、ワークフローに合わせて調整することも可能です。

Dependabot コミュニティのディスカッションで、実際の運用結果についてご意見を聞かせてください。

本記事「The case for a cooldown: Why Dependabot now waits before issuing version updates」は、GitHub Blog の投稿です。