Кибербезопасность цепочек поставок ПО: анализ инцидента с npm-пакетом axios и рекомендации для бизнеса
Согласно сообщениям, злоумышленникам удалось получить доступ к аккаунту мейнтейнера и опубликовать заражённые версии библиотеки. В течение нескольких часов эти версии могли быть установлены в тысячи проектов по всему миру. Для российских компаний, работающих с open-source компонентами, этот случай — ещё один сигнал о необходимости пересмотреть подходы к управлению зависимостями и защите окружения разработки.
Как был скомпрометирован аккаунт мейнтейнера: типовой сценарий социальной инженерии
По данным, опубликованным в технических сообществах и репозиториях, атака строилась не на взломе инфраструктуры npm, а на манипуляции разработчиком. Ведущему мейнтейнеру axios пришло приглашение в корпоративный мессенджер якобы от известной технологической компании. Приглашение выглядело достоверно: использовались логотипы, каналы, фейковые профили сотрудников. Это пример хорошо спланированной социальной инженерии, нацеленной на человека с высокими привилегиями.
В процессе общения последовал звонок в Microsoft Teams, во время которого система якобы потребовала обновления клиента. Установка «обновления» привела к загрузке трояна удалённого доступа (RAT) на рабочую станцию разработчика. Вредоносное ПО, по имеющимся данным, предоставило злоумышленникам контроль над машиной, включая доступ к локальным секретам и сессионным cookie. Этот метод позволяет обходить двухфакторную аутентификацию, если атакующие действуют из уже авторизованной среды.
Важно подчеркнуть: сама по себе двухфакторная аутентификация остаётся важной мерой, но она не защищает от компрометации конечного устройства. Безопасность аккаунта начинается с безопасности рабочей станции.
Хронология инцидента (по данным открытых реестров)
По сведениям из публичных источников, события развивались следующим образом:
- В 00:21 UTC на реестр npm была загружена версия axios 1.14.1, содержащая вредоносные изменения.
- Около 01:00 UTC появилась версия 0.30.4 — предположительно для проектов, использующих старые ветки.
- В обе версии была внедрена зависимость plain-crypto-js с кодом, который при установке разворачивал RAT.
Сообщество разработчиков оперативно зафиксировало аномалию. Создавались тикеты в GitHub и сообщения в соцсетях. Однако, поскольку аккаунт мейнтейнера был под контролем, часть публичных сигналов удалялась. По информации из открытых каналов, прямое обращение к администрации npm позволило удалить вредоносные версии к 03:15–03:29 UTC. Таким образом, заражённые пакеты находились в публичном доступе около трёх часов.
За это время они могли быть установлены через стандартные команды npm install и npm update в CI/CD пайплайнах, продовых окружениях и на машинах разработчиков, особенно там, где не используются lock-файлы или не настроена проверка целостности.
Почему это значимо для российских компаний
В 2026 году атаки на цепочки поставок ПО стали одним из самых распространённых векторов компрометации. Российский бизнес — не исключение. Компании, работающие с персональными данными (152-ФЗ), критической информационной инфраструктурой (187-ФЗ) или банковской сферой, обязаны контролировать используемые зависимости. Регуляторы (ФСТЭК, Банк России) неоднократно указывали на риски, связанные с открытым исходным кодом.
Последствия компрометации через заражённый npm-пакет могут включать:
- получение злоумышленниками доступа к репозиториям, CI/CD, секретам и платёжным шлюзам;
- утечку ключей шифрования, исходных кодов или персональных данных;
- нарушение требований законодательства с риском штрафов (до 500 тыс. руб. для должностных лиц и до 1 млн руб. для юридических лиц при сокрытии инцидента).
В ходе аудитов, проводимых экспертами, нередко выявляется, что в компаниях отсутствует проверка подписей зависимостей, не используются lock-файлы, а разработчики имеют избыточные права. Сам по себе npm audit или Snyk полезны, но они не обнаруживают атаки, основанные на социальной инженерии и внедрении вредоносного кода через легитимные аккаунты мейнтейнеров.
Практические рекомендации по снижению рисков
На основе анализа публичных инцидентов и реальной практики можно выделить следующие меры защиты:
- Фиксация версий зависимостей
Используйте package-lock.json или yarn.lock во всех проектах, включая внутренние и тестовые. После инцидента с axios рекомендуется проверить lock-файлы на наличие версий 1.14.1, 0.30.4 и зависимости plain-crypto-js. Их обнаружение может свидетельствовать о компрометации окружения. - Проверка целостности при использовании CDN
Для фронтенд-библиотек, подключаемых через CDN, применяйте Subresource Integrity (SRI). Это не абсолютная защита, но она усложняет подмену ресурсов. - Приватные реестры с верификацией
Настройте приватный реестр npm (Artifactory, Nexus, GitHub Packages) с кэшированием и проверкой хешей. Это позволит не подхватывать свежевыпущенные заражённые версии без дополнительного анализа. - Управление доступом и 2FA
Ограничьте права на публикацию и изменение аккаунтов по ролевой модели. Включите обязательную двухфакторную аутентификацию, а для критических аккаунтов — аппаратные токены (YubiKey). Регулярно (например, каждые 30 дней) проводите ротацию токенов. - Использование OIDC вместо долгоживущих токенов
OpenID Connect позволяет публиковать пакеты через GitHub Actions без ручного ввода секретов. Украденный токен будет недействителен вне вашего CI/CD. - Детерминированные (hermetic) сборки
Обеспечьте воспроизводимость сборки: одинаковые входные данные дают одинаковый выход. При компрометации пакета можно быстро откатиться к чистому состоянию. - Автоматизированный мониторинг зависимостей
Используйте Dependabot, Snyk или аналоги, но с настройкой автоматической блокировки при обнаружении подозрительных паттернов (например, появления новой неожиданной зависимости в популярном пакете). - Аудит безопасности окружений разработки
Внедрите мониторинг аномалий на рабочих станциях (EDR, SIEM). Обращайте внимание на необычные сетевые соединения и процессы. RAT может долго оставаться незамеченным без соответствующего контроля. - Регулярное обучение социальной инженерии
Проводите для команды реалистичные фишинговые имитации (не формально, а с разбором ошибок). Разработчики, как и все сотрудники, подвержены атакам через «обновления Teams» и другие правдоподобные поводы. - План реагирования на компрометацию цепочки поставок
Разработайте чёткий runbook: изоляция машин, сброс всех токенов и секретов, пересборка образов, анализ сетевых логов на индикаторы компрометации (IOC). Для объектов КИИ и операторов ПД — уведомление регулятора в установленные сроки.
Что делать при подозрении на заражение
Если в ходе проверки обнаружены упомянутые версии или другие признаки, рекомендуется следующий порядок действий:
- Изолировать заражённую машину (отключить от сети и корпоративной инфраструктуры). Если это сервер CI/CD — остановить пайплайны.
- Собрать логи и артефакты (процессы, сетевые соединения, логи авторизаций) для последующего анализа.
- Сбросить все пароли, API-ключи, токены доступа к репозиториям, SSH-ключи.
- Выполнить чистую переустановку ОС на заражённых машинах — удаления RAT антивирусом недостаточно.
- Проанализировать сетевые логи за последние 30 дней на предмет соединений с известными индикаторами компрометации.
- Если компания относится к объектам КИИ или обрабатывает персональные данные — уведомить ФСТЭК или Банк России в соответствии с 152-ФЗ и 187-ФЗ.
Часто задаваемые вопросы (по открытым данным)
- Может ли антивирус обнаружить заражённый npm-пакет?
Антивирусные решения не всегда эффективны против supply chain-атак, так как вредоносная нагрузка может быть обфусцирована или активироваться при определённых условиях. Рекомендуется использовать специализированные инструменты анализа зависимостей в CI/CD. - Если я использовал заражённую версию всего несколько минут и обновился, безопасно ли это?
Нет. Вредоносный код мог успеть закрепиться в системе (автозагрузка, планировщик задач). Требуется полная проверка по указанному алгоритму. - Распространяется ли угроза на российские зеркала npm?
Зеркала синхронизируются с официальным реестром. Если заражённые версии попали в зеркало (а они находились в публичном доступе несколько часов), то риск существует. Проверка необходима независимо от источника. - Как защитить мейнтейнеров собственных open-source библиотек?
Внедрить обязательную 2FA (желательно аппаратную), использовать ролевую модель, проводить тренинги по социальной инженерии. - Каковы тенденции по атакам на цепочки поставок в России?
По данным из открытых отчётов, количество таких атак растёт. Злоумышленники смещаются с PyPI на npm и другие реестры. Российские компании остаются привлекательной целью из-за недостаточного контроля над open-source компонентами. - Ожидаются ли новые требования регуляторов?
В проектах документов ФСТЭК и Банка России обсуждается введение обязательного составления SBOM (Software Bill of Materials) и автоматизированной проверки зависимостей для объектов КИИ и финансовых организаций.
Резюме
Инцидент с axios — не единичный случай. Атаки на мейнтейнеров популярных библиотек будут повторяться, и их основой часто становится не сложный технический эксплойт, а человеческий фактор. Полностью исключить риски невозможно, но можно снизить их до приемлемого уровня: фиксировать зависимости, ограничивать привилегии, обучать команду и иметь план реагирования.
Если вы хотите оценить текущий уровень защищённости ваших процессов разработки и цепочек поставок, мы рекомендуем провести аудит безопасности. Специалисты помогут выявить типовые уязвимости, настроить контроль зависимостей и привести инфраструктуру в соответствие с требованиями регуляторов.
Для получения консультации или чек-листа по безопасности open-source вы можете обратиться в Secure Defence.
⚖️ Данный материал носит информационно-аналитический характер. Все выводы основаны на открытых источниках и не являются утверждением фактов, не подтверждённых официально. Материал не является юридической или технической рекомендацией. Любые решения принимаются читателем самостоятельно.
══════
Больше материалов: Центр знаний SecureDefence.
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]