В этом материале разберём, что произошло с npm-пакетами Red Hat, почему инцидент важен для команд безопасности, какие проверки стоит провести и каких выводов делать не следует.
Что произошло с npm-пакетами Red Hat#
Более 30 npm-пакетов из пространства имён @redhat-cloud-services были скомпрометированы и использовались для распространения новой версии вредоносного ПО Miasma. Код был предназначен для кражи учётных данных разработчиков, облачных секретов, SSH-ключей, токенов CI/CD и других чувствительных данных.
До удаления пакеты суммарно получали около 117 000 загрузок в неделю. После обнаружения проблемы Red Hat удалила их. Согласно опубликованному уведомлению безопасности, бэкдоры были ограничены внутренними инструментами, а вредоносные версии не распространялись через производственные системы Red Hat.
Что означает уведомление безопасности#
Под уведомлением безопасности в данном случае понимается официальная публикация деталей инцидента, его масштаба, потенциальной возможности эксплуатации и рекомендуемых мер защиты. Такие сообщения служат сигналом для технических команд провести оценку рисков и реагирование.
Почему это важно#
Подобные атаки на цепочку поставок ПО опасны тем, что позволяют похищать данные из рабочих окружений разработчиков и систем CI/CD. Даже если пакет никогда не использовался в продакшене, его установка во внутренние инструменты, сборочные среды или на рабочие станции разработчиков может привести к компрометации секретов.
По имеющимся данным, вредоносный код основан на фреймворке Mini Shai-Hulud и содержит дополнительные механизмы обфускации и сбора учётных данных. На момент публикации сообщалось о воздействии вредоносного кода более чем на 300 репозиториев GitHub.
Практический вывод прост: любое окружение, где когда-либо устанавливались или собирались затронутые пакеты, следует рассматривать как потенциально скомпрометированное. Повторное использование одних и тех же учётных данных между внутренними и внешними системами существенно увеличивает последствия инцидента.
Что проверить#
1. Найдите затронутые версии#
Проверьте инфраструктуру, графы зависимостей и lock-файлы на наличие 32 затронутых пакетов и 96 скомпрометированных версий. Удалите их и замените проверенными или исправленными вариантами.
2. Обновите секреты и токены#
Исходите из предположения, что данные могли быть украдены. Замените все секреты, токены, учётные данные CI/CD, SSH-ключи, ключи облачных провайдеров и другие чувствительные артефакты, доступные во время работы заражённых пакетов.
3. Проведите аудит CI/CD#
Проверьте GitHub Actions, GitLab CI, Jenkins и другие конвейеры на наличие неожиданных автоматизаций или злоупотреблений OIDC-токенами. Убедитесь, что в пайплайны не были добавлены несанкционированные шаги, и применяйте принцип минимально необходимых привилегий для выдачи токенов.
4. Разделите внутренние и производственные среды#
Поддерживайте логическое разделение внутренних инструментов разработки и производственных систем, чтобы снизить вероятность распространения последствий инцидента.
Подход соответствует рекомендациям, изложенным в нашем материале о переводе артефактов безопасности в операционную практику:
https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
Также полезно обеспечить качественное покрытие тестами и регулярный аудит зависимостей:
https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan
Чего не стоит утверждать без доказательств#
- Нет подтверждений, что вредоносные пакеты напрямую затронули производственные системы клиентов.
- Связь с конкретной группировкой, например TeamPCP, не подтверждена. Вредоносные фреймворки могут повторно использоваться и модифицироваться разными злоумышленниками.
- Полный масштаб возможной компрометации внутренних учётных данных всё ещё расследуется.
Не преувеличивайте уровень угрозы и не заявляйте о подтверждённой эксплуатации там, где доказательств нет. В отчётности по безопасности используйте точные формулировки.
Сравнение рисков: внутренние инструменты и системы клиентов#
| Аспект | Внутренние инструменты | Системы клиентов |
|---|---|---|
| Вектор воздействия | Высокий при установленном пакете | Не подтверждён |
| Риск компрометации учётных данных | Прямой | Косвенный при повторном использовании |
| Срочность исправлений | Немедленно | Не применяется |
| Приоритет аудита | CI/CD и среды разработки | Защищённые производственные системы |
Безопасность open source требует не только контроля исходного кода. В модель рисков стоит включать операционные процессы и защиту артефактов:
https://gigatap.top/en/articles/open-source-security-needs-more-than-code
Вывод#
Инцидент с npm-пакетами Red Hat напоминает, что внутренние инструменты разработки, зависимости и автоматизация CI/CD входят в поверхность атаки наравне с производственными сервисами. Относитесь к подобным уведомлениям безопасности как к приоритетным задачам: ведите учёт зависимостей, регулярно обновляйте секреты, проверяйте пайплайны, разделяйте среды и поддерживайте актуальные защитные механизмы.
FAQ#
Какие пакеты были скомпрометированы?#
Инцидент затронул более 30 npm-пакетов в пространстве имён @redhat-cloud-services. Под компрометацию попали 96 версий пакетов. После выявления проблемы Red Hat удалила их.
Нужно ли считать учётные данные скомпрометированными, если использовались затронутые пакеты?#
Если заражённые пакеты запускались в вашей среде, следует допускать возможность кражи учётных данных. Обновите все секреты и токены, а также проведите полный аудит систем, где эти пакеты были установлены или выполнялись.