GitHub Actions із підтримкою ШІ можна скомпрометувати одним коментарем, що призведе до витоку API-ключів, хмарних токенів та інших секретів. Дослідник безпеки виявив 22 open-source репозиторії, де публічний тригер, інструмент ШІ, запущений із прапорцем «skip prompts», та відкриті секрети створюють прямий шлях для викрадення даних.

Як працює ця вразливість

Проєкти зараз вбудовують ШІ-агентів — Claude Code, GitHub Copilot CLI та подібні інструменти — безпосередньо в CI-конвеєри. Крок workflow виконує команду shell і часто додає прапорець, який наказує інструменту ігнорувати інтерактивні запити на підтвердження прав. Коли workflow запускається через будь-який публічний вхідний сигнал — issue, коментар або заголовок pull-request — зловловнику достатньо опублікувати рядок тексту, який ШІ сприйме як команду.

ШІ, який уже отримав необмежений доступ до shell завдяки прапорцю «skip prompts», може прочитати будь-яку змінну середовища або файл, які відкриває workflow. Якщо job також завантажує секрети — API-ключі, токени хмарних сервісів або повні облікові дані сервісних акаунтів — ШІ передає ці значення на сервер, підконтрольний зловловнику. Жодних змін у коді, жодних нових залежностей — лише невинний на вигляд коментар.

Приклади з реального світу

Дослідник підтвердив наявність трьох вразливих репозиторіїв, які вже були виправлені:

  • pymc-labs/pymc-marketing – через публічне issue можна було отримати ключ Anthropic API за допомогою prompt injection.
  • MadAppGang/dingo – workflow надавав Claude Code повний доступ до Bash і відкривав два секрети в тому самому job.
  • MadAppGang/claudish – використовувався той самий вразливий шаблон, що й у проєкті dingo.

Один із знайдених випадків стосувався активного ключа облікового запису хмарного сервісу, про що дослідник повідомив безпосередньо команді безпеки великого провайдера ШІ. Ще дванадцять звітів очікують на розгляд мейнтейнерів; їхні назви не розголошуються до моменту випуску виправлень.

Що стоїть на кону

Коли зловловник викрадає секрет, шкода може бути миттєвою та значною. Ключ облікового запису хмарного сервісу надає необмежений доступ до обчислювальних ресурсів, сховищ (storage buckets) та інших платних послуг. API-ключ провайдера великих мовних моделей може виконувати необмежену кількість запитів, що потенційно призведе до витрат у тисячі доларів. Оскільки експлойт запускається всередині CI-середовища, порушення безпеки може поширитися далі: будь-який артефакт, зібраний на скомпрометованому runner, може містити шкідливий код, перетворюючи один репозиторій на вектор атаки на ланцюжок постачання.

Для команд, які покладаються на CI з підтримкою ШІ, компроміс є дуже суворим. Зручність автоматично згенерованого коду, лінтингу або документації має бути зважена проти ризику того, що публічний коментар стане прихованим бекдором.

Чому цю вразливість легко пропустити

Спочатку дослідник подав шість звітів, які згодом були відкликані. Відкликання були зумовлені припущеннями щодо перевірок прав доступу GitHub Actions, а не ретельним аналізом вихідного коду Action. Документація та інтуїція можуть вводити в оману; єдиний надійний спосіб підтвердити безпеку кроку з підтримкою ШІ — це перевірити код, який запускає інструмент, та YAML-файл workflow, який його налаштовує.

Контрольний список заходів із пом'якшення наслідків

Якщо ви запускаєте ШІ-CLI або подібний інструмент у межах GitHub Actions workflow, дайте відповідь на ці два запитання перед злиттям (merge):

  1. Хто може запускати workflow? Обмежте тригери довіреними подіями (наприклад, push у захищені гілки) або вимагайте явного схвалення для запусків, ініційованих зовнішніми контриб'юторами. Уникайте on: issue_comment або on: issues без додаткових механізмів контролю.

  2. Які секрети завантажуються в тому самому job? Ніколи не відкривайте API-ключі, хмарні токени або облікові дані сервісних акаунтів у job, де також запускається ШІ-агент із необмеженим доступом до shell. Розділяйте кроки з великою кількістю секретів на ізольовані jobs або runners, які не викликають ШІ-інструменти.

Додаткові кроки для посилення захисту:

  • Видаліть прапорець, який пропускає запити на підтвердження прав, змушуючи ШІ-інструмент запитувати явне підтвердження перед виконанням команд shell.
  • Додайте крок, який очищує або приховує будь-яку змінну середовища, яку може прочитати ШІ-інструмент.
  • Використовуйте self-hosted runners із контролем вихідного трафіку (network egress), щоб заблокувати викрадення даних на довільні кінцеві точки.

Контраргумент: користь ШІ в CI

Прихильники стверджують, що зростання продуктивності переважує ризики. Автоматизовані пропозиції коду скорочують час на рев'ю, а тестування на базі ШІ допомагає виявляти помилки раніше. Проте та сама зручність розширює поверхню атаки. Ключ полягає не в тому, щоб відмовитися від ШІ, а в тому, щоб ставитися до будь-якого інструмента з привілеями рівня shell як до потенційного вектора атаки.

На що звернути увагу далі

Результати дослідження вже викликали дискусії на форумах безпеки GitHub щодо суворіших дозволів за замовчуванням для Actions з підтримкою ШІ. Майбутні оновлення платформи можуть включати:

  • Прапорець, який змушує інструменти ШІ працювати в ізольованому середовищі (sandbox) без прямого доступу до shell.
  • Вбудоване виявлення патернів prompt-injection у тілах issue або коментарях.
  • Автоматичні сповіщення, коли workflow поєднує публічні тригери із завданнями, що містять секрети.

Наразі відповідальність залишається на мейнтейнерах репозиторіїв. 22 виявлені репозиторії свідчать про те, що проблема не є поодинокою; будь-який проєкт, що повторює такий самий патерн workflow, є вразливим. Швидкий аудит конфігурацій CI може виявити проблему раніше, ніж це зробить зловмисник.

Підсумок: Один рядок тексту у публічному GitHub issue може надати ШІ-агенту повний контроль над вашим CI-середовищем і дозволити викрасти секрети, які ви там зберігаєте. Перевіряйте, хто може запускати ваші workflow, тримайте секрети подалі від кроків, керованих ШІ, і ретельно вивчайте кожен прапорець, що надає неконтрольовані дозволи. Ціна витоку значно перевищує зусилля, необхідні для дисциплінованого аудиту.