Зміст
Коротко
Кампанія 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 у цьому списку перший рядок, не останній.
Коментарі