Shai-Hulud начал искать секреты в 469 расположениях
Исследователи GitGuardian в начале августа обнаружили вариант инфостилера-червя Shai-Hulud, который ищет учётные данные в 469 расположениях. Ранние версии проверяли 189 путей. Новый перечень охватывает среды разработки, инструменты CI/CD, облачные конфигурации и настройки ИИ-инструментов.
Shai-Hulud ориентирован не только на первоначальное проникновение. Найденные токены и ключи помогают продолжать атаку в связанных системах: доступ к рабочей станции разработчика может открыть исходный код, токен GitHub — права записи в другие репозитории, а учётные данные для публикации пакета — канал распространения ПО, которому доверяют разработчики и сборочные системы.
Почему ключи публикации особенно опасны
Учётные данные для публикации пакетов дают право выпускать артефакты через доверенный реестр. Поэтому их кража способна превратить компрометацию одной среды в дальнейшее распространение по цепочке поставок. GitGuardian рекомендует в первую очередь найти такие токены и сократить число постоянно действующих ключей.
Секреты могут находиться не только в репозиториях. Вредоносная программа способна обнаружить их в файлах .env, истории командной оболочки, конфигурации менеджеров пакетов, кэшах CLI, настройках IDE и CI/CD. Ключ, не попавший в Git, всё равно доступен вредоносному ПО на компьютере разработчика.
Краткоживущая аутентификация вместо постоянных токенов
Для операций публикации GitGuardian предлагает переходить к краткоживущим механизмам, привязанным к проверяемой идентичности, включая OIDC. В материале отмечены обновления Docker и GitHub Actions, направленные на усиление аутентификации и использование trusted publishing. Облачные платформы также развивают федеративные сервисы токенов, такие как AWS STS.
Если статический ключ пока нельзя заменить, его следует учитывать, проверять на действительность, закреплять за владельцем, отслеживать и менять при обнаружении утечки. Разработчики знают процесс сборки и выпуска пакетов, а специалисты по безопасности определяют политики и выявляют раскрытые учётные данные; эта работа требует участия обеих сторон.
Как расставлять приоритеты при устранении утечек
После ключей публикации первыми стоит рассматривать действующие доступы к критичным production-системам: облачным аккаунтам, базам данных с клиентской информацией, инфраструктуре подписи, кластерам Kubernetes, средствам развёртывания и административным интерфейсам. Сам факт обнаружения секрета не показывает его реальный риск: важно установить, действует ли он, с какой идентичностью связан, какие права имеет и к каким ресурсам ведёт.
GitGuardian приводит масштаб проблемы: в 2025 году в публичные коммиты GitHub попало 28,65 млн новых жёстко прописанных секретов, что на 34% больше год к году. При таком объёме невозможно одинаково срочно обрабатывать все находки. Действующий ключ с административными правами в production требует иной реакции, чем доступ к изолированной тестовой среде.
Практический вывод для бизнеса — выстроить постоянный цикл обнаружения, устранения и предотвращения утечек. Инвентаризация должна включать код, историю Git, CI/CD и рабочие среды разработчиков, а очередь исправлений — учитывать действительность ключа, среду, полномочия, ресурсы и владельца. Это помогает уменьшать число доступных для кражи постоянных привилегий до появления следующего варианта червя.