PyPI закрыл дыру в цепочке поставок: старые релизы заперты

С 23 июля 2026 года PyPI отклоняет любые новые файлы, загружаемые в релизы старше 14 дней. Мера принята проактивно: атак такого рода ещё не зафиксировано, но техническая возможность «отравить» давно стабильный пакет через скомпрометированный токен существовала. Это вопрос времени, а не принципа.

Контекст

PyPI — центральный реестр Python-пакетов, от которого зависит практически весь AI/ML-стек: numpy, pandas, transformers, LangChain, FastAPI и тысячи других. Большинство AI-first компаний устанавливают зависимости через pip нередко без строгого version-pinning или проверки хэшей — что делает их уязвимыми к атакам на цепочку поставок.

Вектор, который закрыла эта мера, выглядел так: злоумышленник получает доступ к публикационному токену или CI/CD-воркфлоу проекта. Вместо того чтобы выпускать новую вредоносную версию (которую заметят быстро), он загружает изменённый файл в уже существующий стабильный релиз — скажем, в версию, которой доверяют тысячи downstream-пакетов. Пользователи не видят изменений версии. Зеркала кэшировали оригинал. Обнаружение могло занять недели.

«Ограничение введено, чтобы предотвратить отравление старых стабильных релизов в случае компрометации публикационных токенов или воркфлоу проектов. Насколько нам известно, это ещё не использовалось — но нет никаких технических причин, кроме того что атакующие просто не знали о такой возможности» — Сет Ларсон, PyPI blog

Аналитика

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

Масштаб риска понимаешь, когда думаешь о транзитивных зависимостях. Атака на популярный пакет нижнего уровня могла затронуть тысячи проектов одновременно — особенно в AI-first компаниях, где ML-пайплайны нередко запускаются в production с широкими сетевыми правами и доступом к данным, но без строгого аудита зависимостей.

Эта мера вписывается в последовательное hardening PyPI: Trusted Publishers (OIDC-аутентификация из GitHub Actions без статических токенов), карантин для подозрительных новинок — и теперь запрет на мутацию старых релизов. Реестры пакетов становятся критической инфраструктурой — как DNS или TLS — и PyPI ведёт себя соответственно. Это не разовый патч, а архитектурная позиция.

Кейсы применения в бизнесе

B2B SaaS стартап на Python/FastAPI: если у вас есть открытые или внутренние библиотеки на PyPI — проверьте, используете ли вы Trusted Publishers вместо статических токенов. Статический токен, утёкший в логах CI, давал окно для тихой атаки. Сейчас это окно сузилось, но токен всё ещё позволяет загружать новые версии. Ротируйте токены и ограничивайте их по конкретному пакету.

Корпорация с legacy Python-стеком: скорее всего, вы используете внутренние зеркала — Artifactory, devpi или аналоги. Проверьте, синхронизируют ли они пакеты с учётом immutability: если зеркало позволяет переопределить уже скачанный файл, политика PyPI вас не защищает. Обновление зеркала до актуальных практик — отдельная задача для команды DevSecOps.

SMB и локальный IT-бизнес (КР/СНГ): если проект использует pip install без закреплённых хэшей — добавьте флаг --require-hashes и сгенерируйте lock-файл через pip-compile или poetry. Это самый быстрый способ защититься от подмены пакетов, независимо от политик реестра.

Кейсы в личной жизни

Разработчик / AI-инженер: если у вас есть личные пакеты на PyPI — настройте публикацию через OIDC (Trusted Publishers) вместо секрета в переменных среды. Бесплатно, около 10 минут, убирает целый класс рисков компрометации токена.

Контент-мейкер или YouTuber с Python-скриптами: вы, вероятно, не публикуете пакеты, но устанавливаете их. Привычка фиксировать версии в requirements.txt и периодически запускать pip-audit — хорошая гигиена, которая защищает проекты от известных CVE без лишних усилий.

Студент / фрилансер: понимание supply chain атак — один из ключевых навыков безопасного разработчика. Настройте Trusted Publishers для своего pet-проекта: это практика, которую AI-компании начинают включать в вопросы на собеседованиях.

Как применить сегодня

• Запусти pip-audit в своём проекте — проверяет зависимости на известные уязвимости за пару минут.
• Переведи CI/CD публикацию с токенов на Trusted Publishers (OIDC) — официальная инструкция в документации PyPI.
• Добавь флаг --require-hashes в pip install в production-деплоях: если пакет будет подменён, установка упадёт с ошибкой, а не пройдёт молча.
• Если используешь зеркала PyPI — уточни у команды, синхронизируются ли они с учётом новой immutability policy.
• Прочитай пост Сета Ларсона в блоге PyPI — короткое, чёткое объяснение и этого патча, и общей security-позиции команды.