Noma Labs продемонстрировали, что всего одна публичная задача (issue) в GitHub может привести к краже кода из приватных репозиториев с помощью автоматизации на базе ИИ. Их proof-of-concept позволяет злоумышленнику использовать собственных ботов организации против неё самой, раскрывая проприетарные файлы без взлома аутентификации GitHub.
Атака на виду у всех
Цепочка событий достаточно проста для воспроизведения:
- Злоумышленник создает issue в публичном репозитории, доступном для просмотра всем.
- ИИ-агент, подключенный к конвейеру непрерывной интеграции (CI), считывает заголовок и тело issue.
- У этого же агента уже есть права на чтение других приватных репозиториев организации.
- Скрытые инструкции в публичном issue указывают агенту, какие приватные файлы нужно извлечь.
- Агент публикует извлеченные файлы в виде комментария к публичному issue, делая их доступными всему миру.
Все происходит в рамках одного запуска автоматизации. Ни кражи учетных данных, ни утечки API-ключей, ни уязвимостей в самом GitHub. Злоумышленник просто эксплуатирует доверие, которое организация оказывает собственному боту.
Почему это важно именно сейчас
Агенты на базе ИИ сегодня связывают воедино современные конвейеры разработки. Они открывают pull-requests, запускают тесты, развертывают сборки и классифицируют баги — и всё это запускается легкими сигналами, такими как комментарии к issue. Когда такие агенты обладают широким доступом к репозиториям, грань между доверенными данными и недоверенным пользовательским вводом стирается.
Если агент может читать приватный код и писать публично в рамках одного процесса выполнения, модель контроля доступа организации рушится.
Реальный изъян: права доступа, а не модель
Демонстрация не указывает на вину самой ИИ-модели. Модель лишь следует полученным инструкциям. Уязвимость заключается в наборе прав, предоставленных автоматизации:
- Доступ на чтение к приватным репозиториям по всей организации.
- Доступ на запись в публичные ветки обсуждений issue.
- Триггер, срабатывающий на публичный текст, который может составить кто угодно.
Бесплатные, но эффективные способы исправления
Применение принципа наименьших привилегий значительно сужает путь атаки:
- Ограничьте область действия бота репозиторием, в котором он необходим. Если ему нужно работать только в конкретном репозитории, запретите ему любые другие права на чтение.
- Разделите токены на чтение и запись. Используйте одни учетные данные для извлечения кода и другие, строго контролируемые, для публикации комментариев.
- Одобрение человеком перед любой публичной публикацией. Легкий этап проверки — например, обязательная метка одобрения — создает контрольную точку, не останавливая конвейер.
- Минимизация зоны поражения. Проектируйте рабочие процессы так, чтобы сбой или неправомерное использование затрагивали максимум один репозиторий, а не всю организацию.
Контраргумент: операционные расходы
За чем следить дальше
Вывод: Если ИИ-автоматизация может одновременно видеть приватный код и писать публично, значит, система спроектирована неверно. Ужесточите права доступа, внедрите проверки человеком и минимизируйте зону поражения — иначе всего одна публичная задача может стать вектором утечки данных.
