GitHub отключил 73 репозитория Microsoft после признаков заражения червем Miasma, и это сразу превратилось не только в историю про безопасность, но и в историю про отказоустойчивость. Атака на GitHub ударила по зависимостям, на которых держались рабочие CI/CD-пайплайны, так что для многих команд инцидент выглядел не как абстрактная supply chain-угроза, а как вполне прикладное «почему у нас внезапно не деплоится».
По данным The Register, срабатывание защитных механизмов произошло в пятницу, 5 июня: GitHub отключил десятки репозиториев за 105 секунд после того, как внутренние сигналы показали признаки заражения. Исследовательскую картину публично описал сооснователь и CTO StepSecurity Ашиш Курми. По его версии, точкой входа стал скомпрометированный аккаунт контрибьютора, который отправил вредоносный коммит в репозиторий Azure/durabletask.
Ключевая деталь в том, что вредоносный код не просто жил в репозитории «для галочки». В коммите появились конфигурационные файлы, которые могли запускать удаленное выполнение кода на машине разработчика в тот момент, когда тот открывал репозиторий в IDE или в AI-инструментах для программирования, включая Claude Code, Gemini CLI и Cursor. Это уже не старый сюжет про зараженный пакет, который кто-то когда-нибудь поставит на CI. Здесь достаточно было обычного рабочего действия: открыть репозиторий и начать с ним работать.
Параллельно начали ломаться и пайплайны. По словам Курми, особенно быстро проблему почувствовали пользователи Azure/functions-action — GitHub Action, которую применяют для деплоя в Azure. После отключения репозитория все workflow, ссылавшиеся на Azure/functions-action@v1, перестали нормально резолвиться. То есть атака на GitHub зацепила не только машины разработчиков, но и типичный производственный контур: сборки, выкладки, автоматизацию. Именно поэтому инцидент выглядит болезненно даже для тех, кто привык считать supply chain-риски делом security-команды и редких постмортемов по пятницам.
Сам по себе Miasma появился не на пустом месте. The Register связывает нынешний эпизод с атакой от 19 мая, когда под удар уже попадал пакет durabletask в PyPI. Тогда в течение 35 минут в каталог загрузили три версии пакета, которые устанавливали инфостилеры на машины разработчиков. Цель была довольно приземленной: искать облачные секреты и конфигурации инструментов разработки, причем особенно на Linux-системах. Новый удар по durabletask намекает, что история либо не была до конца закрыта, либо противник очень быстро восстановил доступ.
У StepSecurity на этот счет несколько версий, и все неприятные. Первая: токены, связанные со скомпрометированным аккаунтом, после майского инцидента не были полностью отозваны и перевыпущены. Вторая: сам контрибьютор мог быть заражен повторно через механизм распространения червя. Третья: злоумышленник использовал токен другого участника, но подправил метаданные так, чтобы атака выглядела как продолжение прежней кампании. Для корпоративной практики вывод здесь скучный, но полезный: ротация секретов «для отчета» и реальная ликвидация доступа — это разные вещи, и атакующие хорошо знают разницу.
Есть и более широкий контекст. По оценке Snyk, Miasma — потомок червя Mini Shai Hulud, который уже успел отметиться в экосистеме npm. За разработкой Mini Shai Hulud связывали группу TeamPCP, но затем она выложила его в открытый доступ, и после этого вопрос авторства стал почти академическим: когда код червя открыт, продолжателей хватает. За два дня до инцидента с Microsoft тот же Miasma, по данным StepSecurity, успел скомпрометировать более 50 npm-пакетов, включая SDK компании Vapi.ai с более чем 408 тысячами ежемесячных загрузок. Иными словами, речь уже не о единичной атаке на конкретный бренд, а о шаблоне, который переезжает между экосистемами, меняя упаковку, но не цель.
Для русскоязычных команд разработки в этой истории важны не только громкие имена вроде Microsoft и GitHub. Важна механика. Репозиторий давно перестал быть просто местом хранения кода. В нем живут workflow, action-зависимости, конфиги для IDE, скрипты для локального запуска и интеграции с AI-ассистентами. Если злоумышленник получает доступ туда, он бьет сразу по нескольким слоям: разработчик, CI/CD, облачные ключи, цепочка публикации пакетов. Атака на GitHub в 2026 году — это уже не про «кто-то подменил один файл», а про то, как одна компрометация начинает ходить по инженерному контуру как по офису без турникетов.
Отдельный неприятный штрих — скорость и асимметрия. GitHub, если верить описанию инцидента, после срабатывания детектов действовал быстро и отключил репозитории двумя волнами менее чем за две минуты. Но этого все равно хватило, чтобы разработчики заметили последствия, а рабочие процессы сломались. Защита платформы здесь напоминает аварийный рубильник: он нужен и иногда спасает, но когда его дергают, в темноте остаются и злоумышленники, и вполне легитимные команды. Поэтому бизнесу придется внимательнее относиться не только к безопасности исходников, но и к тому, насколько критичные процессы завязаны на внешние репозитории и action-цепочки без запасного маршрута.
Главный вопрос после этого инцидента не в том, сумеют ли платформы быстрее банить зараженные репозитории. С этим у них уже более-менее получается. Вопрос в другом: смогут ли команды перестроить практики так, чтобы компрометация одного аккаунта, одного action-репозитория или одного пакета не превращалась в каскад от локальной машины разработчика до облачной инфраструктуры. Пока экосистема движется в противоположную сторону — больше автоматизации, больше доверия к внешним компонентам, больше AI-инструментов в повседневной разработке. А значит, supply chain-атаки будут становиться не реже, а только ближе к продакшену.