Не устанавливай npm пакеты, пока не прочитаешь про безопасность

В 2026 году в NPM-реестре собрано более 3,5 млн пакетов, и эта цифра продолжает расти: ежемесячно туда публикуют еще 30–40 тысяч новых библиотек. Для фронтенд-разработчиков это одновременно суперсила и головная боль: многие задачи можно сделать быстрее и качественнее с использованием готовых библиотек. 

Но вместе с удобством растут и риски. Безопасность использования npm реестра давно стала зоной ответственности фронтенда: подмена пакетов, тайпсквоттинг, взломы популярных библиотек и уязвимости в транзитивных зависимостях напрямую влияют на стабильность продуктов и сохранность наших и пользовательских данных.

Главный вопрос — как сделать NPM-реестр и свои зависимости мощным инструментом ускорения разработки, а не пороховой бочкой. И ответ — никак, но снизить риски всё же можно.

Как устроен NPM реестр и почему он стал стандартом

NPM registry — это крупнейший публичный репозиторий JavaScript-пакетов, тесно связанный с экосистемой Node.js и де-факто ставший стандартом для фронтенд-разработки. Через npm как пакетный менеджер разработчики устанавливают библиотеки, фреймворки, утилиты сборки и тысячи вспомогательных инструментов — от React и Vue.js до небольших модулей для работы с датами, API или анимациями. Механика проста: разработчик публикует пакет в реестр, указывает название, версию, зависимости фронтенд-проекта и делает его доступным для установки одной командой.

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

Тайпсквоттинг в npm — когда одна буква стоит дорого

Одна из самых примитивных и при этом эффективных атак на npm-экосистему — тайпсквоттинг npm (или typosquatting). Схема работает за счет обычной человеческой ошибки: злоумышленник публикует вредоносные npm-пакеты с названием, максимально похожим на популярную библиотеку, рассчитывая на опечатку разработчика при установке. Вместо npm install lodash кто-то случайно вводит lodahs, вместо react — recat, вместо express — expres. Если пакетный менеджер находит совпадение в реестре, установка проходит без каких-либо предупреждений.

Дальше сценарий зависит от фантазии атакующего: вредоносный код может запускаться через postinstall-скрипты, собирать переменные окружения, красть токены CI/CD, SSH-ключи или просто открывать доступ к инфраструктуре компании. Опасность в том, что внешне такие поддельные пакеты часто выглядят вполне легитимно: у них есть описание, версии и даже рабочая часть кода, чтобы разработчик не сразу заметил проблему.

Реальные кейсы показывают, что это не теория:

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

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

Подмена пакетов npm — атака через внутренние зависимости

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

Сценарий выглядит так: внутри компании существует пакет, например company-ui-kit или internal-auth-lib, который используется в нескольких проектах. Он хранится во внутреннем реестре и доступен только сотрудникам. Проблема начинается, когда сборка одновременно обращается и к публичному реестру.

Атакующий находит название внутреннего пакета — через утечки в GitHub-репозиториях, package.json, логах CI/CD или публичной документации — и публикует в открытый реестр вредоносный-npm пакет с точно таким же именем, но с более высокой версией.

Дальше происходит классическая подмена зависимостей:

Ключевая проблема в том, что npm по умолчанию ориентируется на доступный пакет с подходящей версией, если приватный registry настроен некорректно. Для разработчика установка выглядит абсолютно штатно — зависимость подтягивается без ошибок, сборка проходит успешно, а вредоносный код уже выполняется внутри корпоративной среды.

Самый известный кейс произошел в 2021 году, когда исследователь Алекс Бирсан публично продемонстрировал атаку с подменой зависимости. Он обнаружил названия внутренних пакетов крупных компаний и зарегистрировал их в публичных реестрах npm, PyPI и RubyGems с более высокими версиями. В результате его тестовые пакеты автоматически загрузились во внутренние системы Apple, Microsoft, PayPal, Shopify, Netflix и других компаний. Этот кейс стал поворотным моментом для индустрии: выяснилось, что для компрометации корпоративной инфраструктуры иногда не нужен ни взлом серверов, ни сложные эксплойты — достаточно опубликовать пакет в публичный npm реестр и дождаться, пока чужая система сама его установит.

Заражение цепочки поставок npm — когда легитимный пакет становится оружием

Если тайпсквоттинг и подмена зависимостей строятся на создании поддельных пакетов, то supply chain attack npm работает гораздо опаснее: злоумышленнику не нужно выпускать фейк. Он получает доступ к уже существующему популярному пакету, которому доверяют тысячи разработчиков, и превращает его в точку заражения.

Сценарий обычно выглядит так: атакующий взламывает аккаунт автора через фишинг, утекший токен, слабый пароль или компрометацию CI/CD-доступа. После этого публикует новую версию легитимного пакета с вредоносным кодом. Для разработчиков всё выглядит штатно — знакомая библиотека, привычное имя, обычное обновление версии. Именно поэтому заражение цепочки поставок считается одним из самых опасных сценариев в npm-экосистеме.

Как развивается атака:

Этап	Что происходит
1	Злоумышленник получает доступ к аккаунту мейнтейнера
2	Публикует новую версию популярного пакета
3	Вредоносный код попадает в обновление
4	Разработчики автоматически обновляют зависимости
5	Вредонос распространяется на тысячи проектов

Главная опасность — масштаб. Если заражается нишевый пакет, ущерб ограничен. Если компрометируют библиотеку, которая используется по всей экосистеме, последствия становятся глобальными — свежий пример такой атаки: взлом npm-пакетов TanStack и Mistral AI.

Event-stream (2018)

Один из самых известных кейсов — пакет event-stream, который на момент атаки скачивали около 2 миллионов раз в неделю. Его автор Dominic Tarr фактически перестал поддерживать библиотеку и передал права новому контрибьютору.

Этим воспользовался злоумышленник: в пакет была добавлена зависимость flatmap-stream, внутри которой скрывался вредоносный код. Он был нацелен на пользователей криптокошелька Copay и пытался красть приватные ключи и данные транзакций.

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

ua-parser-js (2021)

В 2021 году был скомпрометирован популярный пакет ua-parser-js, который использовался для анализа user-agent строк и скачивался миллионы раз в неделю.

Злоумышленники получили доступ к аккаунту автора и выпустили заражённые версии 0.7.29, 0.8.0 и 1.0.0. Внутри находились malware-компоненты:

Пакет быстро удалили из npm registry, но заражённые версии успели попасть в продакшн-среды и CI-пайплайны.

Почему это самый опасный тип атак

Разработчики обычно проверяют новые пакеты гораздо внимательнее, чем обновления уже знакомых библиотек. Именно на этом строится атака: доверие к известному имени превращается в уязвимость.

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

Почему npm не может это остановить — и что он всё-таки делает

После историй с тайпсквоттингом, подменой зависимостей и supply chain attack npm возникает логичный вопрос: почему сам реестр это не блокирует?

Ответ в архитектуре. Реестр npm изначально создавался как открытая платформа для быстрого распространения open-source пакетов. Любой разработчик может зарегистрировать аккаунт, опубликовать библиотеку и обновлять версии практически мгновенно. Именно эта модель позволила npm registry вырасти до миллионов пакетов, но она же делает превентивную модерацию почти невозможной.

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

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

Что npm всё же делает для защиты экосистемы:

Чего npm принципиально не делает — и, вероятно, не сможет делать в полном объёме:

Это не проблема конкретно npm и не история про «плохую безопасность». Та же архитектурная реальность существует в PyPI, RubyGems и других открытых реестрах. Чем проще публикация, тем быстрее развивается экосистема — но тем выше ответственность разработчиков за проверку собственных зависимостей.

Нужен ли npm audit или что делать разработчику прямо сейчас

Заключение

Сейчас уже очевидно: безопасность при использовании npm реестра — это уже не узкий вопрос для специалистов по кибербезопасности, а базовая зона ответственности любого фронтенд-разработчика. Реестр сам по себе не «плохой» и не «опасный» — он остаётся мощнейшим инструментом, без которого современная разработка просто не работала бы с такой скоростью. Но открытая архитектура npm означает простую вещь: вместе с удобством вы автоматически получаете и риски.

Тайпсквоттинг, подмена зависимостей и заражённые обновления показывают одну общую проблему — вредоносный код всё чаще попадает в проекты не через взлом серверов, а через обычную установку зависимостей.

Слепое доверие к пакетам давно стало плохой привычкой. Установить библиотеку за 10 секунд легко, а разбираться с последствиями компрометации — уже совсем другая история.

Запусти npm audit в своём проекте прямо сейчас — это самый быстрый способ понять, насколько безопасны зависимости, с которыми ты работаешь каждый день.

Советуем дополнительно по теме: