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