Кибербезопасность

Атаки на цепочки поставок ПО в 2026: что изменилось

05 сентября 2026 Редакция Online-Computer.ru

2026 год стал переломным для атак на цепочки поставок программного обеспечения — не по количеству разовых громких инцидентов, а по масштабу и скорости, с которой злоумышленники научились превращать доверенные репозитории пакетов в оружие. По данным аналитиков, доля атак через цепочки поставок среди значимых облачных инцидентов выросла с 10% до 25% всего за первое полугодие — абсолютное число значимых инцидентов более чем удвоилось.

Самые технически изощрённые случаи года

11 мая 2026 года группировка TeamPCP провела одну из самых быстрых и масштабных атак в истории npm: за шесть минут было опубликовано 84 вредоносные версии пакетов в рамках 42 пакетов из пространства имён @tanstack/*. Начальным вектором стал скомпрометированный CI/CD-пайплайн TanStack на GitHub Actions.

В том же кластере атак злоумышленники опубликовали вредоносный npm-пакет @bitwarden/cli версии 2026.4.0, маскирующийся под легитимный интерфейс командной строки популярного менеджера паролей Bitwarden. При установке пакет запускал многоступенчатую нагрузку, которая похищала учётные данные из облачных провайдеров, CI/CD-систем и рабочих станций разработчиков, а затем самостоятельно распространялась, встраивая бэкдор в каждый пакет, который жертва могла опубликовать сама.

Масштаб через легитимные namespace

Кампания Shai-Hulud оказалась одной из самых масштабных по охвату: аналитики Datadog отследили 1092 уникальные заражённые версии как минимум в 796 пакетах суммарным охватом 130 миллионов загрузок в месяц. Пакет @asyncapi/specs с 1,4 миллиона еженедельных загрузок стал точкой, через которую заражение каскадом прошло по корпоративным пространствам имён, включая Zapier, Postman и PostHog.

В начале февраля 2026 года специалисты Microsoft выявили атаку на организацию @antv в npm: злоумышленник скомпрометировал аккаунт одного из мейнтейнеров и опубликовал вредоносные версии популярных пакетов для визуализации данных, которые еженедельно используют более миллиона разработчиков.

Новый уровень скрытности

В начале июня специалисты JFrog обнаружили кампанию IronWorm — написанный на Rust инфостилер, встроенный в 36 npm-пакетов и скрывавшийся за eBPF-руткитом уровня ядра. Вредонос распространялся, используя украденные npm-учётные данные для публикации троянизированных версий пакетов уже своих жертв — самовоспроизводящаяся цепочка, где каждая новая жертва становится источником заражения для следующей.

Показателен и случай с образами Debian на Docker Hub: несколько официальных базовых образов, содержащих печально известный бэкдор XZ, оставались доступны больше года, а производные образы продолжали распространять заражённый код — наглядная иллюстрация того, насколько долго живут последствия однажды скомпрометированной цепочки поставок.

Почему это работает: доверие как уязвимость

Общая черта всех перечисленных атак — злоумышленники не эксплуатируют классические уязвимости с CVE, а получают несанкционированный доступ к доверенным проектам или аккаунтам мейнтейнеров и встраивают вредоносный код в официальные релизы. Вредоносные версии выглядят подлинными именно потому, что проходят через те же реестры и CI/CD-интеграции, на которые команды разработки полагаются каждый день. По оценке отраслевых отчётов, в 2026 году было зафиксировано 59 кампаний и 657 вредоносных пакетов вообще без единого связанного CVE — то есть формально «невидимых» для традиционных систем сканирования уязвимостей.

Что это значит на практике

Для команд разработки главный практический вывод — что проверка версии пакета по номеру релиза и доверие к «официальному» namespace больше не гарантируют безопасность: сама механика публикации пакета может быть скомпрометирована без единой формальной уязвимости в коде. Растёт значимость таких практик, как обязательная многофакторная аутентификация для публикации пакетов, автоматическое сканирование новых версий зависимостей перед обновлением в проде, и — что особенно подчёркивают случаи вроде IronWorm — своевременная и полная ротация учётных данных CI/CD-систем после любого подозрения на компрометацию, а не только смена одного скомпрометированного токена.

← Все материалы