Инцидент в GitHub сначала мог выглядеть как локальная проблема на одном рабочем устройстве. Но вскоре стало ясно: через вредоносное расширение для Visual Studio Code злоумышленники получили доступ примерно к 3800 внутренним репозиториям компании.

GitHub подтвердил несанкционированный доступ к внутренним репозиториям и сообщил, что компрометация была связана с устройством сотрудника, на котором оказалось «отравленное» расширение VS Code. Компания заявила, что устройство изолировали, вредоносную версию расширения удалили, а критичные секреты начали ротировать.

Один сотрудник и один плагин

Слабым местом оказался не сервер GitHub и не пользовательские репозитории, а рабочая среда разработчика. Сотрудник установил вредоносное расширение VS Code, после чего атакующие смогли добраться до внутренних данных компании.

Это неприятный, но очень показательный сценарий. Расширения редактора кода часто имеют доступ к локальным файлам, терминалу, токенам, переменным окружения и рабочим каталогам. Для разработчика это удобный инструмент. Для злоумышленника — почти идеальная точка входа, если плагин удаётся подменить или отравить.

Коротко: IDE-расширение сегодня может быть таким же опасным элементом цепочки поставки, как npm-пакет или Docker-образ.

Что заявила TeamPCP

Ответственность за инцидент связывают с группой TeamPCP. По данным The Hacker News и других профильных изданий, она выставила на продажу данные из внутренних репозиториев GitHub и заявляла о доступе примерно к 3800–4000 репозиториям. GitHub, по сообщениям СМИ, признал, что эта оценка в целом совпадает с результатами внутреннего расследования.

В публикациях также фигурирует цена около $50 тыс. за украденные данные. Более высокие суммы и заявления самих атакующих лучше воспринимать осторожно: такие сообщения часто используются для давления, рекламы группировки или поиска покупателя.

Что именно могло утечь

По текущим данным, речь идёт о внутренних репозиториях GitHub, а не о массовом взломе пользовательских проектов или enterprise-репозиториев клиентов. GitHub заявляет, что пока не видит признаков влияния на клиентские данные за пределами внутренних репозиториев компании.

Но это не делает инцидент безобидным. Внутренний код, конфигурации и инструменты могут помочь атакующим искать уязвимости, лучше понимать архитектуру платформы и планировать дальнейшие атаки. Даже если секреты уже заменены, сам факт утечки внутреннего кода остаётся серьёзным риском.

Почему это связано с supply chain

История с GitHub хорошо ложится в общий тренд последних месяцев: злоумышленники всё чаще заходят через инструменты разработчиков. Раньше в центре внимания были вредоносные зависимости в npm, PyPI или похожих реестрах. Теперь всё больше риска уходит в IDE-расширения, CI/CD, токены публикации и локальные окружения.

Aikido отдельно пишет, что отравленные расширения VS Code становятся удобным способом атаковать именно developer endpoints — рабочие устройства, на которых часто есть доступ к коду и секретам.

Для GitHub это особенно болезненно символически. Платформа сама находится в центре глобальной разработки, но инцидент показывает: даже крупная компания с сильной безопасностью не может полностью игнорировать риск обычного плагина в редакторе.

Что стоит сделать компаниям

После такой истории командам стоит внимательнее посмотреть на политику IDE-расширений. Белые списки, запрет неизвестных плагинов, контроль обновлений, отдельные рабочие профили и минимизация секретов на локальных машинах уже не выглядят чрезмерной осторожностью.

Также важны короткоживущие токены, разделение доступов и быстрая ротация ключей. Если расширение может увидеть всё окружение разработчика, то вопрос уже не только в том, «какой плагин установлен», а в том, сколько важных данных лежит рядом с ним.

История с GitHub неприятна именно своей простотой. Один плагин, одно рабочее устройство — и дальше начинается цепочка, которая затрагивает тысячи внутренних репозиториев.

Итог

Атака важна не только масштабом, а способом входа. Расширение VS Code кажется мелочью, но на практике оно может получить доступ к самому чувствительному месту компании — рабочей среде разработчика. Это показывает, что supply-chain атаки смещаются ближе к инструментам, которыми пишут код, а не только к серверам и production-инфраструктуре. Для любой команды разработки это повод считать IDE-плагины полноценным риском, а не удобными дополнениями «на свой вкус».

Самое тревожное здесь — не число 3800, а то, насколько буднично выглядит точка входа. Разработчики часто ставят расширения почти автоматически, особенно если они помогают писать код быстрее. Но редактор кода — это не браузерная вкладка с игрушкой, а место, где рядом лежат токены, SSH-ключи, терминал и доступ к репозиториям. GitHub, судя по сообщениям, быстро среагировал, но вывод шире: политика «ставь любые удобные плагины» для серьёзных команд становится слишком рискованной.

Источник: BleepingComputer The Hacker News Aikido