npm стартовал проверять пакеты на вредоносный исходник при публикации

npm внедрил автоматическую проверку пакетов в момент публикации. Теперь новая версия становится доступна для установки не сразу после выполнения npm publish: сначала содержимое пакета анализируется на признаки вредоносного кода.

По итогам проверки пакет опубликуют в обычном режиме, отправят на ручную проверку или заблокируют. Одновременно npm вводит отдельные требования для инструментов двойного назначения — например, средств тестирования на проникновение и исследования безопасности.

Между публикацией и установкой появится задержка

В большинстве случаев проверка занимает около пяти минут. При высокой нагрузке, большом размере пакета или сложном содержимом ожидание может увеличиться до 15 минут и более. GitHub отдельно подчёркивает, что это текущие ориентиры, а не гарантированное время обработки.

Разработчикам стоит проверить автоматизацию выпуска. Сценарии, которые сразу после npm publish пытаются инсталлировать новую версию, запустить тесты или выполнить другие действия с ней, теперь должны учитывать возможную задержку.

Пока тест не завершена, команда npm dist-tag продолжит функционировать. Операции, которым требуется уже доступная релиз пакета, включая npm deprecate и npm unpublish, выполнить не получится.

Заблокированный пакет можно обжаловать

Если платформа заблокирует публикацию, сопровождающий может получить уведомление с возможностью подать апелляцию.

При серьёзном нарушении npm равным образом может принять меры в отношении связанных учётных записей сопровождающих. Подход будет зависеть от характера найденного содержимого и уверенности системы в результате проверки.

Автоматическое сканирование не означает, что реестр сможет обнаруживать любой вредоносный исходник. Команда npm обещает постепенно расширять покрытие проверки и сокращать время анализа.

Для инструментов двойного назначения вводят специальную метку

Некоторые легитимные пакеты используют возможности, которые автоматическая платформа может принять за вредоносное поведение. К ним относятся инструменты тестирования на проникновение, средства исследования безопасности, обфускаторы и другое программное обеспечение, которое можно применять как в законных, так и во вредоносных целях.

Сопровождающие таких пакетов должны добавить в package.json поле ввода contentPolicy:

{ "contentPolicy": { "class": "dual-use" }
}

В корне публикуемого пакета также должен находиться текстовый файл DISCLOSURE. В нём необходимо описать потенциально опасные возможности инструмента и объяснить, для каких легитимных задач они предназначены.

Эти сведения помогут команде доверия и безопасности npm (Trust & Safety) отличать специализированные защитные инструменты от вредоносных пакетов. При этом сама декларация не гарантирует публикацию: пакет могут дополнительно проверить автоматически или вручную.

Публикация потребует двухфакторной аутентификации

Для пакетов двойного назначения npm вводит обязательную двухфакторную аутентификацию.

Напрямую опубликовать такой пакет можно только из интерактивного сеанса с подтверждением через второй фактор. При использовании доверенной публикации через OIDC (trusted publishing) или токена, позволяющего обходить двухфакторную проверку, потребуется публикация через промежуточную стадию (staged publishing). В этом случае подтверждение выполняется при переводе подготовленной версии в открытый реестр.

После первой публикации метку двойного назначения нельзя просто удалить. Поле contentPolicy и файл DISCLOSURE должны сохраняться в следующих версиях. Для снятия декларации потребуется тест со стороны команды npm.

Новые правила будут вводить постепенно

npm не планирует включать все ограничения одновременно. Требования будут вводиться поэтапно, а сопровождающим пакетов, которые система относит к категории двойного назначения, отправят уведомления по электронной почте.

Главное практическое изменение для большинства разработчиков — новая версия пакета больше не обязана становиться доступной сразу после npm publish. Автоматизацию, которая рассчитывает на мгновенное выход версии в реестре, придётся сделать устойчивой к задержкам и повторным попыткам.

О том, как превратить проверки безопасности из набора инструментов в понятный план снижения рисков, 3 августа в 20:00 расскажет преподаватель курса «Внедрение и работа в DevSecOps» на бесплатном уроке. Присоединяйтесь