11% из 100%: реальный масштаб атаки на GitHub оказался меньше прогнозов

Недавняя атака на GitHub Action вновь подняла вопрос о безопасности цепочек поставок ПО и уязвимости CI/CD-конвейеров. Первоначально сообщалось, что было затронуто 23 000 проектов. Однако, детальный анализ ситуации показал, что реальные масштабы проблемы значительно меньше предварительных оценок.

Специалисты выяснили, что лишь 5 416 репозиториев из 4 072 организаций содержали рабочие процессы, связанные с проблемным GitHub Action. Среди репозиториев были некоторые популярные проекты с 350 000 звезд и 63 000 форков, что первоначально вызывало опасения о возможных масштабах атаки.

Однако по факту из всего множества репозиториев в критический 24-часовой период атаки с 14 по 15 марта 2025 года рабочие процессы с использованием опасного компонента запускались лишь в 614 случаях, что составляет около 11% от общего числа затронутых репозиториев. При этом значительная часть из них ограничилась не более чем 10 запусками, хотя в отдельных случаях зафиксировано свыше 50 запусков.

Даже среди 614 активных репозиториев не все подверглись утечке данных. Только 218 репозиториев оказались уязвимы настолько, что в их логах действительно были зафиксированы секретные ключи и токены. Всего выявлено 72 различных типа секретных данных, большая часть из которых — временные токены доступа GitHub (GITHUB_TOKEN). Такие токены действуют только в момент исполнения рабочего процесса и истекают по завершении задания или через сутки, что существенно ограничивает их ценность для злоумышленников.

Тем не менее, несмотря на относительно небольшой масштаб проблемы, последствия для затронутых репозиториев могут быть весьма серьёзными. Среди утёкших данных были обнаружены информация из DockerHub, npm и AWS. Именно эти данные представляют наиболее серьёзную угрозу, так как открывают возможности для дальнейших атак на цепочки поставок.

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