Зміст
Коротко
Заголовки про hijack npm-пакета повторюються, а порада «будьте обережні» не масштабується на 1200+ транзитивних залежностей. Матеріал на Dev.to розбирає реальну модель загроз і п’ять практичних шарів захисту.
Що сталося
У package.json — десятки прямих deps, у node_modules — сотні й тисячі. Кожен пакет може виконати код на install, бути скомпрометованим після фішингу maintainer або підмінитися через typosquatting.
Це відбувається до тестів і лінтера — у момент npm install.
Чому це важливо
npm не можна зробити «безпечним за замовчуванням», але розрив між дефолтною установкою та hardened install великий.
| Захід | Ефект |
|---|---|
ignore-scripts=true |
Відрізає головний канал payload |
npm ci у CI |
Без дрейфу lockfile |
| Рев’ю lockfile | Видно нові транзитивні пакети |
| Provenance | Прив’язка збірки до репо |
| Pin + proxy + SBOM | Менше сюрпризів при інциденті |
На практиці
- Сьогодні:
ignore-scripts=true, потімnpm rebuildлише для довірених native-пакетів. - У CI — лише
npm ci. - На PR з deps дивитися package-lock.json.
- Секрети не тримати в env збірки з install-скриптами.
Найбільший ROI: вимкнути install scripts за замовчуванням.
Підсумок
Повністю запобігти компрометації на registry не можна, але заборонити виконання у вашому build environment — можна.