GitHub и PyPI ужесточают защиту цепочек поставок ПО: новые правила против атак

GitHub и индекс пакетов Python (PyPI) объявили о новых мерах, направленных на укрепление безопасности цепочек поставок программного обеспечения. Эти шаги призваны предотвратить быстрое распространение вредоносных версий пакетов и отравление давно стабильных релизов. Введение «периода охлаждения» для Dependabot и запрет на загрузку новых файлов в старые релизы на PyPI — ключевые изменения, которые должны снизить риски для разработчиков и пользователей по всему миру.

GitHub вводит трехдневную задержку для Dependabot

GitHub добавил в Dependabot механизм «cooldown»: теперь автоматизация ждет минимум три дня после публикации нового релиза, прежде чем открыть pull request с обновлением зависимости. Это сделано для того, чтобы дать мейнтейнерам, исследователям безопасности и автоматическим сканерам время обнаружить вредоносную версию и удалить ее до того, как она попадет в ваш проект. Как поясняют в GitHub, «ожидание несколько дней перед внедрением нового релиза дает возможность выявить злонамеренную версию и отозвать ее до того, как она достигнет ваших pull request'ов».

Важно, что трехдневная задержка применяется только к обновлениям, не связанным с безопасностью. Если речь идет о критическом исправлении уязвимости, Dependabot может действовать немедленно. Поведение можно настроить через опцию в файле dependabot.yml. GitHub подчеркивает баланс: «Три дня как значение по умолчанию уравновешивает две цели: он выводит вас за окно, в котором живет большинство этих атак, и не задерживает ваши зависимости дольше, чем необходимо».

PyPI блокирует загрузку в старые релизы

PyPI теперь отклоняет загрузку новых файлов в релизы, которым больше 14 дней. Это ограничение введено, чтобы предотвратить отравление старых и давно стабильных версий в случае компрометации токенов публикации или рабочих процессов проектов. Об этом сообщил Сет Ларсон, security developer-in-residence в Python Software Foundation, в недавнем блог-посте.

Предыстория и контекст

Идея такого ограничения обсуждалась еще в январе 2024 года в рамках PEP 740 (Digital Attestations). Однако активный диалог возобновился в марте 2026 года после того, как были скомпрометированы популярные пакеты LiteLLM и Telnyx. Эти пакеты пострадали из-за «изменяемой ссылки» (mutable reference) в использовании GitHub Action Trivy. Злоумышленники смогли подменить версии, что привело к быстрому распространению вредоносного кода среди пользователей.

Эти инциденты показали, что даже проверенные и давно существующие пакеты могут быть уязвимы, если рабочие процессы публикации не защищены должным образом. Введение ограничений на PyPI — это упреждающий шаг, чтобы закрыть лазейку, через которую атакующие могли внедрять вредоносный код в старые версии, которым доверяют многие разработчики.

Как это работает?

Для Dependabot: когда выходит новая версия пакета, Dependabot не сразу создает pull request. Вместо этого он ждет три дня (по умолчанию). Если за это время выясняется, что версия вредоносная, она может быть отозвана, и pull request не будет создан. Если же версия безопасна, обновление произойдет в обычном режиме. Это не замедляет процесс обновления критически важных исправлений, но фильтрует потенциально опасные релизы.

Для PyPI: если ваш проект публикует новую версию, а затем вы пытаетесь загрузить дополнительные файлы (например, исправления) в релиз, которому больше 14 дней, PyPI отклонит такую загрузку. Это вынуждает разработчиков выпускать новые версии вместо того, чтобы модифицировать старые, что снижает риск подмены содержимого давно используемых релизов.

Влияние на существующие рабочие процессы

Чтобы оценить, насколько disruptive будет это изменение, команда PyPI проанализировала базу данных проектов, которые публиковали новые файлы в старые релизы. Оказалось, что таких случаев немного: всего 56 проектов за последний год. Это говорит о том, что большинство разработчиков используют стандартный подход — выпускают новые версии, а не обновляют старые. Однако для тех, кто полагался на возможность патчить старые релизы, это станет серьезным ограничением.

Для GitHub новая задержка Dependabot может повлиять на скорость обновления зависимостей в проектах, но большинство команд не заметят разницы, так как обновления обычно не требуются мгновенно. Более того, это дает дополнительное время для проверки безопасности, что в долгосрочной перспективе повышает общую защищенность экосистемы.

Кого затронет и как

Разработчики, использующие Dependabot, увидят, что pull request'ы для обновления зависимостей будут появляться с задержкой в несколько дней. Это может замедлить процесс интеграции новых функций, но не критично. Более важно, что это защищает от атак, подобных тем, что произошли с LiteLLM и Telnyx.

Проекты, публикующие пакеты на PyPI, теперь должны быть внимательны: если вы хотите внести изменения в релиз старше 14 дней, вам придется выпустить новую версию. Это может усложнить процесс для проектов, которые поддерживают несколько веток или долгосрочные релизы. Однако это также стимулирует более чистую практику управления версиями.

Пользователи пакетов выиграют от повышенной безопасности: снижается вероятность того, что они скачают вредоносную версию пакета, даже если токены публикации проекта будут скомпрометированы.

Что будет дальше

Ожидается, что подобные меры будут внедряться и в других экосистемах. Уже сейчас npm и другие реестры рассматривают аналогичные ограничения. Возможно, мы увидим более широкое использование цифровых подписей и аттестаций (attestations) для подтверждения подлинности пакетов.

GitHub продолжит развивать Dependabot, возможно, добавляя более тонкие настройки для разных типов зависимостей. PyPI, в свою очередь, будет следить за реакцией сообщества и, возможно, скорректирует 14-дневное окно, если оно окажется слишком жестким.

Итог

Новые политики GitHub и PyPI — важный шаг в борьбе с атаками на цепочки поставок. Они не решают проблему полностью, но значительно повышают барьер для злоумышленников. Разработчикам стоит адаптировать свои процессы к этим изменениям, чтобы обеспечить безопасность своих проектов и пользователей. Следите за обновлениями в документации и блогах GitHub и PyPI, чтобы быть в курсе дальнейших улучшений.