Об авторе: Михаил Макаров, руководитель продукта AppSec.Track компании AppSec Solutions, участник АРПП «Отечественный софт»
Весной этого года произошло то, что ещё пару лет назад считалось почти невозможным. Через штатный сборочный конвейер популярного open source-проекта TanStack за считаные минуты прошли десятки вредоносных версий пакетов. Каждая — с корректной криптографической аттестацией сборки высокого уровня. Пострадали не маргинальные библиотеки, а компоненты, встроенные в тысячи продуктов по всему миру, включая официальный клиент OpenSearch и корпоративные пакеты крупных вендоров.
Подпись есть. Доверять нельзя
Самое неприятное в этой истории — не факт компрометации, а то, что автоматические средства проверки «промолчали». Артефакты были подписаны тем же механизмом и в том же конвейере, что и легитимные релизы. С точки зрения любого инструмента, сверяющего происхождение и подпись пакета, всё было «зелёным».
Это и есть главный сдвиг, который стоит осознать: механизмы, подтверждающие происхождение кода, не подтверждают его чистоту. Подпись говорит «этот пакет собран там, где положено». Она не говорит «внутри нет закладки». А если злоумышленник получил контроль над самим конвейером сборки, он подпишет вредоносный код так же, как и любой другой.
Для организаций, которые привыкли мыслить категориями «сертифицировано значит безопасно», это требует перенастройки картины мира. И начать стоит с понимания масштаба.
Масштаб: почему это перестало быть экзотикой
Цифры за последние полтора года не оставляют пространства для благодушия. К концу 2025 года в экосистемах открытого кода было выявлено около 19,5 тысячи вредоносных пакетов — на треть больше, чем годом ранее. К началу 2026-го счёт перевалил за 20 тысяч. Это не разовые всплески, а устойчивый тренд: цепочка поставок ПО стала для атакующих одним из основных маршрутов проникновения.
Почему именно она? Ответ в самой архитектуре современной разработки. Доля заимствованного открытого кода в типовом корпоративном приложении достигает 70–90%. Каждое приложение тянет за собой десятки прямых зависимостей и сотни транзитивных, тех, о которых команда разработки чаще всего даже не подозревает, потому что они подтягиваются автоматически.
По нашему опыту работы в кибербезопасности, картина типичного приложения выглядит примерно так: на каждую библиотеку, которую разработчик осознанно подключил и может назвать, приходится несколько, а иногда и десяток компонентов, попавших в сборку транзитивно. Именно в этом «слепом» слое чаще всего и обнаруживаются как известные уязвимости, так и потенциально враждебный код. Команда физически не может уследить за тем, о существовании чего не знает.
Отсюда простой вывод: доверять «репутации» популярной библиотеки с готовым кодом недостаточно. Популярность — это не свойство безопасности, а, скорее, наоборот, показатель привлекательности мишени. Чем больше проектов зависит от компонента, тем выше отдача от его компрометации.
Анатомия атаки: четыре способа «отравить колодец»
Атаки на цепочку поставок — это не один приём, а целое семейство техник. Разберём четыре основных, от самого простого к самому изощрённому.
1. Опечатка ценою в инцидент
Самый примитивный и при этом на удивление живучий метод. Злоумышленник публикует пакет с именем, почти неотличимым от популярного — с лишней буквой, дефисом или переставленными символами. Разработчик торопится, ошибается на одну букву в команде установки — и в проект попадает вредоносный двойник.
Метод рассчитан на человеческую невнимательность и на автоматику, которая не задаёт лишних вопросов. Защита от него концептуально проста — сверять то, что устанавливается, с доверенным списком, — но без автоматизации на масштабе сотен зависимостей это неработающая теория.
2. Захват мейнтейнера
Куда опаснее ситуация, когда атакуют не имя пакета, а человека, который его сопровождает. В сентябре 2025 года разработчик, отвечавший за несколько чрезвычайно популярных библиотек, получил письмо с поддельным уведомлением и ложным ощущением срочности — классический фишинг. Одного успешного входа в чужую учётную запись хватило, чтобы вредоносные версии широко используемых пакетов ушли в открытый доступ от имени легитимного автора.
Здесь нет никакой «хакерской магии» — есть усталость, спешка и убедительное письмо. Но последствия масштабируются мгновенно: пакет, которому доверяют миллионы, обновляется, и вместе с обновлением «расходится» закладка. Доверие к автору превращается в канал доставки.
3. Отравление сборочного конвейера
Это тот самый случай TanStack, с которого мы начали. Вместо того чтобы красть чужие учётные данные заранее, атакующий использует уязвимость в настройке автоматизированной сборки и вытаскивает нужные токены прямо в момент выполнения — из памяти процесса, обрабатывающего, например, входящее предложение изменений в код.
Дальше вредоносный код проходит через тот же легитимный конвейер, что и обычные релизы, и получает от него все атрибуты благонадёжности: подпись, аттестацию происхождения, «зелёный» статус у проверяющих инструментов. Именно поэтому статические сканеры в этом сценарии бесполезны — они проверяют, что пакет собран правильно, а не что в нём.
4. Червь, который размножается сам
Кульминация эволюции — самораспространяющееся вредоносное ПО. Осенью 2025 года экосистема столкнулась с червём, который поставил рекорды скорости и охвата. Логика его работы деловито проста: попав в систему при установке заражённого пакета, он ищет в окружении учётные данные и токены — доступы к репозиториям, облачным средам, реестрам пакетов — и, найдя ключи, публикует заражённые версии во все пакеты, которые может обновить от имени жертвы. Каждый новый заражённый пакет становится источником следующей волны.
Первая кампания за несколько дней затронула более сотни пакетов и десятки скомпрометированных учётных записей. Но по-настоящему тревожным стало продолжение: при повторной волне в ноябре 2025 года за трое суток пострадали десятки тысяч репозиториев. Новая версия червя начала выполнять вредоносный код ещё на стадии подготовки к установке — то есть раньше, чем у защитных средств появлялся шанс среагировать. А в сценарии, когда украсть данные не удавалось, вредонос переходил к прямому уничтожению доступных файлов.
Ключевой урок этой истории даже не в технических деталях, а в динамике. То, что раньше при использовании обычного трояна занимало недели, теперь разворачивается за часы. Скорость распространения обогнала скорость ручного реагирования. Значит, ручное реагирование как основная стратегия больше не работает.
Почему ПО, которое работает для задач КИИ, — в особой зоне риска
Важно, что вопрос атак на цепочку поставок актуален в равной мере для любого ПО, поскольку очень часто содержит заимствованный открытый код.
Более того, для государственных информационных систем цена компрометации несопоставимо выше: речь идёт о персональных данных граждан, о критических сервисах. Один заражённый компонент, попавший в сборку через подрядчика, — и проблема оказывается уже внутри контура организации.
С 1 марта 2026 года вступил в силу приказ ФСТЭК России № 117, пришедший на смену приказу № 17. Для темы цепочки поставок в нём есть два принципиальных момента.
Во-первых, при разработке программного обеспечения для государственных систем — как собственными силами, так и силами подрядчика — теперь необходимо следовать требованиям национального стандарта по безопасной разработке ГОСТ Р 56939-2024, который описывает процессы разработки безопасного ПО, включая контроль заимствованных компонентов.
Во-вторых — и это едва ли не важнее — ответственность за безопасность конечного продукта возложена на заказчика ПО. Заказчик обязан выдвигать требования к безопасной разработке и фиксировать их в техническом задании, а по сути — понимать, из чего собран софт, который он принимает и вводит в эксплуатацию.
Что с этим делать: от инвентаризации к контролю
Хорошая новость в том, что задача, при всей её серьёзности, вполне решаема. Плохая — в том, что решить её точечными мерами не выйдет. Нужен системный подход, и выстраивается он поэтапно.
Начать со знания состава ПО. Невозможно защитить то, о существовании чего не знаешь. Базовый артефакт здесь — SBOM (Software Bill of Materials), то есть полная «ведомость состава» программного продукта: перечень всех компонентов, включая транзитивные зависимости, с версиями и происхождением. По нашему опыту, сам факт первой честной инвентаризации зависимостей обычно становится для команды важным открытием — реальный состав приложения оказывается заметно богаче, чем предполагалось.
Автоматизировать контроль. Ручная сверка сотен компонентов невозможна в принципе — это работа для инструментов класса анализа состава ПО (в международной терминологии — SCA, Software Composition Analysis; в отечественной — анализ открытого кода, OSA, Open Source Analysis). Такие инструменты сопоставляют состав продукта с базами известных уязвимостей и вредоносных пакетов, отслеживают появление новых угроз в уже используемых компонентах и позволяют задавать политики: например, автоматически блокировать сборку, если в неё попадает пакет из чёрного списка или с критической уязвимостью.
Встроить проверку в конвейер. Контроль, который выполняется раз в квартал вручную, бесполезен против угроз, разворачивающихся за часы. Проверка состава должна быть встроена в конвейер сборки как обязательный этап — чтобы вредоносный или уязвимый компонент был задержан автоматически. Это же требование, по сути, вытекает и из логики непрерывного контроля, заложенной в новых требованиях регулятора.
Защитить сам конвейер. Наконец, кейс с отравлением сборки напоминает: защищать нужно не только то, что попадает на вход, но и сам процесс сборки — управление доступом, изоляцию, контроль настроек автоматизации. Скомпрометированный конвейер обесценивает все остальные меры, потому что он придаёт вредоносному коду вид легитимного.
Итоги
Атаки на цепочку поставок — это не отдельный класс угроз, который можно закрыть покупкой одного продукта или прохождением одной аттестации. Это следствие самой природы современной разработки, где почти любое приложение — это на 70–90% чужой код, собранный из открытых источников.
