У Red Hat случился неприятный и показательный сбой в том месте, где компания сама обещала навести порядок. В npm-namespace @redhat-cloud-services обнаружили 32 скомпрометированных пакета и 96 заражённых версий, а значит атака на npm затронула не абстрактный open source где-то в стороне, а одного из самых заметных поставщиков корпоративного ПО. Для русскоязычных команд это сигнал простой: если вредоносный код спокойно доезжает до пайплайна Red Hat, значит проверять собственные CI/CD-контуры и секреты пора без самоуспокоения.
Об инциденте, как пишет ZDNet, первой подробно сообщила исследовательская компания Aikido. По её данным, заражённые версии суммарно скачивали около 116 991 раза в неделю. Речь идёт о JavaScript-пакетах из пространства имён Red Hat, которые использовались как фронтенд-библиотеки и затем собирались в контейнерные образы в процессе продуктовой сборки. По версии Red Hat, злоумышленник получил доступ через скомпрометированный GitHub-аккаунт и внедрил вредоносный код в пакеты, поддерживаемые в GitHub-организации компании. Сами пакеты уже удалены из npm, а Red Hat заявляет, что код не попал в клиентские поставки через console.redhat.com и не затронул production-системы компании, партнёров и заказчиков.
Технически схема атаки выглядела до боли знакомо для всех, кто следит за supply-chain угрозами в JavaScript. Во вредоносные версии добавили preinstall hook: то есть при обычном npm install на машине разработчика или на CI-агенте автоматически исполнялся посторонний код. По данным Microsoft Threat Intelligence, каждый такой пакет содержал раздутый и сильно обфусцированный загрузчик index.js, который подтягивал следующий этап полезной нагрузки. Дальше malware искал и пытался вывести наружу всё, до чего мог дотянуться: токены npm, GitHub и CircleCI, SSH-ключи, AWS-, GCP- и Azure-учётные данные, Kubernetes-конфиги, токены HashiCorp Vault и другие секреты из переменных окружения и конфигурационных файлов.
Отдельно неприятно то, что это был не просто инфостилер. Исследователи связали кампанию с червём Mini Shai-Hulud, который уже фигурировал в прежних инцидентах в npm. В случае с Red Hat несколько отчётов называют новую вариацию Miasma: она сохраняет способность к самораспространению, но работает более хитро за счёт многоступенчатой загрузки и дополнительной обфускации. Если заражённый код запускался в окружении, где у пользователя были права на публикацию других npm-пакетов, червь пытался переопубликовать и их, уже со своим preinstall-пейлоадом. Иными словами, каждая новая жертва могла автоматически стать следующей точкой атаки. Именно эта «червеобразность», по оценке исследователей, позволила очень быстро загрязнить namespace Red Hat: некоторые оценки говорят, что более 30 пакетов были заражены буквально за минуты.
Контекст добавляет инциденту почти театральной иронии. За несколько дней до этого IBM и Red Hat объявили Project Lightwell, инициативу с ИИ-компонентом для поиска и исправления уязвимостей в open-source ПО. На словах всё выглядело как масштабный план по оздоровлению экосистемы, тем более на фоне регулярных разговоров о том, что безопасность open source давно не поспевает за его ролью в корпоративной разработке. И тут же сама Red Hat получает удар по цепочке поставок через npm, одну из самых проблемных площадок по части доверия к пакетам. Это не отменяет значимости Project Lightwell, но точно убирает иллюзию, что большие бренды находятся над схваткой и защищены по факту размера.
Есть и ещё один важный маркер: по данным Semgrep и других исследователей, вредоносные пакеты могли быть опубликованы с использованием GitHub Actions OpenID Connect-токенов, связанных с репозиторием RedHatInsights/javascript-clients. При этом изменения в npm не всегда сопровождались видимыми изменениями в публичных исходниках. Для специалистов по AppSec и платформенной инженерии это почти учебный пример компрометации сборочного контура: репозиторий выглядит относительно чисто, а заражение живёт на стыке CI, публикации артефактов и доверенных токенов. Если ваша команда до сих пор считает, что защита Git-репозитория и защита реального релизного конвейера — примерно одно и то же, инцидент у Red Hat показывает обратное довольно наглядно.
Практический вывод для разработчиков и бизнеса здесь несложный, просто неприятный. Если в вашей инфраструктуре когда-либо использовались пакеты из @redhat-cloud-services, инцидент надо рассматривать не как новость про чужую компанию, а как возможную компрометацию собственных секретов. Безопасники прямо рекомендуют считать, что токены и ключи из соответствующих окружений могли утечь. Значит, базовый минимум — срочная ротация GitHub PAT, SSH-ключей, облачных API-ключей и CI-токенов, аудит активности в GitHub и облаках на предмет подозрительных обращений, а также пересборка потенциально загрязнённых окружений из доверенного базового состояния. Параллельно стоит проверить деревья зависимостей, заблокировать известные плохие релизы и, где нужно, откатиться на проверенные сборки или заменить пакеты.
Для руководителей разработки и IT-директоров здесь тоже есть неприятный, но полезный урок. Жёсткое pinning версий, внутренние зеркала и разговоры про «мы не тянем пакеты напрямую в production» снижают риск, но не спасают, если заражение произошло в девелоперском контуре, а затем пошло гулять через секреты и права публикации. Supply-chain безопасность уже давно не сводится к SCA-сканеру в CI и редкому аудиту зависимостей. Она упирается в то, кто и какими токенами публикует пакеты, какие разрешения получает GitHub Actions, где лежат облачные ключи, насколько быстро команда умеет отозвать учётные данные и пересобрать среду без ручной магии по ночам.
Атака на npm в истории с Red Hat вряд ли станет последней и точно не останется частным курьёзом одного вендора. Чем сильнее индустрия завязана на автоматическую сборку из чужих пакетов, тем дороже становится любая дыра между репозиторием, CI/CD и хранилищем секретов. Вопрос уже не в том, случится ли следующий похожий эпизод, а в том, сколько компаний по-прежнему уверены, что компрометация зависимостей — это проблема кого-то из новостей, а не их собственной инфраструктуры.