Red Hat скомпрометировали через npm — что это значит для нас
Злоумышленники опубликовали десятки зараженных пакетов в официальной экосистеме @redhat-cloud-services через новый вариант червя Shai-Hulud. Это не просто инцидент — это сигнал о том, насколько уязвима цепочка поставок в enterprise-сегменте. Атака на цепочку поставок — это когда компрометируют не вашу инфраструктуру напрямую, а доверенные зависимости. В случае с Red Hat злоумышленники получили доступ к инфраструктуре публикации и залили вредоносный код в официальные пакеты. Проблема в том, что эти библиотеки уже в production у тысяч компаний. Что делать прямо сейчас: проверить зависимости проектов на наличие пакетов @redhat-cloud-services, обновлённых в последние недели. Если находите — изолировать, проверить хеши, откатить на предыдущие версии. Не полагайтесь на автоматические обновления — даже у крупных вендоров случается такое. Долгосрочно: внедряйте Software Bill of Materials (SBOM), используйте инструменты для проверки целостности пакетов (например, Sigstore), настраивайте приватные зеркала для критичных зависимостей. Да, это накладные расходы. Но цена компрометации production через библиотеку — на порядки выше. 🔒 Мы после нескольких инцидентов в экосистеме (Log4Shell, event-stream) перешли на жёсткий контроль зависимостей: автоматическая проверка при сборке, ручной апрув для новых библиотек, закреплённые версии с периодическим аудитом. Замедляет разработку? Да. Но сон спокойнее. Вопрос к комментариям: как у вас организован контроль зависимостей в production? Проверяете целостность пакетов перед развёртыванием или доверяете публичным репозиториям?