Введение

Современная фронтенд-разработка немыслима без переиспользования стороннего кода: типовое клиентское приложение на стеке React/TypeScript включает десятки прямых и сотни транзитивных зависимостей из публичного реестра npm. Безопасность приложения тем самым становится производной от безопасности всех используемых пакетов — эта проблема получила название угрозы цепочки поставок программного обеспечения.

Актуальность темы возросла в связи с серией атак на экосистему npm, в ходе которых злоумышленники получали контроль над учётными записями сопровождающих и публиковали вредоносные версии. Показателен инцидент марта 2026 года с библиотекой axios — одним из самых распространённых HTTP-клиентов для браузера и Node.js: в npm были опубликованы вредоносные версии, доставлявшие на машины разработчиков и в конвейеры непрерывной интеграции троян удалённого доступа [1, 2]. Хотя вредоносные версии находились в реестре лишь несколько часов, при объёме порядка ста миллионов еженедельных загрузок и более чем ста семидесяти тысячах зависимых пакетов радиус поражения оказался крайне велик [2].

Объект исследования

Объектом исследования являются программные зависимости клиентских веб-приложений, построенных на экосистеме npm. В качестве эмпирической базы рассматриваются три промышленных клиентских веб-приложения на стеке React/TypeScript, использующих менеджер пакетов pnpm.

Под угрозой цепочки поставок понимают компрометацию приложения через доверенные сторонние компоненты, а не через собственный код разработчика. Применительно к экосистеме npm можно выделить несколько типовых классов угроз.

Компрометация сопровождающего. Злоумышленник получает доступ к учётной записи автора пакета (через утечку токена, фишинг или повторно используемый пароль) и публикует вредоносную версию под легитимным именем. Именно к этому классу относится инцидент с axios: вредоносный код был опубликован под официальным именем пакета, что делает атаку особенно опасной, поскольку версия проходит штатную установку без видимых признаков подмены.

Тайпсквоттинг. Публикация пакета с именем, близким к популярному, в расчёте на ошибку разработчика при установке.

Известные уязвимости (CVE). Наиболее массовый класс — это не вредоносный код, а ошибки в легитимных версиях пакетов, которым присвоены идентификаторы CVE. Для библиотеки axios, в частности, актуальны уязвимости класса подделки запроса на стороне сервера (SSRF) и инъекции в HTTP-заголовки, устранённые в более поздних версиях [3, 4].

Цель и задачи исследования

Цель работы — на основе практического опыта аудита трёх промышленных веб-приложений сформулировать методику управления безопасностью зависимостей клиентского приложения и обосновать набор практических рекомендаций. Для достижения цели решаются следующие задачи:

1. классифицировать основные виды угроз цепочки поставок в экосистеме npm;
2. описать инструменты аудита зависимостей и их ограничения;
3. проанализировать инцидент с axios как пример конфликта между требованием обновления и риском компрометации линии релизов;
4. сформулировать практические рекомендации по снижению риска.

Методы исследования

Базовым средством статического анализа зависимостей в рассматриваемой экосистеме является команда аудита, сопоставляющая дерево установленных пакетов с базой данных известных уязвимостей. В проектах, использующих менеджер пакетов pnpm, применяется команда pnpm audit, которая по файлу блокировок (pnpm-lock.yaml) строит полное дерево зависимостей, включая транзитивные, и для каждого пакета проверяет наличие зарегистрированных уязвимостей с указанием уровня критичности и рекомендуемой безопасной версии [5].

Инструмент аудита обладает рядом ограничений, которые необходимо учитывать на практике. Во-первых, он выявляет только известные уязвимости, уже попавшие в базу данных, и бессилен против ранее неизвестных закладок в момент их появления. Во-вторых, рекомендация «обновиться до версии X» носит механический характер и не учитывает ни обратной совместимости, ни того, что рекомендуемая линия релизов могла быть скомпрометирована. В-третьих, значительная доля находок приходится на транзитивные зависимости, которые невозможно обновить напрямую без вмешательства в дерево разрешения версий.

Для управления версиями транзитивных зависимостей в pnpm предусмотрен механизм переопределений (поле overrides в package.json), позволяющий принудительно зафиксировать версию пакета во всём дереве, независимо от того, какую версию запрашивают промежуточные зависимости. Этот механизм является ключевым инструментом ручного управления риском.

Аудит каждого из трёх веб-приложений выполнялся по единой последовательности действий: фиксация исходного состояния дерева зависимостей; запуск pnpm audit и выгрузка отчёта с уровнями критичности и рекомендуемыми версиями; классификация находок; устранение (обновление прямых зависимостей, переопределение транзитивных через overrides, повторный аудит); документирование решений по уязвимостям, обновление которых сознательно отложено.

Результаты исследования

В результате аудита трёх веб-приложений выявлены уязвимости различных уровней критичности; сводные данные приведены в таблице 1.

Таблица 1

Результаты аудита зависимостей трёх веб-приложений

Наиболее показательным результатом аудита стала ситуация вокруг библиотеки axios, иллюстрирующая нетривиальный характер управления риском цепочки поставок.

В ходе инцидента марта 2026 года в реестр npm под официальным именем axios были опубликованы вредоносные версии, содержавшие троян удалённого доступа [1]. Последней безопасной версией в соответствующей минорной линии оказалась версия, предшествующая скомпрометированной; именно на неё рекомендовалось откатиться, а также зафиксировать её в файле блокировок и отключить автоматическое обновление пакета, поскольку вредоносная нагрузка содержала механизм повторной попытки самообновления [1, 2].

Одновременно с этим в той же библиотеке существовали известные уязвимости (класса SSRF и инъекции в заголовки), устранённые лишь в более поздней минорной линии [3, 4]. Таким образом, статический аудит формирует рекомендацию обновиться вперёд (для закрытия CVE), тогда как анализ инцидента предписывает остаться на более ранней безопасной. Возникает прямое противоречие между двумя корректными по отдельности требованиями безопасности (рис. 1).

Рис. 1. Конфликт требований при управлении уязвимостью axios

В рассматриваемых проектах было принято решение зафиксировать безопасную версию axios, не затронутую компрометацией, и сознательно подавить соответствующие предупреждения аудита о CVE, задокументировав это решение. Обоснование: риск исполнения вредоносного кода при попадании в скомпрометированную линию релизов оценивался как существенно более высокий и немедленный, чем риск эксплуатации известных уязвимостей в контролируемом окружении клиентского приложения. Решение носит временный характер и подлежит пересмотру по мере стабилизации линии релизов библиотеки.

Данный пример демонстрирует ключевой тезис работы: автоматический аудит является необходимым, но недостаточным инструментом. Его рекомендации не могут применяться механически — итоговое решение требует экспертной оценки контекста, в том числе истории релизов конкретного пакета.

На основе проведённого анализа сформулированы следующие рекомендации по управлению безопасностью зависимостей клиентского веб-приложения.

Закрепление версий и контроль файла блокировок. Отказ от диапазонной записи версий для критичных зависимостей и фиксация точных версий в файле блокировок снижают риск автоматического получения скомпрометированной версии при установке. Файл блокировок должен находиться под контролем версий и проходить ревью при изменении.

Использование переопределений (overrides). Для транзитивных зависимостей, которые невозможно обновить напрямую, следует применять механизм overrides, принудительно фиксируя безопасную версию во всём дереве.

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

Отказ от автоматического обновления и реагирование на инциденты. Для пакетов, затронутых инцидентами компрометации, следует отключать автообновление и при необходимости ротировать секреты и учётные данные, которые могли быть скомпрометированы [1].

Минимизация поверхности атаки. Снижение числа прямых зависимостей и периодический пересмотр их необходимости уменьшают общий объём доверенного стороннего кода.

Вывод

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

Литература:

1. Mitigating the axios npm supply-chain compromise. — Текст: электронный // microsoft.com: [сайт]. — URL: https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise (дата обращения: 13.06.2026).
2. Axios Supply Chain Attack. — Текст: электронный // unit42.paloaltonetworks.com: [сайт]. — URL: https://unit42.paloaltonetworks.com/axios-supply-chain-attack/ (дата обращения: 13.06.2026).
3. CVE-2026–40175: Axios Unrestricted Cloud Metadata Exfiltration via Header Injection Chain. — Текст: электронный // GitHub Security Advisory: [сайт]. — URL: https://github.com/axios/axios/security/advisories/GHSA-fvcv-3m26-pcqx (дата обращения: 14.06.2026).
4. CVE-2025–62718: Axios Server-Side Request Forgery and proxy bypass. — Текст: электронный // nvd.nist.gov: [сайт]. — URL: https://nvd.nist.gov/vuln/detail/CVE-2025–62718 (дата обращения: 14.06.2026).
5. pnpm audit. — Текст: электронный // pnpm.io: [сайт]. — URL: https://pnpm.io/cli/audit (дата обращения: 14.06.2026).