Dependabot cooldown: GitHub по умолчанию защищает цепочку поставок

14 июля 2026 года GitHub тихо, но весомо изменил поведение одного из своих ключевых инструментов безопасности. Dependabot — бот для автоматического обновления зависимостей — теперь по умолчанию выдерживает трёхдневную паузу перед тем, как предложить слияние нового релиза. Никакой дополнительной конфигурации это не требует.

На первый взгляд — мелочь. На деле — важный сдвиг в архитектуре доверия к пакетам с открытым исходным кодом.

Что изменилось?

Dependabot теперь ждёт, пока новый релиз будет доступен в реестре как минимум три дня, прежде чем открыть pull request на обновление версии. Это поведение стало стандартным и не требует никакой настройки.

Раньше бот действовал немедленно: новая версия пакета появилась в npm, PyPI или другом реестре — Dependabot тут же предлагал обновить. Теперь он делает паузу и наблюдает.

Зачем нужна пауза перед обновлением?

Новые релизы — частая точка входа для атак на цепочку поставок: скомпрометированная или сломанная версия может попасть к вам прежде, чем мейнтейнеры или сообщество успеют её обнаружить. Короткая задержка даёт время для появления предупреждающих сигналов — и снижает вероятность того, что вы сольёте плохой релиз в момент его выхода.

Это не теоретическая угроза. Реальная история из практики: разработчик слил «рутинное» обновление зависимости, не зная, что версия была скомпрометирована — учётные данные мейнтейнера украли и внедрили вредоносный код. Атаку обнаружили и пакет удалили в течение трёх дней. Но код уже работал на заражённой версии.

Трёхдневная пауза — это не гарантия безопасности. Это время для сигналов тревоги, которые должны успеть всплыть.

Важный нюанс: security-обновления не затронуты

Режим по умолчанию применяется только к обновлениям версий. Security updates (обновления безопасности) по-прежнему открываются немедленно — критические исправления не задерживаются.

Это разумное разграничение: обычное обновление с 1.4.2 до 1.4.3 может подождать, а патч для CVE (уязвимости с публичным идентификатором) — нет.

Как это работает: поток обновления

graph TD
    A[Новый релиз в реестре\nnpm / PyPI / Maven] --> B{Dependabot\nпроверяет возраст}
    B -- "< 3 дней" --> C[⏸ Пауза.\nDependabot ждёт]
    B -- ">= 3 дней" --> D[✅ Открывается Pull Request\nна обновление версии]
    C --> B
    D --> E{Тип обновления?}
    E -- "Security update" --> F[🚨 PR открывается\nнемедленно, без паузы]
    E -- "Version update" --> D

Гибкая настройка через .github/dependabot.yml

По умолчанию — три дня. Но вы полностью контролируете этот параметр. Используйте опцию cooldown в файле .github/dependabot.yml, чтобы задать другой период или полностью отказаться от ожидания.

Команды могут задать стандартный период ожидания, установить разные задержки для major-, minor- и patch-релизов (по схеме семантического версионирования), а также включить или исключить отдельные зависимости из правила. Документированный диапазон — от 1 до 90 дней, а в списках include/exclude допускается до 150 записей.

Пример продвинутой конфигурации:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3       # базовый период ожидания
      semver-major-days: 30 # major-версии ждём дольше
      semver-minor-days: 7  # minor-версии — неделю
      semver-patch-days: 3  # патчи — 3 дня
      exclude:
        - "my-internal-package" # внутренние пакеты не ждут

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7

Сравнение: до и после изменения

Чего cooldown НЕ делает

Важно понимать пределы этой меры. Это контроль времени, а не проверка подлинности. Пакет, которому три дня, пережил три дня в открытом доступе — но он автоматически не доказал своё происхождение, процесс сборки, личность мейнтейнера или поведение во время выполнения.

GitHub поставил временной барьер на пути бота обновлений. Но такого же барьера нет вокруг каждой команды пакетного менеджера, каждой рабочей станции разработчика, каждого CI-резолвера или другого dependency-бота. Репозиторий может получать меньше «нулевых» PR от Dependabot — и при этом пропускать пакеты нулевого дня через другой путь.

Масштаб применения

Новый стандарт распространяется на обновления версий Dependabot во всех поддерживаемых экосистемах на github.com и вступит в силу в GitHub Enterprise Server версии 3.23.

Это охватывает npm, PyPI, Maven, Gradle, NuGet, Helm, RubyGems, Cargo, Composer, Go Modules и другие — то есть фактически весь стек современной разработки.

Итог: маленький шаг с большим смыслом

Трёхдневная пауза звучит скромно. Но в контексте участившихся атак на цепочку поставок это осознанное архитектурное решение: GitHub сделал трёхдневный период ожидания частью стандартного поведения Dependabot. Это звучит как небольшое изменение расписания. В действительности это изменение того, где команды размещают доверие: новая опубликованная зависимость больше не получает автоматический PR на обновление версии в момент публикации.

Для большинства проектов на GitHub это улучшение безопасности, которое активируется само — без единой строчки конфигурации. А для тех, кому нужна более тонкая настройка, весь инструментарий уже давно доступен в dependabot.yml.