Атака на цепочку поставок npm

Представьте, что вы используете веб-приложение для переводов криптовалют. Это приложение написано уважаемой компанией, которой можно доверять. Фронтенд реализован на JavaScript и использует сторонние библиотеки для ускорения разработки.

Мы все используем библиотеки, ведь какой смысл каждый раз изобретать велосипед и тратить на разработку неоправданно много времени. Мы используем npm для JavaScript, NuGet для .NET, PyPI для Python, Maven Central для Java, crates.io для Rust, Go modules для Go. И мы такие не одни. По оценкам, типичное приложение в наше время на 70-90% состоит из свободного ПО (Free and Open Source Software - FOSS).

Так вот вы используете веб-приложение крипто-кошелька и делаете перевод 0.5 биткоинов с одного своего адреса на другой. Но средства не приходят на ваш адрес. Они уходят в совершенно другое место. Почему это могло произойти? Могла быть скомпроментирована одна из библиотек, используемых кошельком. И в этой библиотеке мог оказаться код, подменяющий адреса в транзакциях на адреса злоумышленников.

Это именно то, что произошло в мире JavaScript 8 сентября 2025 года.

В этот день злоумышленники получили доступ к аккаунту маинтейнера нескольких популярных пакетов npm и выпустили их новые версии, добавив код, заменяющий адреса крипто-транзакций. Маинтейнера зовут Josh Junon и он стал жертвой фишинга. Изменены были такие популярные пакеты как debug и chalk. Общее количество скачиваний атакованных пакетов - 2 миллиарда в неделю. Вот тут можно прочитать детали.

Получается, кто-то обманул какого-то разработчика, а в итоге полбиткоина потеряли вы, серьёзно? Да, серьёзно, и это большая проблема в мире современной разработки. Данный тип атаки называется Supply Chain Attack - атака на цепочку поставок. Почему цепочку? Дело в том, что библиотеки тоже не пишутся с нуля, а используют другие библиотеки. А те другие и так далее. И, когда вредный код попадает в библиотеку debug, он по цепочке попадает и в другие библиотеки, которые используют debug. А затем в другие и так далее. Разработчики крипто-кошелька даже могли не знать, что в их приложении есть код debug.

Как разработчикам защититься?

Эта проблема особенно актуальна для экосистемы npm, которая чаще всего становится целью атак из-за своего огромного размера (более 4.8 млн пакетов) и относительно слабых правил безопасности. Культура использования множества мелких пакетов ("микрозависимостей") создает огромную поверхность для атаки. Вот несколько ключевых шагов для защиты:

* Фиксируйте версии зависимостей. Это важнейшее правило. Никогда не полагайтесь на автоматическое скачивание "последней" версии. Используйте lock-файлы (package-lock.json, yarn.lock). Они записывают точную версию каждого пакета в вашем проекте. Это гарантирует, что при каждой установке вы получите именно тот код, который был протестирован и проверен.

* Используйте npm ci вместо npm install. Команда npm install может обновлять ваш package-lock.json, что нежелательно в автоматизированных средах. Команда npm ci (clean install) строго устанавливает зависимости только из package-lock.json.

* Минимизируйте количество зависимостей. Каждая библиотека, которую вы добавляете в проект, — это потенциальный вектор атаки. Прежде чем установить новый пакет, спросите себя: "Действительно ли он мне нужен?". Иногда проще написать несколько десятков строк кода самостоятельно, чем тянуть за собой целое дерево чужих зависимостей. Экосистемы с богатой стандартной библиотекой (например, .NET) поощряют именно такой подход, снижая необходимость во внешних инструментах.

* Обратите внимание на Deno. Deno — это альтернативная среда выполнения для JavaScript/TypeScript, созданная Ryan Dahl, автором Node.js. Одна из целей Deno, как раз, заключается в том, чтобы создать богатую стандартную библиотеку.

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

#security #javascript #npm #supply_chain