Новая волна червя-инфостилера Shai-Hulud проверяет 469 мест хранения учётных данных. Ранние варианты ограничивались 189 путями: список вырос на 280 позиций, примерно на 148%. Такая прибавка меняет представление об атаке на цепочку поставок ПО. Злоумышленнику необязательно взламывать реестр пакетов или разрушать доверие между участниками разработки. Проще украсть полномочия, на которых это доверие уже держится. Разработчики доверяют реестрам пакетов, компании — сопровождающим ПО, системы CI/CD — переданным им идентификаторам, а приложения — зависимостям, загруженным во время сборки.
Попав в рабочую среду, Shai-Hulud собирает учётные данные, выясняет доступные им системы и использует найденные права для дальнейшего заражения либо распространения вредоносного ПО. Затем цикл повторяется. Токен с ноутбука разработчика открывает исходный код; в коде могут лежать облачные ключи; облачный доступ ведёт к инфраструктуре. Токен GitHub с правом записи позволяет менять другие репозитории, а ключ публикации пакета — выпускать заражённую версию через канал, которому уже доверяют разработчики и сборочные системы. Учётные данные становятся связующим звеном между первой взломанной машиной и следующими целями. Поэтому заражения охватывают разные языки программирования, менеджеры пакетов и операционные системы.
Искать секреты только в репозиториях Git уже поздно. Предсказуемые места вроде файлов.env, истории командной оболочки и конфигураций менеджеров пакетов остаются полезной добычей, но список давно шире. В него входят кэши CLI, настройки CI/CD и IDE, а также конфигурационные файлы инструментов разработки с искусственным интеллектом. Злоумышленники заранее не знают, какой ключ окажется ценнее, поэтому забирают всё подряд и позднее проверяют валидность, владельца, принимающую систему, набор привилегий и доступные ресурсы. Защитникам выгодно действовать в обратном порядке: заранее найти самые опасные полномочия, установить места их хранения и убрать их до заражения.
Первыми под зачистку должны попасть ключи публикации пакетов. Такой ключ превращает обычную кражу секрета в механизм распространения: заражённый пакет автоматически получают разработчики, организации и конвейеры сборки. Долгоживущих токенов публикации должно становиться меньше; вместо них нужны краткосрочная проверяемая аутентификация, OpenID Connect (OIDC) и trusted publishing, то есть доверенная публикация с подтверждением личности рабочей нагрузки. Обновления Docker и GitHub Actions уже ведут экосистему к более строгой аутентификации и расширению trusted publishing. Облачные платформы внедряют федеративные сервисы токенов безопасности; AWS Security Token Service (AWS STS), например, подходит для межплатформенной проверки нагрузок, отправляющих артефакты.
Учётные данные не признают привычного деления на безопасность исходного кода, CI/CD, облака, конечных устройств и приложений. За один рабочий день разработчик может войти в GitHub, npm, AWS, Kubernetes, внутренние API и сборочную инфраструктуру. В конвейере CI/CD набор бывает столь же пёстрым. Секрет, найденный на ноутбуке, способен управлять облачным ресурсом, производственной системой или публикацией пакетов. Место обнаружения говорит лишь о том, где лежала строка; для оценки риска нужны валидность, связанная идентичность, принимающая система, права, достижимая среда и сотрудник, отвечающий за отзыв или ротацию. Это уже управление риском учётных данных, а не простое обнаружение секретов.
Даже 100 000 срабатываний не означают 100 000 одинаково срочных происшествий. Часть ключей истекла, отозвана либо никогда не работала; другие ведут лишь в одноразовую среду разработки. Среди них может затеряться небольшой набор доступов к производственным базам, облачной инфраструктуре, системам развёртывания и публикации пакетов. Одинаковая обработка всех находок создаёт очередь тикетов, а не снижение риска. Рабочий вопрос звучит проще: «Какие учётные данные злоумышленник выбрал бы первыми?» Именно этот ответ должен задавать порядок работ.
Авторам и сопровождающим пакетов следует найти каждое место, где сохраняются токены публикации, и проверить, нужны ли вообще постоянные ключи. Поиск обязан выходить за пределы Git: обычные инструменты разработки записывают данные аутентификации в локальные конфигурационные файлы, а вредоносная программа на рабочей станции читает их без всякого коммита. Отсюда и интерес атакующих к действующей среде разработчика. Практический принцип здесь суров: «Труднее всего украсть тот ключ публикации, которого не существует». Если статический секрет пока нельзя убрать, он должен обнаруживаться средствами контроля, проходить проверку, иметь владельца, находиться под наблюдением и ротироваться после раскрытия. Разработчики знают устройство сборки и выпуска, служба безопасности видит распространение секретов и задаёт правила; поодиночке задача не решается.
После издательских ключей идут действующие доступы к производству. Изолированная тестовая среда обычно ограничивает ущерб, тогда как право записи в производственную инфраструктуру означает серьёзный инцидент. Внутренняя иерархия должна начинаться с производственных аккаунтов облака, баз с клиентскими данными, инфраструктуры цифровой подписи, кластеров Kubernetes, инструментов развёртывания и административных интерфейсов. Одной проверки валидности мало: требуется оценить радиус поражения и спросить, «Что произойдёт, если похищенный доступ используют во вред?» Ответ покажет, какой долговременный ключ следует удалить, а какой хотя бы немедленно отозвать или сменить.
Повторное использование секретов прокладывает незаметные дороги между разработкой, staging-средой, автоматизацией и производством. Ключ, обнаруженный в staging, порой принимается производственной системой; токен, скопированный в локальную среду разработчика, сохраняет права, выданные когда-то роботу автоматизации. Один и тот же секрет годами всплывает в разных системах, хотя исходное назначение давно забыто. Сигнал сканера без контекста мало полезен: находку нужно связать с идентичностью, привилегиями, ресурсами, рабочими средами и владельцем. Части этой картины обычно разбросаны между DevOps, платформенной командой, Identity and Access Management (IAM) и службой безопасности.
Масштаб не оставляет надежды на ручной разбор. В 2025 году в публичные коммиты GitHub добавили 65 миллионов новых жёстко прописанных секретов, на 34% больше, чем годом ранее. Сначала следует автоматически установить, работает ли найденный ключ, но валидность — лишь фильтр. Действующий доступ к общей среде разработки и административный доступ к производственному аккаунту AWS требуют разной реакции. Для каждой находки нужны проверяемые ответы: какую идентичность она представляет, какими правами обладает, ведёт ли в production, staging или development, какие ресурсы открывает, где ещё используется, кто ею владеет и кто вправе её отозвать. Так бесформенный массив утечек превращается в очередь, отсортированную по реальному ущербу.
Постоянная программа начинается с инвентаризации исходного кода, истории Git, CI/CD, рабочих сред разработчиков и прочих мест, где оседает материал аутентификации. Её главный вопрос: «Где сейчас существует повторно используемое полномочие?» Проверки должны быть аудируемыми и охватывать больше, чем известные секреты в secrets vault, то есть хранилище секретов. Полезная метрика — доля ключей, оставшихся за пределами vault. Бесхозные открытые секреты быстро ломают систему контроля при росте компании. Затем находки ранжируются по валидности, среде, идентичности, привилегиям, владельцу, доступным ресурсам и повторному использованию.
Новые жёстко прописанные секреты нужно блокировать до попадания в код, рабочие процессы переводить на краткосрочные полномочия, а локальные среды разработчиков защищать и регулярно проверять. Рабочий цикл формулируется как «обнаружение, устранение и предотвращение», а не как разовая уборка после инцидента. Следующий вариант Shai-Hulud, вероятно, выйдет за нынешние 469 мест, добавив пути новых инструментов разработчика. Перечислять их наперегонки с авторами инфостилера бессмысленно: задача защиты — сокращать постоянные привилегии и количество повторно используемых ключей, которые очередная волна сможет забрать.
Попав в рабочую среду, Shai-Hulud собирает учётные данные, выясняет доступные им системы и использует найденные права для дальнейшего заражения либо распространения вредоносного ПО. Затем цикл повторяется. Токен с ноутбука разработчика открывает исходный код; в коде могут лежать облачные ключи; облачный доступ ведёт к инфраструктуре. Токен GitHub с правом записи позволяет менять другие репозитории, а ключ публикации пакета — выпускать заражённую версию через канал, которому уже доверяют разработчики и сборочные системы. Учётные данные становятся связующим звеном между первой взломанной машиной и следующими целями. Поэтому заражения охватывают разные языки программирования, менеджеры пакетов и операционные системы.
Искать секреты только в репозиториях Git уже поздно. Предсказуемые места вроде файлов.env, истории командной оболочки и конфигураций менеджеров пакетов остаются полезной добычей, но список давно шире. В него входят кэши CLI, настройки CI/CD и IDE, а также конфигурационные файлы инструментов разработки с искусственным интеллектом. Злоумышленники заранее не знают, какой ключ окажется ценнее, поэтому забирают всё подряд и позднее проверяют валидность, владельца, принимающую систему, набор привилегий и доступные ресурсы. Защитникам выгодно действовать в обратном порядке: заранее найти самые опасные полномочия, установить места их хранения и убрать их до заражения.
Первыми под зачистку должны попасть ключи публикации пакетов. Такой ключ превращает обычную кражу секрета в механизм распространения: заражённый пакет автоматически получают разработчики, организации и конвейеры сборки. Долгоживущих токенов публикации должно становиться меньше; вместо них нужны краткосрочная проверяемая аутентификация, OpenID Connect (OIDC) и trusted publishing, то есть доверенная публикация с подтверждением личности рабочей нагрузки. Обновления Docker и GitHub Actions уже ведут экосистему к более строгой аутентификации и расширению trusted publishing. Облачные платформы внедряют федеративные сервисы токенов безопасности; AWS Security Token Service (AWS STS), например, подходит для межплатформенной проверки нагрузок, отправляющих артефакты.
Учётные данные не признают привычного деления на безопасность исходного кода, CI/CD, облака, конечных устройств и приложений. За один рабочий день разработчик может войти в GitHub, npm, AWS, Kubernetes, внутренние API и сборочную инфраструктуру. В конвейере CI/CD набор бывает столь же пёстрым. Секрет, найденный на ноутбуке, способен управлять облачным ресурсом, производственной системой или публикацией пакетов. Место обнаружения говорит лишь о том, где лежала строка; для оценки риска нужны валидность, связанная идентичность, принимающая система, права, достижимая среда и сотрудник, отвечающий за отзыв или ротацию. Это уже управление риском учётных данных, а не простое обнаружение секретов.
Даже 100 000 срабатываний не означают 100 000 одинаково срочных происшествий. Часть ключей истекла, отозвана либо никогда не работала; другие ведут лишь в одноразовую среду разработки. Среди них может затеряться небольшой набор доступов к производственным базам, облачной инфраструктуре, системам развёртывания и публикации пакетов. Одинаковая обработка всех находок создаёт очередь тикетов, а не снижение риска. Рабочий вопрос звучит проще: «Какие учётные данные злоумышленник выбрал бы первыми?» Именно этот ответ должен задавать порядок работ.
Авторам и сопровождающим пакетов следует найти каждое место, где сохраняются токены публикации, и проверить, нужны ли вообще постоянные ключи. Поиск обязан выходить за пределы Git: обычные инструменты разработки записывают данные аутентификации в локальные конфигурационные файлы, а вредоносная программа на рабочей станции читает их без всякого коммита. Отсюда и интерес атакующих к действующей среде разработчика. Практический принцип здесь суров: «Труднее всего украсть тот ключ публикации, которого не существует». Если статический секрет пока нельзя убрать, он должен обнаруживаться средствами контроля, проходить проверку, иметь владельца, находиться под наблюдением и ротироваться после раскрытия. Разработчики знают устройство сборки и выпуска, служба безопасности видит распространение секретов и задаёт правила; поодиночке задача не решается.
После издательских ключей идут действующие доступы к производству. Изолированная тестовая среда обычно ограничивает ущерб, тогда как право записи в производственную инфраструктуру означает серьёзный инцидент. Внутренняя иерархия должна начинаться с производственных аккаунтов облака, баз с клиентскими данными, инфраструктуры цифровой подписи, кластеров Kubernetes, инструментов развёртывания и административных интерфейсов. Одной проверки валидности мало: требуется оценить радиус поражения и спросить, «Что произойдёт, если похищенный доступ используют во вред?» Ответ покажет, какой долговременный ключ следует удалить, а какой хотя бы немедленно отозвать или сменить.
Повторное использование секретов прокладывает незаметные дороги между разработкой, staging-средой, автоматизацией и производством. Ключ, обнаруженный в staging, порой принимается производственной системой; токен, скопированный в локальную среду разработчика, сохраняет права, выданные когда-то роботу автоматизации. Один и тот же секрет годами всплывает в разных системах, хотя исходное назначение давно забыто. Сигнал сканера без контекста мало полезен: находку нужно связать с идентичностью, привилегиями, ресурсами, рабочими средами и владельцем. Части этой картины обычно разбросаны между DevOps, платформенной командой, Identity and Access Management (IAM) и службой безопасности.
Масштаб не оставляет надежды на ручной разбор. В 2025 году в публичные коммиты GitHub добавили 65 миллионов новых жёстко прописанных секретов, на 34% больше, чем годом ранее. Сначала следует автоматически установить, работает ли найденный ключ, но валидность — лишь фильтр. Действующий доступ к общей среде разработки и административный доступ к производственному аккаунту AWS требуют разной реакции. Для каждой находки нужны проверяемые ответы: какую идентичность она представляет, какими правами обладает, ведёт ли в production, staging или development, какие ресурсы открывает, где ещё используется, кто ею владеет и кто вправе её отозвать. Так бесформенный массив утечек превращается в очередь, отсортированную по реальному ущербу.
Постоянная программа начинается с инвентаризации исходного кода, истории Git, CI/CD, рабочих сред разработчиков и прочих мест, где оседает материал аутентификации. Её главный вопрос: «Где сейчас существует повторно используемое полномочие?» Проверки должны быть аудируемыми и охватывать больше, чем известные секреты в secrets vault, то есть хранилище секретов. Полезная метрика — доля ключей, оставшихся за пределами vault. Бесхозные открытые секреты быстро ломают систему контроля при росте компании. Затем находки ранжируются по валидности, среде, идентичности, привилегиям, владельцу, доступным ресурсам и повторному использованию.
Новые жёстко прописанные секреты нужно блокировать до попадания в код, рабочие процессы переводить на краткосрочные полномочия, а локальные среды разработчиков защищать и регулярно проверять. Рабочий цикл формулируется как «обнаружение, устранение и предотвращение», а не как разовая уборка после инцидента. Следующий вариант Shai-Hulud, вероятно, выйдет за нынешние 469 мест, добавив пути новых инструментов разработчика. Перечислять их наперегонки с авторами инфостилера бессмысленно: задача защиты — сокращать постоянные привилегии и количество повторно используемых ключей, которые очередная волна сможет забрать.