Червь Shai-Hulud в новой версии ищет учетные данные уже в 469 локациях вместо прежних 189. Для разработчиков, DevOps-команд и компаний, которые живут на GitHub, CI/CD и облаках, это плохая, но полезная новость: злоумышленникам все чаще не нужно ломать доверенные цепочки поставки, им достаточно забрать токены, на которых эти цепочки и держатся.
Речь идет о варианте инфостилера, который в начале августа обнаружили исследователи GitGuardian, сообщает The Hacker News. По их наблюдениям, вредонос теперь проверяет не только привычные места вроде .env, shell history и конфигов пакетных менеджеров, но и кэши CLI, настройки IDE, CI/CD-конфигурации, облачные профили и даже файлы конфигурации AI-инструментов для разработки. Сам скачок с 189 до 469 путей выглядит не как косметическое обновление, а как честное признание рынка: рабочая машина разработчика давно стала складом ключей от половины инфраструктуры.
Логика атаки проста и от этого неприятна. Один украденный токен с ноутбука разработчика может открыть доступ к исходникам. В репозитории или рядом с ним часто находятся другие секреты, уже для облака, внутренних API, Kubernetes или пайплайнов сборки. Токен GitHub с правом записи позволяет двигаться по другим репозиториям, а учетные данные для публикации пакета превращают заражение в полноценную атаку на software supply chain: вредоносный код можно доставить через канал, которому экосистема уже привыкла доверять. Иначе говоря, секреты здесь работают как связующая ткань между разными системами, которые бизнес обычно считает отдельными зонами защиты.
Именно поэтому новый червь Shai-Hulud важен не столько как очередной инфостилер, сколько как симптом. Атакующие сместили фокус: вместо того чтобы дорого и шумно ломать trust relationships, они все чаще используют уже выданные полномочия. Это хорошо укладывается в тренд последних лет, когда атаки на цепочки поставки все чаще стартуют не с компрометации реестра пакетов или зависимости как таковой, а с банального похищения секрета в рабочем окружении. Плохая новость для компаний в том, что такой секрет может лежать не в Git и не в проде, а в локальном конфиге, который разработчик когда-то сохранил «на пять минут» и забыл.
Почему ключевая цель теперь не код, а права на публикацию
В исходном материале отдельно подчеркивается ценность publishing credentials, и это, пожалуй, самый практичный вывод для индустрии. Ключ публикации npm-пакета, контейнера или другого артефакта ценнее многих других секретов, потому что он дает злоумышленнику не просто доступ, а канал распространения. Если атакующий получает право публиковать обновления от имени доверенного поставщика, заражение начинает жить своей жизнью: артефакты автоматически подтягивают разработчики, CI-системы и корпоративные сборки. В такой схеме токен публикации превращается в инфраструктурный секрет первого класса, хотя во многих командах с ним до сих пор обращаются как с технической мелочью из локального конфига.
Отсюда и главный совет, который в статье звучит без лишней драматизации: длинноживущие publishing tokens надо либо убирать совсем, либо жестко ограничивать. Там, где экосистема это поддерживает, логичным вариантом выглядит переход на короткоживущую, верифицируемую аутентификацию через OIDC и похожие механизмы trusted publishing. В качестве примеров упомянуты недавние изменения в Docker и GitHub Actions, а также общий поворот облачных платформ в сторону федеративных токен-сервисов вроде AWS STS. Смысл довольно прозаичный: самый надежный секрет для защиты от инфостилера тот, которого нет в открытом виде на машине разработчика и который нельзя переиспользовать через неделю или месяц.
Для служб безопасности здесь тоже неприятный, но полезный вывод. Делить защиту на безопасность исходников, безопасность CI/CD, облачную безопасность и endpoint security удобно для оргструктуры, но секреты эти границы не уважают. Один и тот же инженер в течение обычного рабочего дня ходит в GitHub, npm, AWS, Kubernetes, внутренние сервисы и сборочную инфраструктуру. Пайплайны делают то же самое, только без сна и с более широкими правами. Поэтому обнаружить секрет в файле на ноутбуке мало. Нужно понимать, действителен ли он, к какой идентичности привязан, какие права дает, до какой среды дотягивается и кто отвечает за его отзыв. Иначе сканирование секретов быстро превращается в бесконечную очередь алертов без внятного снижения риска.
Что с этим делать разработчикам и бизнесу
Хорошая новость ровно одна: приоритеты здесь понятны. Не все найденные секреты одинаково опасны. Тысячи старых, уже инвалидированных ключей шумят в отчетах, но не обязательно создают инцидент. Несколько живых токенов с правом публикации пакетов, доступа к продовым облачным ресурсам или deployment-системам значат куда больше. Поэтому зрелая реакция на такие истории начинается не с тотальной паники и не с очередного «запретить хранить секреты в файлах», а с инвентаризации самых опасных классов учетных данных. Командам стоит искать publishing credentials не только в репозиториях, но и в локальных конфигурациях, кэшах CLI, настройках IDE и пайплайнах. Если токен нельзя убрать, он должен быть учтен, привязан к владельцу, мониториться и быстро ротироваться при утечке.
Для российских команд, особенно тех, кто развивает собственные SDK, пакеты, контейнеры и внутренние платформы, история с червем Shai-Hulud звучит предельно приземленно. Чем сильнее компания автоматизирует поставку кода и чем больше живет на self-service для разработчиков, тем выше цена одного небрежно оставленного секрета. Следующий виток атак на supply chain, похоже, будет мериться не экзотичностью эксплойтов, а тем, сколько реальных полномочий осталось лежать в открытом виде между ноутбуком, IDE, агентом CI и облачным аккаунтом.