- 27,545
- 46
- 8 Ноя 2022
NPM 12 превращает установку зависимостей в отдельную работу.
NPM готовит одно из самых заметных изменений за последние годы. В новой версии менеджера пакетов разработчики больше не смогут по умолчанию запускать установочные сценарии из чужих библиотек. На бумаге выглядит как мощный удар по вредоносным пакетам , но полностью проблему такой шаг не решит.
Согласно объявлению NPM, в версии NPM 12 сразу несколько опасных возможностей перейдут в режим запрета по умолчанию. Главное новшество касается сценариев, которые запускаются при установке пакетов. Сейчас команда npm install может автоматически выполнить preinstall, install и postinstall не только у прямой зависимости, но и у вложенных пакетов, о существовании которых разработчик часто даже не знает.
Именно такие сценарии много лет помогали вредоносным пакетам быстро закрепляться на компьютерах разработчиков и в средах автоматической сборки. Достаточно было установить заражённую зависимость, и вредоносный код получал шанс выполниться сразу. В NPM 12 автоматический запуск отключат. Разработчикам придётся вручную разрешать нужные сценарии через npm approve-scripts, просматривать затронутые пакеты и отдельно запрещать лишнее через npm deny-scripts.
Кроме того, зависимости из репозиториев Git потребуют явного флага --allow-git. Такой шаг закрывает опасный обход, при котором зависимость могла через собственный файл .npmrc подменить исполняемый файл Git и запустить код даже при включённом --ignore-scripts. Зависимости в виде удалённых архивов по HTTPS тоже станут требовать отдельного разрешения через --allow-remote. Выход NPM 12 ожидается примерно в июле 2026 года, а готовиться к переменам можно уже в NPM 11.16.0 и новее.
Изменения выглядят сильными, потому что установочные сценарии давно стали одним из главных путей заражения в экосистеме NPM. Многие атаки строились именно на том, что пакет запускал код в момент установки, пока разработчик ещё не успел открыть проект или проверить содержимое зависимости. Автоматический запуск отключат, и это действительно снизит число массовых атак и усложнит жизнь злоумышленникам.
Параллельно набирает популярность другой простой механизм защиты – задерживать установку свежих версий. В NPM такой параметр появился в версии 11.10.0. Разработчик может запретить установку пакета, пока новая версия не проведёт в открытом доступе заданное число дней. Логика проста: многие заражённые версии быстро находят и удаляют, поэтому короткая пауза позволяет отсеивать часть угроз без сложного анализа. Похожий подход уже используют pNPM, Yarn и Bun.
На рынке также растёт спрос на защитные прослойки для цепочки поставок . Такие инструменты перехватывают попытку установки пакета, проверяют известные признаки риска и могут заблокировать опасную зависимость. В этой области работают открытые и коммерческие решения, включая Datadog, npq, Socket, Aikido и Endor Labs. Но такие средства помогают только до тех пор, пока разработчики не обходят предупреждения ради того, чтобы срочно собрать проект.
Главная слабость новой модели NPM связана не с технологией, а с привычками людей. Многие легитимные пакеты действительно используют установочные сценарии. Среди них есть esbuild, sharp, core-js, puppeteer, Nx, bufferutil, utf-8-validate и bcrypt. Одни скачивают двоичные файлы под конкретную платформу, другие собирают нативные модули через node-gyp, третьи готовят окружение после установки.
После выхода NPM 12 такие пакеты могут перестать работать без того, чтобы вручную разрешить сценарии. Разработчики начнут одобрять сценарии один за другим, особенно если процесс сборки будет ломаться перед сроками сдачи. Со временем полезная защита рискует превратиться в очередное окно, которое все автоматически подтверждают и закрывают. С похожей проблемой уже сталкивались браузеры, операционные системы и среды разработки.
Злоумышленники тоже не исчезнут. Если установочный сценарий больше не запускается сам, вредоносный код можно перенести в другой этап. Например, в команды для начальной настройки, отдельный загрузчик, внешний сценарий или двоичный файл с удалённого сервера. Если заражена уже используемая библиотека, сценарий установки может вообще не понадобиться, потому что полезная нагрузка выполнится внутри приложения.
Из-за этого защитникам станет сложнее отличать нормальное поведение от опасного. Легитимные авторы пакетов, которым всё ещё нужно скачать файл или собрать модуль, могут перейти на обходные схемы. Внешняя загрузка, непрямой запуск и нестандартные настройки раньше выглядели как сильный признак вредоноса, но после ужесточения правил часть нормальных проектов начнёт выглядеть так же подозрительно.
Получается неоднозначная картина. NPM 12 действительно закрывает один из самых удобных путей для массовых атак. Задержки установки свежих версий и защитные прослойки тоже дают командам реальный шанс остановить попытки заражения до запуска кода. Но вредоносные пакеты не исчезнут, а часть активности просто сместится туда, где меньше контроля и хуже видимость.
Включать задержку установки свежих версий можно уже сейчас, не дожидаясь NPM 12. Разрешённые сценарии лучше подготовить заранее, чтобы при переходе на новую версию не пришлось хаотично одобрять всё подряд. Защитные инструменты тоже полезны, если команда готова соблюдать их правила.
Но главная защита всё равно лежит не в настройке одного параметра. Команде нужно понимать, от каких пакетов зависит проект, зачем нужна каждая прямая и вложенная зависимость, какие действия разрешены при установке и кто отвечает за такие решения. NPM сделал важный шаг, но безопасность цепочки поставок не появится сама по себе после смены нескольких настроек.
NPM готовит одно из самых заметных изменений за последние годы. В новой версии менеджера пакетов разработчики больше не смогут по умолчанию запускать установочные сценарии из чужих библиотек. На бумаге выглядит как мощный удар по вредоносным пакетам , но полностью проблему такой шаг не решит.
Согласно объявлению NPM, в версии NPM 12 сразу несколько опасных возможностей перейдут в режим запрета по умолчанию. Главное новшество касается сценариев, которые запускаются при установке пакетов. Сейчас команда npm install может автоматически выполнить preinstall, install и postinstall не только у прямой зависимости, но и у вложенных пакетов, о существовании которых разработчик часто даже не знает.
Именно такие сценарии много лет помогали вредоносным пакетам быстро закрепляться на компьютерах разработчиков и в средах автоматической сборки. Достаточно было установить заражённую зависимость, и вредоносный код получал шанс выполниться сразу. В NPM 12 автоматический запуск отключат. Разработчикам придётся вручную разрешать нужные сценарии через npm approve-scripts, просматривать затронутые пакеты и отдельно запрещать лишнее через npm deny-scripts.
Кроме того, зависимости из репозиториев Git потребуют явного флага --allow-git. Такой шаг закрывает опасный обход, при котором зависимость могла через собственный файл .npmrc подменить исполняемый файл Git и запустить код даже при включённом --ignore-scripts. Зависимости в виде удалённых архивов по HTTPS тоже станут требовать отдельного разрешения через --allow-remote. Выход NPM 12 ожидается примерно в июле 2026 года, а готовиться к переменам можно уже в NPM 11.16.0 и новее.
Изменения выглядят сильными, потому что установочные сценарии давно стали одним из главных путей заражения в экосистеме NPM. Многие атаки строились именно на том, что пакет запускал код в момент установки, пока разработчик ещё не успел открыть проект или проверить содержимое зависимости. Автоматический запуск отключат, и это действительно снизит число массовых атак и усложнит жизнь злоумышленникам.
Параллельно набирает популярность другой простой механизм защиты – задерживать установку свежих версий. В NPM такой параметр появился в версии 11.10.0. Разработчик может запретить установку пакета, пока новая версия не проведёт в открытом доступе заданное число дней. Логика проста: многие заражённые версии быстро находят и удаляют, поэтому короткая пауза позволяет отсеивать часть угроз без сложного анализа. Похожий подход уже используют pNPM, Yarn и Bun.
На рынке также растёт спрос на защитные прослойки для цепочки поставок . Такие инструменты перехватывают попытку установки пакета, проверяют известные признаки риска и могут заблокировать опасную зависимость. В этой области работают открытые и коммерческие решения, включая Datadog, npq, Socket, Aikido и Endor Labs. Но такие средства помогают только до тех пор, пока разработчики не обходят предупреждения ради того, чтобы срочно собрать проект.
Главная слабость новой модели NPM связана не с технологией, а с привычками людей. Многие легитимные пакеты действительно используют установочные сценарии. Среди них есть esbuild, sharp, core-js, puppeteer, Nx, bufferutil, utf-8-validate и bcrypt. Одни скачивают двоичные файлы под конкретную платформу, другие собирают нативные модули через node-gyp, третьи готовят окружение после установки.
После выхода NPM 12 такие пакеты могут перестать работать без того, чтобы вручную разрешить сценарии. Разработчики начнут одобрять сценарии один за другим, особенно если процесс сборки будет ломаться перед сроками сдачи. Со временем полезная защита рискует превратиться в очередное окно, которое все автоматически подтверждают и закрывают. С похожей проблемой уже сталкивались браузеры, операционные системы и среды разработки.
Злоумышленники тоже не исчезнут. Если установочный сценарий больше не запускается сам, вредоносный код можно перенести в другой этап. Например, в команды для начальной настройки, отдельный загрузчик, внешний сценарий или двоичный файл с удалённого сервера. Если заражена уже используемая библиотека, сценарий установки может вообще не понадобиться, потому что полезная нагрузка выполнится внутри приложения.
Из-за этого защитникам станет сложнее отличать нормальное поведение от опасного. Легитимные авторы пакетов, которым всё ещё нужно скачать файл или собрать модуль, могут перейти на обходные схемы. Внешняя загрузка, непрямой запуск и нестандартные настройки раньше выглядели как сильный признак вредоноса, но после ужесточения правил часть нормальных проектов начнёт выглядеть так же подозрительно.
Получается неоднозначная картина. NPM 12 действительно закрывает один из самых удобных путей для массовых атак. Задержки установки свежих версий и защитные прослойки тоже дают командам реальный шанс остановить попытки заражения до запуска кода. Но вредоносные пакеты не исчезнут, а часть активности просто сместится туда, где меньше контроля и хуже видимость.
Включать задержку установки свежих версий можно уже сейчас, не дожидаясь NPM 12. Разрешённые сценарии лучше подготовить заранее, чтобы при переходе на новую версию не пришлось хаотично одобрять всё подряд. Защитные инструменты тоже полезны, если команда готова соблюдать их правила.
Но главная защита всё равно лежит не в настройке одного параметра. Команде нужно понимать, от каких пакетов зависит проект, зачем нужна каждая прямая и вложенная зависимость, какие действия разрешены при установке и кто отвечает за такие решения. NPM сделал важный шаг, но безопасность цепочки поставок не появится сама по себе после смены нескольких настроек.
- Источник новости
- www.securitylab.ru
