ИИ-помощники ускоряют разработку, но вместе с кодом в репозиторий могут попасть API-ключи, токены и пароли. Разбираем, почему при вайб-кодинге растёт риск утечек и как его снизить с помощью управления секретами, контроля публикаций и ограничения доступа ИИ.
- 1. Введение
- 2. Как секреты попадают в код при работе с ИИ
- 3. Меры по снижению риска утечки секретов при разработке с использованием ИИ
- 4. Выводы
Введение
Вайб-кодинг — практика быстрой разработки программного обеспечения с использованием ИИ-инструментов. Вместе с ростом её популярности увеличивается число случаев, когда в коде, созданном с участием ИИ, обнаруживаются корпоративные секреты.
По данным исследования GitGuardian State of Secrets Sprawl 2026, пароли, ключи и токены для подключения к различным сервисам обнаруживались в 3,2% изменений кода с участием Claude Code, тогда как общий показатель для публичных изменений (в том числе внесённых программистами-людьми) на площадке для совместной разработки и хранения кода GitHub составлял 1,5%. Таким образом, доля изменений кода с обнаруженными секретами при использовании ИИ-инструментов оказалась более чем в два раза выше среднего показателя.
Основные типы корпоративных секретов и источники их утечки:
- API-ключи и токены — цифровые пропуска, с помощью которых программы взаимодействуют с облачными сервисами, базами данных и другими ресурсами. Их обладатель получает доступ к соответствующим сервисам в пределах выданных разрешений.
- Hardcoded secrets — пароли и ключи, записанные непосредственно в тексте программы или её настройках, то есть доступ к ресурсу оказывается неотделим от самого кода.
- Файлы настроек и история изменений в хранилище кода — источники утечки, при которых секрет может оставаться в конфигурации или в истории коммитов даже после его удаления из текущей версии файла.
Сами по себе такие секреты не всегда появляются в коде по вине ИИ: разработчики оставляли ключи и пароли в репозиториях и раньше. Однако генеративные инструменты меняют масштаб проблемы — они ускоряют создание и изменение кода, а вместе с этим увеличивают число потенциальных точек, где чувствительные данные могут оказаться в открытом доступе.
Как секреты попадают в код при работе с ИИ
Типичный сценарий утечки выглядит следующим образом: разработчик передаёт ИИ-инструменту рабочий ключ для проверки подключения к сервису. Файл с этим ключом попадает в общую папку проекта и публикуется вместе с кодом. Дополнительный риск связан с тем, что некоторые ИИ-помощники используют не только текст запроса, но и окружающий код, включая фрагменты открытых файлов, — это может привести к попаданию секрета в контекст запроса даже без явного упоминания.
Таким образом, одновременно возникают два риска: передача секрета ИИ-сервису и публикация секрета в репозитории. Рабочий ключ не следует передавать в запросе или примере для ИИ ради удобства.
Поскольку вайб-кодинг ускоряет разработку и подключение новых сервисов, он обостряет существующую проблему публикации секретов в коде. Каждое новое подключение добавляет ключ, который необходимо контролировать. Отдельно отметим, что ряд популярных инструкций по настройке ИИ-ассистентов рекомендует размещать API-ключи в конфигурационных файлах, аргументах командной строки и строках подключения, что противоречит принципам кибербезопасности.
Действующий ключ предоставляет доступ к данным или операциям в пределах прав, разрешённых программе; масштаб последствий утечки определяется объёмом этих прав.
Использование закрытого репозитория не решает проблему полностью: секреты остаются доступны его легитимным пользователям, которые могут случайно передать их вовне. Ключи также нередко попадают в рабочие чаты и системы постановки задач — с аналогичными последствиями. Удаление строки с секретом из файла не отключает сам доступ: копия может сохраниться в истории проекта, поэтому раскрытый ключ необходимо отозвать или заменить.
Проблема секретов в коде не ограничивается отдельным продуктом или командой — она связана с тем, как компания в целом создаёт, передаёт и хранит доступы.
Меры по снижению риска утечки секретов при разработке с использованием ИИ
Снижать риск необходимо на трёх уровнях: не допускать попадания долгоживущих секретов в код и запросы к ИИ, предоставлять приложениям только ограниченный по времени доступ и обнаруживать учётные данные до публикации. Для этого применяют централизованное управление секретами, автоматическую проверку кода и ограничение доступа ИИ-инструментов к корпоративным ресурсам.
Централизованное управление секретами
Для решения этой задачи в отрасли применяются два взаимодополняющих класса решений:
- Парольные сейфы (enterprise password manager) предназначены для пользователей и команд. Обеспечивают централизованное зашифрованное хранение учётных данных, разграничение доступа по ролям и журналирование действий.
- Хранилища ИТ-секретов (secrets management) предназначены для машинных сценариев: DevOps-конвейеров и ИИ-инструментов. Реализуют тот же принцип централизации, но секрет выдаётся программе или пайплайну по заданной политике, под конкретную задачу, с автоматической ротацией и отзывом.
Именно второй класс решений закрывает описанный выше сценарий: секрет хранится в защищённом хранилище, а не передаётся через диалог с ИИ или через конфигурационный файл, попадающий в публичный репозиторий. Источником рабочего секрета становится управляемое хранилище, а не сообщение, ответ нейросети или скопированный конфигурационный файл.
На практике применяются два дополняющих друг друга подхода.
Первый подход (характерен для облачных сервисов и CI/CD): секрет не хранится постоянно, а выдаётся на время выполнения задачи.
- В коде указывается способ получения доступа без указания самого значения (ключа, пароля, токена). Например, GitHub Actions поддерживает получение краткосрочного облачного доступа через OIDC — механизм подтверждения подлинности программы.[2] Это исключает необходимость хранить постоянный облачный ключ в настройках сборки.
- При запуске система сборки подтверждает свою подлинность и назначение с помощью полученного значения. Автоматическое предоставление доступа ко всем корпоративным ключам не допускается — для каждой задачи должны использоваться минимальные полномочия.
- Облачный провайдер предоставляет только тот доступ, который разрешён политикой для конкретного задания.
- Срок действия доступа ограничен, и по его истечении доступ автоматически прекращается.
Второй подход (характерен для корпоративных хранилищ ИТ-секретов): Секрет хранится в зашифрованном виде в защищённом хранилище и выдаётся по API под конкретную задачу — с ограничением по времени, минимальными правами и полным журналом обращений. Несмотря на различие механизмов, оба подхода преследуют одну цель: исключить появление рабочего ключа в открытом виде — в переписке, конфигурационном файле или диалоге с ИИ-инструментом.
Внедрение контроля публикации кода
Дополнительной мерой является проверка кода на наличие секретов и блокировка публикаций, содержащих обнаруженные ключи. Например, GitHub поддерживает такую проверку с помощью функции Push Protection, которая автоматически проверяет изменения на наличие API-ключей, токенов и других учётных данных перед их публикацией в репозитории. При обнаружении потенциального секрета система блокирует отправку, указывает разработчику причину и предлагает удалить конфиденциальные данные, после чего публикацию можно повторить.
Блокировку можно обойти с указанием причины, однако для корпоративных репозиториев такие случаи фиксируются в журнале аудита и сопровождаются уведомлением ответственных сотрудников. Также поддерживается настройка собственных шаблонов для поиска внутренних ключей нестандартного формата.
ИИ-инструменты повышают скорость разработки, однако рабочие ключи должны выдаваться не напрямую разработчиком, а специализированной защищённой системой — парольным сейфом или хранилищем ИТ-секретов — по необходимости, под конкретную задачу и с ограниченными правами.
Выводы
Вайб-кодинг не создаёт принципиально новый вид утечки, но увеличивает скорость разработки и объём публикуемого кода, поэтому прежние ошибки могут происходить чаще, а их последствия — быстрее распространяться. Ответственность за проверку и публикацию результата при этом остаётся за разработчиком и компанией.
Защита должна работать на нескольких уровнях. Долгоживущие ключи не следует хранить в коде, конфигурационных файлах и запросах к ИИ. Приложениям и ИИ-агентам необходимо выдавать краткосрочные учётные данные с минимальными правами, а изменения кода — автоматически проверять до попадания в репозиторий.
Если секрет уже был опубликован или передан внешнему сервису, простого удаления строки недостаточно. Ключ необходимо отозвать и заменить, проверить журналы его использования и при необходимости очистить историю репозитория. Цель таких мер — не ограничить применение ИИ, а встроить его в процесс разработки так, чтобы ускорение работы не происходило за счёт безопасности.
