［ニュース解説］GitHubがDependabotに「3日待つ」仕組みを導入——サプライチェーン攻撃対策の新デフォルト

2026-07-24

はじめに

　GitHubは2026年7月23日、依存関係管理ツール「Dependabot」のバージョン更新機能に、新しいリリース公開から少なくとも3日間プルリクエストの発行を待つ「クールダウン」をデフォルトで導入したと発表しました。本稿では、この変更の背景にあるサプライチェーン攻撃の実態と設定方法について解説します。

参考記事

タイトル: The case for a cooldown: Why Dependabot now waits before issuing version updates
著者: Carlin Cherry
発行元: GitHub Blog
発行日: 2026年7月23日
URL: https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/

要点

Dependabotのバージョン更新は、新しいリリース公開から3日間の「クールダウン」を経てからプルリクエストが作成されるようになった
クールダウンは非セキュリティのバージョン更新のみに適用され、既知の脆弱性に対応するセキュリティ更新は従来通り即座に発行される
GitHub Advisory Databaseによれば、2026年5月までの1年間でnpmマルウェアに関する勧告は6,500件超に達し、前年の約6,200件から増加した
Solana web3.js、Axios、ua-parser-jsなど過去の侵害事例では、いずれも公開から数時間以内に不正なバージョンが検知・削除されている
クールダウンの日数はdependabot.ymlの設定オプションでプロジェクトごとに変更できる

詳細解説

なぜクールダウンが必要なのか

　GitHubによれば、2025年9月にnpmメンテナー1名の認証情報がフィッシングによって窃取され、合計で週20億回以上ダウンロードされているchalkやdebugなど十数個のパッケージに不正なバージョンが公開される事件がありました。このコードは、ブラウザアプリ内の暗号資産ウォレットアドレスを書き換えるものであり、コミュニティが異常に気づきnpmが該当バージョンを削除するまで、およそ2時間にわたって公開され続けていたとのことです。

　2時間という対応の速さ自体は評価できる点だと思いますが、バージョン更新ツールは新しいリリースが公開された瞬間にそれを取得するよう設計されているため、この2時間は自動化ツールがプルリクエストを開くには十分すぎる時間だと考えられます。悪意あるコードが新しいリリースとして公開され、人やスキャナーが確認する前に数分でビルドパイプラインに取り込まれてしまう構図は、近年のサプライチェーン攻撃に共通するパターンだと言えます。

Dependabotの2種類の更新と適用範囲

　Dependabotは、GitHub標準の依存関係管理ツールであり、既知の脆弱性に対応する「セキュリティ更新」と、リリースの新しさを保つ「バージョン更新」という2つの役割を担っています。GitHubの説明では、今回のクールダウンは後者のバージョン更新にのみ適用され、すでに公開されている脆弱性の修正を遅らせることになるセキュリティ更新は対象外とされています。バージョン更新は現在のパッケージの健全性に関わらず新しいリリースを取り込む仕組みであるため、悪意あるコードが紛れ込んだ場合の入り口になりやすいという点が、今回の変更の焦点になっていると考えられます。

データが示す攻撃の実態と3日間という根拠

　GitHub Advisory Databaseの集計では、2026年5月までの1年間にnpmエコシステムのマルウェア関連勧告が6,500件を超え、前年の約6,200件から増加し、1日あたり約18件のペースで新たな悪意あるnpmパッケージが確認されたとのことです。また、Solana web3.js、Axios、ua-parser-jsといった広く使われるパッケージでも、侵害されたビルドが公開から数時間以内に検知・削除された事例が紹介されています。外部サイトdaniakash.comによる2018年から2026年にかけての21件の著名なサプライチェーン事件のレビューでも同様の傾向が確認されており、axios、Solana web3.js、ua-parser-js、Ledger Connect Kitはいずれも公開から数時間で削除されたと報告されています。

　3日間という期間は、こうした短命な攻撃の大半をやり過ごしつつ、依存関係の更新を必要以上に遅らせない、という2つの目的のバランスを取った数値だと考えられます。他の開発ツールでも3日前後のクールダウンを採用する例があるとのことで、開発者がツールを行き来する際の一貫性という観点からも妥当な選択と言えそうです。設定はdependabot.ymlのクールダウンオプションで変更可能なため、社内限定パッケージと公開レジストリで異なる期間を設定するといった調整もできます。

多層防御の一部としての位置づけ

　クールダウンが有効なのは、悪意あるバージョンが公開・拡散されすぐに発覚するという特定のパターンに対してであり、リリースに仕込まれたまま長期間潜伏するバックドアや、メンテナー自身による不正行為、ビルドシステムの侵害といった、時間をかけて仕掛けられる攻撃にはほとんど効果がないとされています。そのため、クールダウンはあくまで防御の一層として位置づけ、ロックファイルによる依存関係の固定、CI環境でのインストールスクリプト無効化、ビルドパイプラインで使うトークンの権限を絞ること、更新をマージ前にレビューすることなど、他の対策と組み合わせることが重要だと思います。