GitHub Dependabot начал ждать 3 дня перед обновлением пакетов
GitHub изменил поведение Dependabot, сервиса, который в автоматическом режиме отслеживает версии зависимостей проекта и открывает пул-реквесты на их обновление. Раньше такой пул-реквест появлялся практически сразу после выхода новой версии пакета. Теперь по умолчанию, без какой-либо настройки со стороны пользователя, Dependabot ждёт минимум три дня с момента публикации релиза в реестре пакетов и только потом открывает пул-реквест на обновление. GitHub называет эту задержку «cooldown» (период выдержки).
Причина, защита от атак на цепочку поставок: свежий релиз пакета, частая точка входа для таких атак, когда скомпрометированная или попросту сломанная версия попадает в зависимости проектов раньше, чем её успевают заметить мейнтейнеры и сообщество. Пока версия «свежая», риск, что в ней прячется вредоносный код или критическая ошибка, выше обычного, сообщество ещё не успело её проверить, а жалобы и предупреждения ещё не накопились. Трёхдневная пауза даёт этому сигналу время проявиться, прежде чем автоматика вроде Dependabot подхватит новую версию и предложит влить её в проект.
Задержка касается только версионных обновлений, плановых пул-реквестов на переход к новой версии пакета. Обновления безопасности, которые Dependabot открывает в ответ на уже известную и подтверждённую уязвимость, задержке не подлежат и по-прежнему публикуются мгновенно: критичные исправления GitHub решил не тормозить. Пользователи сохраняют контроль над новым поведением: в файле .github/dependabot.yml параметром cooldown можно задать собственное окно ожидания, длиннее или короче трёх дней, либо отключить задержку полностью.
Новый дефолт уже действует для версионных обновлений Dependabot во всех экосистемах пакетов, которые поддерживает github.com. До самостоятельно размещённых серверов, GitHub Enterprise Server (GHES), версии GitHub для организаций, которые держат инфраструктуру у себя, изменение дойдёт с выходом релиза GHES 3.23.
Ключевые факты
- Dependabot теперь по умолчанию ждёт минимум три дня с момента выхода новой версии пакета в реестре, прежде чем открыть пул-реквест на её установку, включать эту задержку отдельно не нужно.
- Цель, снизить риск атак на цепочку поставок: скомпрометированная или сломанная версия пакета получает время «отлежаться» и попасться на глаза сообществу, прежде чем её автоматически предложат влить в проект.
- Обновления безопасности, исключение: пул-реквесты с исправлением уже известных уязвимостей Dependabot по-прежнему открывает без задержки.
- Своё окно ожидания можно задать или полностью отключить задержку через параметр
cooldownв файле.github/dependabot.yml. - Новый дефолт уже работает на github.com для всех поддерживаемых экосистем и появится в GitHub Enterprise Server начиная с релиза GHES 3.23.
Почему это важно
Dependabot, один из самых массовых инструментов автоматизации на GitHub: он подключён в огромном количестве репозиториев и по умолчанию предлагает обновлять зависимости сразу, как только выходит новая версия пакета. Именно эта скорость и была уязвимым местом: атака на цепочку поставок часто выглядит как публикация вредоносной или испорченной версии обычного, уже доверенного пакета, и чем быстрее эта версия расходится по чужим проектам, тем меньше шансов, что кто-то успеет забить тревогу. Трёхдневная задержка, простой способ, не требующий действий от пользователя, снизить скорость такого распространения в масштабе всей платформы: пока сообщество не подтвердит, что свежий релиз безопасен, Dependabot не станет предлагать его к установке.
Кому это важно
В первую очередь, мейнтейнерам open source проектов и командам, которые используют Dependabot для автоматического обновления зависимостей, особенно если у них настроено автослияние таких пул-реквестов: раньше пул-реквест мог влиться в проект буквально в первые минуты после выхода новой, ещё непроверенной версии пакета, теперь на это отведено минимум три дня. Важно и для служб безопасности и DevOps-команд, которые оценивают риски цепочки поставок программного обеспечения в своих организациях. Тех, кто обновляет зависимости другими способами, не через Dependabot, это конкретное изменение не касается.
Как это применить
Никаких действий предпринимать не нужно, трёхдневная задержка уже включена по умолчанию для всех репозиториев на github.com, использующих версионные обновления Dependabot. Если нужно окно другой длины или задержку хочется полностью отключить, это делается через параметр cooldown в файле .github/dependabot.yml каждого репозитория. Организациям на собственных серверах GitHub Enterprise Server стоит иметь в виду: это поведение появится у них только с обновлением до версии GHES 3.23, а до тех пор Dependabot будет по-прежнему открывать обновления немедленно.
Можно ли доверять
Да: это официальный анонс в блоге изменений самого GitHub, а не пересказ третьих лиц, источник первичный и максимально надёжный для описания того, как теперь работает собственный продукт компании. Текст написан в справочном, а не рекламном тоне: конкретные условия, трёхдневный срок для обычных обновлений, мгновенная публикация обновлений безопасности, настраиваемый параметр cooldown, сформулированы точно и проверяемы прямо в настройках Dependabot. Публикация вызвала заметный интерес у разработчиков: обсуждение на Hacker News набрало 135 голосов и 81 комментарий.
Риски и подводные камни
Трёхдневное окно, компромисс, а не гарантия: это условный срок, который не обещает, что за три дня вредоносная или сломанная версия обязательно будет замечена, особенно у менее популярных пакетов с небольшим сообществом вокруг них. Для команд, которые ценят немедленные обновления, например, чтобы быстрее получать новые возможности или несрочные исправления, задержка означает, что каждое обновление зависимости теперь приходится ждать на несколько дней дольше обычного. Наконец, это изменение поведения по умолчанию, а не то, что нужно включать самому: команды, которые не читали список изменений, могут не сразу понять, почему пул-реквесты Dependabot вдруг стали приходить позже, и потратить время на выяснение, что это не сбой, а новая норма.
«Небольшая задержка даёт этому сигналу время проявиться, так вы с меньшей вероятностью вольёте в проект плохой релиз в момент его выхода.»
— Блог изменений GitHub