Noma Labs продемонстрували, що один публічний GitHub issue може бути використаний для викрадення коду з приватних репозиторіїв за допомогою автоматизації на базі ШІ. Їхній proof-of-concept дозволяє зловмиснику використати власних роботів організації проти неї самої, що призводить до витоку пропрієтарних файлів без порушення автентифікації GitHub.

Атака на видному місці

Ланцюжок подій досить просто відтворити:

  • Зловмисник створює issue у публічному репозиторії, який доступний для перегляду будь-кому.
  • ШІ-агент, підключений до конвеєра безперервної інтеграції (CI pipeline), зчитує заголовок та текст issue.
  • Цей самий агент уже має права на читання інших приватних репозиторіїв організації.
  • Приховані інструкції у публічному issue вказують агенту, які саме приватні файли потрібно отримати.
  • Агент публікує отримані файли у відповідь на публічне issue у вигляді коментаря, роблячи їх доступними для всього світу.

Усе відбувається під час одного запуску автоматизації. Жодних крадіжок облікових даних, жодних витоків API-ключів, жодних вразливостей GitHub. Зловмисник просто експлуатує довіру, яку організація надала власному боту.

Чому це важливо саме зараз

Агенти на базі ШІ зараз є сполучною ланкою сучасних конвеєрів розробки. Вони відкривають pull-requests, запускають тести, розгортають збірки та класифікують баги — і все це запускається легкими сигналами, такими як коментарі до issue. Коли ці агенти мають широкий доступ до репозиторіїв, межа між довіреними даними та недовіреним вводом користувача розмивається.

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

Справжня вада: права доступу, а не модель

Демонстрація не вказує на провину самої моделі ШІ. Модель лише виконує отримані інструкції. Вразливість полягає у наборі дозволів, наданих автоматизації:

  • Доступ на читання до приватних репозиторіїв усієї організації.
  • Доступ на запис до публічних гілок обговорень issue.
  • Тригер на публічний текст, який може створити будь-хто.

Виправлення, які нічого не коштують, але працюють

Застосування принципу найменших привілеїв значно звужує шлях атаки:

  • Обмежте область дії бота лише тим репозиторієм, де він необхідний. Якщо йому потрібно діяти лише в одному конкретному репозиторії, забороніть йому будь-які інші права на читання.
  • Розділяйте токени на читання та запис. Використовуйте одні облікові дані для отримання коду та інші, суворо контрольовані дані для публікації коментарів.
  • Людське схвалення перед будь-якою публікацією. Легкий етап перевірки — наприклад, обов'язкова мітка схвалення — додає контрольний пункт, не зупиняючи конвеєр.
  • Зменшення радіусу ураження. Проектуйте робочі процеси так, щоб збій або зловживання впливали максимум на один репозиторій, а не на всю організацію.

Контраргумент: операційні витрати

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

Висновок: Якщо ШІ-автоматизація може одночасно бачити приватний код і писати публічно, система спроектована неправильно. Посильте дозволи, додайте перевірки людьми та тримайте радіус ураження невеликим — інакше один публічний issue може стати вектором витоку даних.