GitHub добавил в Dependabot паузу по умолчанию: сервис теперь ждёт 72 часа перед тем, как открыть pull request с обычным обновлением зависимости. Почти одновременно PyPI закрыл другой рискованный сценарий: спустя 14 дней после публикации релиза в него больше нельзя дозагружать новые файлы. Для команд, которые живут на автоподтягивании пакетов, это не мелкая настройка, а попытка сбавить скорость там, где она уже не раз била по безопасности.
Обе меры подтверждаются официальными сообщениями GitHub и PyPI, а BleepingComputer связал их в один тренд: платформы начали сознательно вставлять временной буфер в цепочку поставок, чтобы вредоносный пакет не доезжал до проектов быстрее, чем его успеют заметить.
Dependabot теперь ждёт три дня перед обычным обновлением
GitHub сообщил 14 июля 2026 года, что Dependabot по умолчанию применяет трёхдневную задержку к version updates. Иными словами, новый релиз пакета не попадёт в обычный PR мгновенно: сначала он должен «отлежаться» в реестре не меньше 72 часов.
Есть важная деталь, которой в исходном тексте не хватало: это правило касается только обычных обновлений версий. Security updates, то есть обновления для закрытия известных уязвимостей, Dependabot по-прежнему открывает сразу. Иначе мера безопасности сама бы начала тормозить срочные патчи, что выглядело бы как плохая шутка.
GitHub прямо объясняет логику: новые релизы часто становятся удобной точкой входа для атак на цепочку поставок. За несколько часов сообщество и защитные сервисы могут успеть поднять тревогу, а вот автоматические обновлялки обычно реагируют быстрее людей. Пауза в три дня должна сократить именно этот зазор. При этом настройку можно изменить в .github/dependabot.yml или отключить совсем.
PyPI запретил дозагрузку файлов в релизы старше 14 дней
PyPI 22 июля 2026 года ввёл другое ограничение: если релизу больше 14 дней, добавить в него новый файл уже нельзя. Речь о защите от «отравления» старой версии, когда злоумышленник получает токен публикации или доступ к workflow и подсовывает вредоносный wheel или sdist в релиз, которому разработчики уже привыкли доверять.
Здесь тоже важна точность. PyPI не утверждает, что такой приём уже применяли в реальных атаках на площадке. Наоборот, площадка пишет прямо: известных случаев пока нет, ограничение ввели превентивно. Логика простая: техническая возможность существовала, а значит ждать первого громкого инцидента было бы странно.
При этом PyPI проверил, насколько болезненным окажется запрет для легитимных сценариев. По данным площадки, среди 15 тысяч популярных проектов только 56 публиковали wheel для Python 3.14 позже чем через 14 дней после выхода релиза. То есть ограничение бьёт по редкой практике, а не по норме.
Почему платформы резко добавляют трение
Контекст у решения вполне приземлённый: за последний год экосистема пакетов получила серию заметных инцидентов. GitHub в своём разборе напоминает атаку сентября 2025 года, когда злоумышленник опубликовал вредоносные версии chalk, debug и ещё ряда npm-пакетов с совокупной аудиторией свыше 2 млрд загрузок в неделю. Заражённые релизы прожили около двух часов, прежде чем их сняли. Для человека это быстро. Для автоматического PR в CI этого более чем достаточно.
PyPI ссылается на другой фон: обсуждение меры ускорили компрометации пакетов LiteLLM и Telnyx в марте 2026 года. Там проблема была связана с mutable reference в GitHub Action. Суть та же: если процесс публикации или обновления слишком доверчив, атакующему не нужно долго удерживать доступ, чтобы устроить проблемы тысячам downstream-проектов.
Что это меняет для команд в России и СНГ
Практический вывод простой: автoобновление зависимостей больше нельзя считать безусловным благом. Для стартапов это сигнал не мерить зрелость разработки числом быстро смерженных dependency PR. Для корпоративных платформенных и AppSec-команд это хороший повод пересмотреть политику обновлений: где нужен жёсткий lockfile, где стоит отключить лишние install-скрипты в CI, а где полезно разделить срочные security updates и обычные version updates.
Иными словами, GitHub и PyPI не «замедляют разработку», а перекладывают часть доверия с автоматики обратно на проверку. В 2026 году это уже не паранойя, а базовая гигиена.
Следующий логичный шаг для рынка — такие же временные буферы и более жёсткие правила публикации в других пакетных реестрах и CI-интеграциях.
Оригиналы: GitHub Changelog, PyPI Blog, BleepingComputer.