Содержание
Коротко
Заголовки про hijack npm-пакета повторяются, а совет «будьте осторожнее» не масштабируется на 1200+ транзитивных зависимостей. Материал на Dev.to разбирает реальную модель угроз и пять практических слоёв защиты — без иллюзии «абсолютной безопасности».
Что произошло
В package.json — десятки прямых deps, в node_modules — сотни и тысячи. Каждый пакет может:
- выполнить код на install (
preinstall/postinstall); - оказаться скомпрометированным после фишинга maintainer;
- подмениться при typosquatting (
lodahsvslodash).
Это происходит до тестов и линтера — в момент npm install.
Почему это важно
npm нельзя сделать «безопасным по умолчанию»: модель доверия — «запускаем код незнакомцев». Но разрыв между дефолтной установкой и hardened install большой.
| Мера | Эффект |
|---|---|
ignore-scripts=true в .npmrc |
Отрезает главный канал доставки payload |
npm ci --ignore-scripts в CI |
Без дрейфа lockfile |
| Ревью diff lockfile | Видны новые транзитивные пакеты |
| Provenance (Sigstore) | Привязка сборки к репо и workflow |
| Pin версий + proxy (Verdaccio) + SBOM | Меньше сюрпризов и быстрее расследование |
На практике
- Сегодня:
ignore-scripts=true, затемnpm rebuildтолько для доверенных native-пакетов (sharp,better-sqlite3). - В CI — только
npm ci, неnpm install. - На PR с deps смотреть package-lock.json, не только
package.json. - Для критичных сервисов — exact pin без
^/~на ключевых зависимостях. - Секреты не держать в env сборки, где крутятся install-скрипты.
Одна мера с максимальным ROI: отключить install scripts по умолчанию.
Итог
Полностью предотвратить компрометацию пакета на registry нельзя, но запретить выполнение в вашем build environment — можно. Дефолты npm плохие; проект может наследовать не их.