Microsoft Threat Intelligence связала компрометацию npm supply chain Mastra с Sapphire Sleet. По данным исследования, скрытая postinstall-нагрузка попала более чем в 140 проектов. Особенно опасен момент установки: lifecycle script выполняется автоматически и наследует доступ CI runner-а к рабочей директории, сети и иногда секретам.

140+проектов получили заражённую зависимость
INSTALLpayload запускается в доверенном pipeline
CI/CDтокены увеличивают последствия

Почему традиционного SCA мало

Software Composition Analysis хорошо отвечает на вопрос о известных CVE, но новый вредоносный релиз может ещё не иметь идентификатора. Здесь важны происхождение пакета, изменение maintainer-ов, lifecycle scripts, сетевое поведение при сборке и отличие опубликованного tarball от исходного репозитория.

Защитный минимум

  • Запрещать install scripts по умолчанию и разрешать их точечно после review.
  • Использовать ephemeral runners без постоянных credentials.
  • Разделять токены чтения зависимостей и публикации релизов.
  • Проверять npm provenance, подписи и хэши артефактов.
  • Снимать SBOM для каждого релиза и хранить его вместе с build attestation.
  • Алертить новые исходящие домены и запуск неожиданных интерпретаторов во время build.
Практический вывод: pipeline необходимо считать production-системой с собственным threat model. Компрометированная зависимость ценна атакующему именно потому, что сборочная среда доверяет ей больше, чем обычная рабочая станция.

Что искать ретроспективно

Нужно сопоставить версии пакета с build history, проверить npm cache, журналы egress, процессы, созданные package manager-ом, и использование секретов после подозрительных сборок. Перевыпуск приложения безопасен только после очистки runner-ов и ротации доступных им токенов.

Первоисточник: Microsoft Security — Mastra npm compromise. Текст подготовлен Virusologia как независимый defensive-разбор.