GitHub стал главной мишенью хакеров: доля атак через цепочки поставок выросла до четверти инцидентов
Доля атак через цепочки поставок в облачных инцидентах выросла до 25%, превратив GitHub из удобного хранилища кода в главную мишень для киберпреступников. Похищенные токены и скрытые промпт-инъекции позволяют злоумышленникам заражать сотни продуктов через легитимные каналы, что требует срочного пересмотра политик безопасности DevSecOps.
GitHub превратился из удобного хранилища кода в главную мишень для киберпреступников и ключевой узел автоматизации разработки. Доля атак через цепочки поставок программного обеспечения в облачных инцидентах выросла с 10% до 25%. Теперь одного взломанного аккаунта разработчика достаточно, чтобы заразить сотни продуктов, превратив автоматизацию сборки из инструмента ускорения работы в масштабную угрозу для всей инфраструктуры.
Почему GitHub стал «слабым звеном» безопасности
Основная проблема заключается в том, что злоумышленники перестали ломать стены и начали использовать легитимные каналы доставки кода. Они активно охотятся за токенами доступа к GitHub. Похищенные учетные данные позволяют получить несанкционированный доступ к приватным репозиториям, контейнерным хранилищам и другим облачным ресурсам жертв.
В одном из зафиксированных эпизодов атакующие заявляли о доступе примерно к 4000 частных репозиториев благодаря украденным секретам. Исследователи отмечают, что похищенные токены используются не только для чтения данных, но и для изменения содержимого кода. Более того, фиксировались случаи повторного использования украденных секретов спустя несколько недель после первоначального взлома, иногда даже другими группировками.
GitHub стал «мостом» между открытым миром и закрытой корпоративной инфраструктурой. Любой скомпрометированный элемент в цепочке поставок (зависимость, плагин, токен) мгновенно масштабирует уязвимость на все проекты, использующие этот элемент.
Как ИИ меняет вектор атак и защиту
Искусственный интеллект теперь работает с обеих сторон баррикад: он ускоряет создание угроз и одновременно становится жертвой манипуляций. Злоумышленники перестали использовать ИИ только для фишинга и начали применять его для автоматической разработки вредоносного кода. Традиционные методы защиты, основанные на поиске известных сигнатур, перестают работать.
Особую опасность представляет использование популярных платформ, включая GitHub, в качестве скрытых каналов для размещения вредоносного ПО. Например, группа Armored Likho перевела троянец Kharon RAT в приватные репозитории GitLab и GitHub. Это существенно усложняет процесс обнаружения, так как стандартный мониторинг публичных репозиториев становится неэффективным. Легитимные бизнес-инструменты превращаются в слепые зоны для систем безопасности.
Параллельно с этим ИИ-агенты сами становятся вектором атаки. Злоумышленники внедряют скрытые инструкции (промпт-инъекции) в файлы Readme репозиториев на GitHub. Когда ИИ-ассистент разработчика считывает этот файл, он воспринимает текст как команду и может выполнить вредоносные действия: выгрузить API-ключи или запустить скрипты на компьютере пользователя. Традиционные антивирусы бессильны против таких атак, так как они оперируют текстом, а не исполняемыми файлами.
Практические риски для бизнеса
Для компаний, использующих GitHub в рабочих процессах, складывается тройной риск:
- Утечка секретов через сторонние сервисы. В 2025 году в публичные репозитории GitHub было загружено 28,65 млн новых секретов. Проблема вышла за рамки открытых проектов: ключи часто остаются активными годами из-за сложности их замены. Утечки происходят даже через популярные веб-сервисы форматирования кода, которые публично сохраняют введённые данные.
- Атаки на агентов ИИ. Интеграция ИИ-агентов в корпоративные инструменты (через OAuth-токены и ключи доступа) делает традиционные системы контроля (IAM и PAM) менее эффективными. Агенты получают широкий доступ к данным, но часто работают без прямого контроля со стороны ИТ-отдела.
- Компрометация цепочки поставок. Злоумышленники скрывают вредоносные зависимости в популярных пакетах (например, через уязвимости NPM). Вредоносный пакет сканирует систему на наличие учетных данных GitHub и передает их наружу. Это позволяет атакующим получить временные учетные данные для развертывания вредоносной инфраструктуры внутри облака жертвы.
Что делать: рекомендации по снижению рисков
Ситуация требует пересмотра подходов к безопасности разработки (DevSecOps). Ограничиться проверкой кода на наличие багов уже недостаточно.
- Аудит и ротация секретов. Необходимо внедрить автоматизированное сканирование репозиториев на наличие зашитых токенов, паролей и API-ключей. Старые учетные записи должны отзывать регулярно.
- Контроль ИИ-агентов. Перед интеграцией ИИ-ассистентов в рабочие процессы нужно четко ограничить их права доступа. Агенты не должны иметь возможности выгружать конфиденциальные данные или выполнять произвольные скрипты без явного подтверждения человека.
- Проверка происхождения зависимостей. Нельзя слепо доверять популярным пакетам из открытых репозиториев. Требуется верификация источника и мониторинг обновлений стороннего ПО для быстрого патчинга уязвимостей.
- Обучение разработчиков. Сотрудники должны понимать, что файл
Readme или комментарий в коде может содержать вредоносную инструкцию для ИИ-ассистента. Также важно избегать использования сторонних онлайн-сервисов для форматирования чувствительного кода.
Прогноз
Если текущий темп внедрения автономных ИИ-агентов в корпоративные процессы сохранится без адекватной разработки стандартов идентификации и прозрачности их действий, то к 2027 году «промпт-инъекции» станут таким же частым вектором атаки, как SQL-инъекции были в эпоху веб-разработки. Компании, которые не разделят уровни доверия между системными инструкциями для ИИ и внешними данными из репозиториев, столкнутся с массовыми утечками данных, инициированными собственными же автоматизированными инструментами.
🤖 Сводка сформирована на основе фактов из Календаря и обновляется при поступлении новых данных.
📅 Последнее обновление сводки: 1 сентября 2026.
