Содержание
Коротко
Кампания GhostAction, по отчёту GitGuardian, собирала не только учётные данные GitHub. В зоне риска секреты сборки, облачные ключи, токены npm, PyPI и Docker Hub и ключи провайдеров моделей. Вредоносный сценарий пользуется доверием, которое уже выдано задаче сборки. Просмотр одного аккаунта GitHub не отвечает, выпустили ли пакет, заходили ли в облачную роль и появился ли чужой расход на ключе модели. Сначала сохраните следы запуска, потом сверьте каждый связанный сервис.
Что произошло
На Dev.to разбирают сдерживание после кражи секретов в GitHub Actions, а не список жертв. У каждого запуска есть личность. Это GITHUB_TOKEN, секреты репозитория, которые задача может прочитать, короткий облачный токен через OIDC и сеть, если сборщик свой. Вопрос не в том, упоминает ли файл сценария имя секрета. Вопрос в том, мог ли вредоносный запуск прочитать живое значение и отправить его наружу. Задача, которую остановили до выполнения, и задача, которая уже вышла в сеть, — разные улики.
Публичный слой интернета автор смотрел в ZoomEye 6 ноября 2026 года, около 15:46 по всемирному времени. Запрос domain="github.com" дал 101 совпадение, из них 54 с портом 443. Отдельный запрос к адресу 193.32.204.199 дал два индексированных наблюдения. Это снимок открытой инфраструктуры, не число жертв и не доказательство, что учётные данные дошли до атакующего. Запрос не показывает, какие облака, реестры и провайдеры моделей были привязаны к репозиторию.
Дальше инвентаризация по каждому затронутому репозиторию. Для облака — роль, учётная запись, журналы создания и использования токенов: появлялся ли неожиданный субъект. Для реестра пакетов — область действия, владелец, журналы публикации: вышел ли новый пакет или версия. Для исходного кода — область токена и события аудита: менял ли токен другие репозитории. Для провайдера модели — владелец ключа, использование и счета: был ли необъяснимый расход или новый проект. Сырой журнал или выгрузку с контрольной суммой автор просит сохранить. Снимок экрана панели это не заменяет.
Почему это важно
Инцидент пересекает границы инструментов. Доверие сборки уже проведено в облако, в публикацию пакетов и в оплату моделей. Пока смотрите только GitHub, чужой пакет может стоять в реестре, а счёт за ключ модели уже идти.
Короткоживущий токен через OIDC, как его описывает документация GitHub, уменьшает цену секрета, найденного в истории git: доступ привязан к одному запуску и его можно разобрать по журналу. Он не закрывает всё. Реестру пакетов часто всё ещё нужен токен публикации. Провайдеру модели — ключ API. Оставшиеся постоянные секреты стоит сузить до проекта, прав и лимита трат.
Удаление ключа в интерфейсе не равно отзыву. Старое значение может работать, если шаг отзыва не завершился.
На практике
- Сначала сохраните сценарий, запись запуска и следы исходящей сети. Потом список значений, которые были доступны каждой выполненной задаче.
- Смените то, у чего самый широкий доступ. Проверьте, что одобренный потребитель уже ходит с новым значением, и только затем отзовите старое.
- Старый ключ проверьте на безвредной точке: ответ должен быть отказом. Для облачных ролей смотрите политику доверия и журналы сессий. Для реестров — историю выпусков и владельца. Для провайдеров моделей — использование, состав проекта и создание ключей.
- Не читайте публичный отчёт как утверждение, что затронут именно ваш облачный аккаунт. Список конкретных репозиториев и всех утёкших значений в открытых материалах нет. Повод проверить каждого подключённого поставщика — есть.
Итог
Кража секрета сборки — это проверка всех дверей, которые эта сборка уже открывает. GitHub в этом списке первая строка, не последняя.
Комментарии