Не менее 70 репозиториев Microsoft на GitHub оказались недоступны после инцидента, который уже выглядит как серьезный взлом репозиториев Microsoft. Для разработчиков это плохая новость не только потому, что речь идет об Azure и AI-инструментах: в скомпрометированный код, по данным исследователей, подмешали вредоносные компоненты для кражи паролей и других учетных данных.
О случившемся сообщает TechCrunch. По информации издания, Microsoft временно закрыла доступ к десяткам open source-проектов на GitHub, пока разбирается, как злоумышленники смогли внедрить вредоносный код в репозитории компании. Под удар попали проекты, связанные с облачной платформой Azure, а также инструменты, которыми пользуются разработчики, работающие с AI-средами и AI-ассистентами для написания кода, включая Claude Code, командный интерфейс Gemini и VS Code.
Первыми тревогу подняли компания Cloudsmith и площадка OpenSourceMalware, где сообщество анализирует вредоносные пакеты и зараженный open source-код. По их оценке, зараженные компоненты позволяли атакующим красть пароли и другие чувствительные данные в тот момент, когда пользователь открывал скомпрометированные инструменты в AI-приложениях для разработки. Сколько именно разработчиков успели скачать зараженный код, пока неизвестно. Microsoft этого не раскрывает. Представитель компании Бен Хоуп подтвердил, что часть репозиториев была снята с публикации на время проверки: некоторые уже вернули в доступ, остальные остаются офлайн, пока расследование продолжается.
Отдельно Microsoft признала, что уведомила небольшое число клиентов, которые могли скачать содержимое из затронутых репозиториев. Формулировка аккуратная, но для инженеров и ИТ-руководителей она читается довольно прямо: если ваша команда тянула код или зависимости из этих проектов, проверка нужна уже сейчас, а не после красивого постмортема. Тем более что речь идет о типичной атаке на цепочку поставок, когда злоумышленники не ломятся в инфраструктуру жертвы в лоб, а заражают популярный код, откуда он сам разъезжается по рабочим машинам, CI/CD-контурам и внутренним сервисам.
В этой истории особенно неприятен выбор цели. Обычно supply chain-атаки обсуждают применительно к небольшим open source-проектам, где один-два мейнтейнера могут месяцами не замечать чужую активность или банально не вывезти полноценную защиту. Здесь все иначе: под ударом оказались проекты Microsoft, то есть компании, которая не только располагает ресурсами для защиты своей open source-инфраструктуры, но и владеет самим GitHub. Это не делает атаку более драматичной в голливудском смысле, зато отлично показывает практическую вещь: размер вендора не отменяет базовую проблему доверия к цепочке доставки кода.
Есть и еще один слой. По данным Ars Technica, это уже второй известный эпизод за последние недели, когда злоумышленники компрометируют open source-проекты Microsoft. В середине мая исследователи безопасности сообщали о взломе Durable Task, проекта для разработки приложений. Теперь OpenSourceMalware прямо называет новый инцидент re-compromise того же Durable Task. Проще говоря, либо атакующие не были полностью вытеснены после первой зачистки, либо мы видим отдельный повторный взлом. Оба варианта для Microsoft выглядят одинаково некомфортно. В первом случае вопрос к качеству реагирования, во втором — к устойчивости процессов защиты и контроля изменений.
Для русскоязычной ИТ-аудитории эта история важна не как еще один повод пошутить про безопасность в корпорациях масштаба Big Tech. Взлом репозиториев Microsoft бьет ровно по тому стеку, который давно стал рутиной в продуктовых командах: разработчик тянет open source-проект, открывает его в привычной AI-среде, подключает облачные токены, запускает локальную отладку, а дальше секреты начинают жить своей жизнью. Если вредоносный код действительно был нацелен на кражу паролей и учетных данных, риски выходят далеко за пределы одной рабочей станции. Это уже вопрос доступа к облакам, внутренним репозиториям, интеграциям и данным клиентов.
Что из этого следует на практике. Во-первых, даже крупные и вроде бы проверенные репозитории нельзя воспринимать как доверенную зону только потому, что у них известный логотип. Во-вторых, командам, которые используют инструменты Microsoft для Azure и AI-разработки, стоит поднять журналы загрузок и сборок за последние недели и проверить, не подтягивался ли код из отключенных репозиториев. В-третьих, если такие проекты открывались в AI-инструментах с доступом к токенам, API-ключам и облачным credential-файлам, разумный минимум — ротация секретов, ревизия прав и проверка рабочих станций разработчиков. Звучит скучно, но в новостях про supply chain именно скучные действия потом спасают от очень нескучного ущерба.
На более широком уровне инцидент показывает, как меняется профиль риска вокруг AI-разработки. Чем больше инструментов умеют подхватывать локальный контекст, конфиги, ключи и репозитории ради удобства программиста, тем выше цена компрометации даже небольшого куска кода в привычной цепочке работы. Open source никуда не денется, AI-ассистенты для кода тоже, а значит главный вопрос теперь не в том, случится ли следующая такая атака, а в том, какие команды успеют перестроить контроль зависимостей и работу с секретами до того, как очередной зараженный репозиторий снова окажется в их пайплайне.