Безопасность цепочки поставки ПО: как пакетные менеджеры становятся точкой входа для атак

Инциденты с event-stream, xz и left-pad объединяет одно: пакетный менеджер в каждом из них работал именно так, как и был спроектирован. Не ломался, не давал сбоев - просто делал своё дело. И в этом главная проблема.

Архитектура доверия, которая бьёт по своим

Исследователь Эндрю Несбитт опубликовал детальный разбор моделей угроз для пакетных менеджеров - и выводы получились неудобными. Большинство известных атак на цепочку поставки не эксплуатировали уязвимости в классическом понимании. CVE на них никто не заводил. Механизмы работали штатно: npm запускал postinstall, pip поднимал setup.py, Cargo компилировал build.rs. Код из пакета выполнялся на машине пользователя - с его правами, с доступом к его окружению - ещё до того, как тот успевал хоть что-то проверить. Уругвай - Испания 27 июня

Это не баг. Это фича. И именно она легла в основу десятков громких инцидентов за последние годы.

Что реально фиксирует lockfile - и где он молчит

Отдельный пласт проблем - гарантии lockfile. Не все они одинаково надёжны. Одни фиксируют хэш содержимого и гарантируют получение конкретных байтов. Другие запоминают лишь имя и версию, доверяя реестру не менять содержимое задним числом. Разница критическая.

• go.sum и Cargo.lock фиксируют хэши содержимого
• Gemfile.lock и классический yarn.lock - только имя и версию
• Go дополнительно сверяется с публичной append-only базой контрольных сумм
• npm предлагает две команды: install и ci - поведение у них принципиально разное

Поверх этого - путаница с командами. Пользователи считают безопасными lock, audit и outdated, но в ряде экосистем даже получение метаданных способно спровоцировать выполнение кода. Форматы манифестов, которые являются программами, а не данными, жёсткую границу провести попросту не могут.

Dependency confusion и нормализация имён: тихие векторы

Исследование dependency confusion 2021 года наглядно показало: если один и тот же пакет существует в публичном и приватном реестре, резолвер нередко выбирает публичный - просто потому что там выше номер версии. Атакующему достаточно зарегистрировать имя внутреннего пакета в открытом индексе и выставить версию повыше.

Не менее коварна история с нормализацией имён. Реестр и клиент могут по-разному трактовать дефисы, подчёркивания, регистр и ширину Unicode-символов. В пространстве между двумя нормализаторами один пакет способен незаметно подменить другой - и это не потребует никакой эксплойтации в привычном смысле.

Что с этим делать

Несбитт не предлагает универсального рецепта - и это честно. Вместо этого он формулирует перечень вопросов, на которые каждая команда обязана ответить применительно к своему стеку: какие хуки запускаются при установке, срабатывают ли они для транзитивных зависимостей, что именно фиксирует lockfile, совпадает ли логика нормализации имён у клиента и реестра. Ответы на эти вопросы нигде не записаны, кроме исходного кода.

Go и Deno пока остаются редкими исключениями - они изначально спроектированы вокруг принципа «при установке ничего не запускается». Остальным экосистемам предстоит догонять. А пока инфраструктура пакетных менеджеров остаётся одним из наименее контролируемых звеньев в цепочке поставки - и именно на неё всё чаще смотрят атакующие.