GitHub-репозитории заразили через «автоматические» коммиты: что показала атака Megalodon

В GitHub прошла крупная supply-chain атака, которая выглядит особенно неприятно для эпохи автоматизации разработки. Исследователи SafeDep описали кампанию Megalodon: 18 мая за шесть часов злоумышленники протолкнули 5718 вредоносных коммитов в 5561 репозиторий. Коммиты маскировались под обычную настройку CI/CD — что-то вроде «улучшить build pipeline» или «обновить конфигурацию сборки», — но на деле добавляли GitHub Actions workflow для кражи секретов.

SecurityWeek вынесла историю в Techmeme, а Ox Security независимо подтвердила, что тысячи репозиториев уже содержали зараженный YAML-файл. Важная деталь: это не классическая история про один взломанный npm-пакет. Атака била по самой инфраструктуре сборки, где обычно живут токены, cloud-доступы и автоматические ключи.

Как работала схема

По данным SafeDep, вредоносные коммиты приходили от поддельных авторов вроде build-bot, auto-ci, ci-bot и pipeline-bot. Названия и сообщения выглядели достаточно скучно, чтобы не привлечь внимание: «ci: add build optimization step», «build: improve ci performance», «chore: update ci/cd pipeline». Для уставшей команды это может выглядеть как очередная машинная правка, особенно если репозиторий давно полагается на автоматические коммиты.

Внутри workflow был base64-код, который запускался в CI и пытался собрать всё, что обычно нельзя терять: переменные окружения, AWS-, GCP- и Azure-доступы, SSH-ключи, Docker- и Kubernetes-конфиги, npm- и GitHub-токены, database connection strings, .env-файлы и другие секреты. SafeDep отдельно отмечает, что один вариант срабатывал на push и pull request, а другой создавал отложенную заднюю дверь через workflow_dispatch — такой workflow можно было запустить позже через GitHub API, если у атакующего есть подходящий токен.

Самый показательный пример — Tiledesk, open source платформа для live chat и чат-ботов. SafeDep пишет, что версии @tiledesk/tiledesk-server с 2.18.6 по 2.18.12 попали в npm уже с вредоносным workflow. При этом атакующий, по версии исследователей, не захватывал npm-аккаунт напрямую: репозиторий был отравлен раньше, а maintainer затем выпустил пакет из зараженного исходного кода.

Почему это важно не только разработчикам

Supply-chain атаки становятся опаснее именно потому, что современная разработка всё больше похожа на сеть автоматических доверий. CI/CD получает ключи к облакам, registry, тестовым базам, staging-средам и иногда к production. AI-агенты, code assistants и автоматические пайплайны ускоряют работу, но одновременно делают «служебные» изменения менее заметными: в ленте коммитов становится больше машинного шума, а значит вредоносный YAML легче принять за рутину.

Для компаний урок здесь практический. Проверять надо не только package-lock, requirements.txt и список npm-зависимостей. Нужно отдельно смотреть изменения в .github/workflows, права GitHub Actions, разрешение id-token: write, deploy keys, personal access tokens, cloud-роли и то, какие workflow могут запускаться по pull_request_target или workflow_dispatch. Если CI имеет доступ к секретам, то YAML-файл становится почти таким же чувствительным, как backend-код.

Ox Security советует блокировать соединения с C2-адресом 216.126.225.129, ротировать ключи на затронутых машинах и аудитить GitHub Actions. Но главное последствие шире одного IP-адреса. Атака Megalodon показывает, что цепочка поставки ПО теперь ломается не только через популярные библиотеки, а через доверие к автоматизации. Там, где раньше команда спрашивала «какой пакет мы установили?», теперь нужно спрашивать ещё и «какой робот изменил нашу сборку — и почему мы ему поверили?»