Очередная волна тайпсквоттинга в npm: 140+ вредоносных пакетов за неделю. Чем защищаете сборку?

[sneeke]

Исследователи на этой неделе сняли с npm больше 140 пакетов с тайпсквоттингом под популярные библиотеки — клоны react-, eslint- и hardhat-пакетов с опечатками в названиях. Полезная нагрузка классическая: postinstall-скрипт тащит переменные окружения и токены CI наружу. Неделей раньше похожая зачистка была в PyPI. Тренд очевидный: атакующим проще зайти через зависимости, чем ломать периметр. Вопрос к залу: что у вас реально внедрено против этого, кроме надежды на внимательность разработчиков? Интересует опыт именно небольших команд, без бюджета на enterprise-сканеры.

[svelteops]

База, которая закрывает процентов восемьдесят проблем и стоит ноль рублей: lockfile в репозитории, в CI строго npm ci вместо npm install, и npm config set ignore-scripts true глобально у разработчиков и на сборщиках. Подавляющее большинство этих вредоносных пакетов отрабатывает именно через install-скрипты — отключили их, и полезная нагрузка просто не запускается. Из side-эффектов — пара пакетов типа sharp требует скриптов для сборки нативных биндингов, для них делаем точечные исключения.

[pirani]

У нас прокси-реестр на Nexus, и это сильно меняет картину. Новые пакеты попадают к разработчикам не напрямую из npm, а через карантин: версия должна провисеть в реестре несколько дней, прежде чем прокси её отдаст. Звучит занудно, но почти все эти вредоносные пакеты живут в npm меньше 48 часов до зачистки — карантин их просто пересиживает. Плюс Nexus даёт единую точку, где видно, кто и что тянет. Для команды из 15 человек подняли за день на той же виртуалке, что и GitLab.

[kickmybox]

Расскажу, как мы к этому пришли через боль. Прошлой осенью джун в спешке поставил пакет с опечаткой в названии — один символ от настоящего. Postinstall утащил .npmrc и переменные окружения с его машины, включая токен от нашего приватного реестра. Заметили через сутки по странной активности токена, ротировали всё, обошлось без последствий, но седых волос прибавилось. После инцидента внедрили три уровня. Первый — превентивный: ignore-scripts везде, lockfile-линтер в pre-commit, который орёт на пакеты моложе 30 дней и на любые изменения resolved-URL. Второй — детектирующий: socket-подобный сканер в CI, который смотрит на поведенческие признаки в новых зависимостях, плюс обычный osv-scanner по базе уязвимостей. Третий — ограничивающий ущерб: токены CI короткоживущие и с минимальными правами, секреты только через OIDC, на машинах разработчиков нет долгоживущих кредов от прода вообще. Главный урок: считать, что вредоносная зависимость рано или поздно проскочит, и проектировать так, чтобы ей было нечего украсть.

[nixos69]

Поддержу предыдущего оратора насчёт «нечего украсть» — это вообще самый недооценённый слой. Все обсуждают сканеры, а потом у них в env сборщика лежит AWS-ключ с админскими правами и токен напрямую от продовой базы. Сканер всегда можно обойти, новый пакет всегда может оказаться чистым на момент проверки и стать вредоносным в следующем патч-релизе. А вот секрет, которого нет, украсть нельзя.

[coder_vasya]

А для соло-разработчиков и pet-проектов какой минимум посоветуете? Поднимать Nexus ради трёх репозиториев как-то жирно. Пока остановился на ignore-scripts, lockfile и привычке выжидать пару дней перед обновлением зависимостей — посмотреть, не подняли ли шум. Достаточно или я наивен?