Кибератаки на проекты с открытым кодом преимущественно связаны с распространением вредоносных компонентов в публичных хранилищах. Однако инцидент 14 марта выделяется: злоумышленники взломали популярный рабочий процесс (GitHub Action) tj-actions/changed-files, задействованный в более чем 23 тысячах репозиториев. Уязвимость под идентификатором CVE-2025-30066 затрагивает все проекты, использовавшие скомпрометированную версию changed-files. Несмотря на оперативную блокировку и откат к безопасному состоянию администрацией, пострадавшим необходимо предпринять меры по устранению последствий, а сообществу — сделать выводы.
Суть GitHub Actions
Инструмент GitHub Actions предназначен для автоматизации рутинных DevOps-задач. Эти процессы активируются определёнными событиями на платформе, например, внесением изменений в код. Пользователям доступен каталог готовых решений — интеграция нужного действия в конвейер CI/CD требует добавления всего одной строки в конфигурацию.
Детали компрометации changed-files
14 марта в код процесса tj-actions/changed-files (используется для отслеживания изменённых файлов) внедрили вредоносные инструкции. Злоумышленники обновили ссылки на версии, распространив заражённый код через все релизы. Действие выполнялось от имени автоматизированного сервиса Renovate, однако его учётные данные не пострадали — это была лишь имитация для скрытия анонимного коммита.
Вредоносный фрагмент маскировался под функцию updateFeatures, которая запускала скрытый Python-скрипт. Этот скрипт анализировал память рабочего процесса Runner Worker, выявляя конфиденциальные данные: ключи облачных провайдеров (AWS, Azure, GCP), токены GitHub и NPM, учётные записи баз данных и RSA-ключи. Украденная информация записывалась в логи сборки с двойным кодированием base64, что упрощало её извлечение из публично доступных журналов любыми третьими лицами.
GitHub удалил опасную версию changed-files через 24 часа после обнаружения, вызвав временные сбои в зависимых CI/CD-процессах. Через 8 часов репозиторий восстановили из безопасной резервной копии.
Действия для минимизации последствий
Публичные репозитории с открытыми журналами сборок подвергаются наибольшему риску. Однако приватные проекты также уязвимы — особенно если в них используются секреты, дублирующиеся в публичных источниках. Под угрозой могут оказаться реестры контейнеров или пакеты популярных open source-решений.
Рекомендуемые меры:
- Проверить логи GitHub Actions от 14–15 марта на наличие подозрительных записей в разделе changed-files. Обнаруженные данные стоит декодировать для оценки масштаба утечки.
- Изучить историю активности за этот период на предмет аномальных IP-адресов.
- Обновить все секреты, задействованные в сборках — в первую очередь для проектов с публичными журналами, затем для приватных.
- Экспортировать и проанализировать логи перед их очисткой в публичном доступе.
Выводы для разработчиков
Атаки на цепочку поставок ПО становятся сложнее: помимо инфицированных пакетов и репозиториев, злоумышленники теперь используют процессы CI/CD. Это требует внедрения усиленных мер безопасности на всех этапах жизненного цикла разработки.
Ключевые рекомендации:
- Тщательный аудит сторонних компонентов (библиотеки, контейнеры, инструменты автоматизации).
- Внедрение систем контроля безопасности контейнеров и централизованного управления секретами.
- Соблюдение специальных правил работы с конфиденциальными данными не только в коде, но и в процессах сборки. Официальная документация GitHub детально описывает настройки безопасности для Actions.