Вредоносный код был подписан Red Hat
На этой неделе код, ворующий учётные данные, добрался до разработчиков под именем Red Hat. Угроза пришла не извне Вашего круга доверия — она пришла изнутри. Проверками из этого не выбраться. Но Вы можете держать свои учётные данные вне досягаемости.
На этой неделе код, подписанный Red Hat, пытался украсть Ваши учётные данные.
Злоумышленники получили доступ к аккаунту разработчика Red Hat и опубликовали изменённые версии официальных пакетов Red Hat. Как только машина устанавливала один из них, скрытый код запускался автоматически и хватал всё ценное, что мог найти, — ключи облака, токены доступа, логины, всё, что открывает дверь. Затем он использовал украденное, чтобы распространиться дальше.
Обратите внимание на форму этой атаки. Мишенью был не Red Hat — мишенью были Вы. Их имя, их доверенный аккаунт, конвейер установки, через который Вы проходили тысячу раз, не задумываясь, — всё это не было жертвой. Это было оружием. Атака не проскользнула мимо Вашего круга доверия. Она вошла через парадную дверь с бейджем, который Вы выдали сами себе. Именно это отличает атаки на цепочку поставок от всего остального: опасен не незнакомец, которого можно заблокировать, а поставщик, которому Вы уже решили доверять и который доставляет полезную нагрузку за Вас. И речь о Red Hat — одной из самых зрелых в отношении безопасности компаний, с реальным пересмотром кода и реальным бюджетом. Плохой код всё равно ушёл в свет под их именем.
Отсюда вывод, от которого не уклониться: если Red Hat не может гарантировать, что устанавливаемое Вами у них чистое, никто не может. Не может Ваш фреймворк, не может поставщик CI, не может зависимость на три уровня ниже, которую Вы никогда не читали. Рано или поздно Вы выполните код, который не писали и не могли проверить полностью. Это не сбой процесса — это и есть разработка на чужом программном обеспечении.
Продолжайте сканировать. Продолжайте фиксировать версии. Продолжайте проверять. Всё это стоит делать — только не полагайтесь на это: на этой неделе ничто из этого не помогло бы, вредоносный код пришёл, уже будучи доверенным. Настоящий вопрос не в том, как не допустить плохой код внутрь. Он вот в чём: когда плохой код выполняется на Вашей машине, Вы защитили свои секреты?
Почти для всех честный ответ — нет. Посмотрите, что забрала эта атака: переменные окружения, токены, лежащие в файлах, а затем она подошла к облачным менеджерам секретов и потребовала отдать их содержимое. Так учётные данные живут в 2026 году: свалены в одном месте, в прямой досягаемости всего, что в этот момент выполняется. Одна неудачная установка забирает не один секрет. Она забирает все, а затем распространяется.
Решение — перестать хранить учётные данные там, где их может схватить Ваш код. Держите их на вытянутой руке.
В этом вся идея работы Clavitor. Ваши секреты не живут в окружении; ничего не ждёт чтения в файле .env. Программа — или ИИ-агент — никогда не держит сами учётные данные. Она получает возможность их использовать: они подгружаются заново в момент, когда нужны, — никогда не сохраняются и не кешируются, — из одной из наших 21 точки на шести континентах, так что ближайшая копия всегда в миллисекундах, с областью доступа ровно в рамках одного выданного секрета и с журналом каждого обращения. Когда вредоносный установочный скрипт ощупывает окружение в поисках ключей, он находит пустую комнату.
И мы исходим из того, что учётные данные рано или поздно перехватят, поэтому то, что несёт агент, в случае кражи почти бесполезно. Они работают только с машины, для которой были выданы: перехватите их и запустите с серверов злоумышленника — будет отказано. Действуют ограничения по частоте и контроль: несколько секретов в минуту, так что вычистить Ваше хранилище не получится; стоит лишь выйти за обычную горстку — срабатывает оповещение, и доступ блокируется. Вся стратегия червя — быстро схватить всё и использовать везде — упирается в стену.
Об иммунитете речи не идёт: если учётные данные используются в момент запуска вредоносного кода, именно их могут перехватить — ни одна архитектура не переписывает физику. Но в этом и суть. Атака на Red Hat была разрушительной именно потому, что одна установка могла опустошить целое хранилище секретов и превратить его в оружие. Дистанция на вытянутую руку плюс учётные данные, привязанные к одной машине и ограниченные тонкой струйкой, превращают «они забрали всё и распространились» в «возможно, они перехватили один ключ на лету, и нигде он не сработал». Это и есть расстояние между катастрофой и сноской.
Вредоносный код был подписан Red Hat. Проверками это не одолеть. Исходите из того, что код попадёт внутрь, — и убедитесь, что в этот момент Ваши секреты не лежат перед ним на виду.
(Публично отслеживается как «Miasma» — вариант семейства самораспространяющихся npm-червей Shai-Hulud. Технические разборы заслуживают Вашего времени; этот пост — о той части, которая не меняется от атаки к атаке.)
Источники: