Vibe coding: как AI ускоряет разработку, но ломает безопасность — что делать

Что происходит на практике?

Один из ваших разработчиков открыл среду разработки, ввёл запрос в AI-помощник — «сгенерировать функцию авторизации», получил готовый код и за пару минут отправил его в общий репозиторий. Такой диалог с программой-помощником, когда разработчик формулирует задачу, получает готовый фрагмент и сразу отправляет его в репозиторий, называется vibe coding.

Как меняется модель контроля?

Традиционный процесс обеспечения безопасности разработки (проверка кода в репозитории, сканирование на уязвимости) построен на том, что весь код появляется в системе контроля версий. При vibe coding часть работы происходит до создания запроса на слияние: запросы к модели, ответы и даже небольшие фрагменты кода могут оставаться вне зоны видимости команды безопасности. В результате теряется два критичных пункта прозрачности:

• Какие данные (исходный код, конфиги, логи, иногда даже тексты задач) уходят в модель.
• Кто фактически написал конкретный кусок кода — человек или AI-ассистент.

Какие новые риски появляются?

• Утечка конфиденциальных данных — если в запросе разработчик передаёт части бизнес-логики, пароли или внутренние ключи доступа, модель может их запомнить или отразить в ответе.
• Неизвестный источник кода — сканеры видят лишь итоговый фрагмент, но не знают, откуда он пришёл. Это усложняет оценку риска уязвимостей, связанных с известными уязвимостями в зависимостях, которые модель могла добавить автоматически.
• Небезопасные паттерны — AI-ассистент может предложить решение, которое выглядит корректным, но нарушает принципы минимальных прав доступа, использует устаревшие библиотеки или открытые порты.
• Отсроченный отклик DevSecOps — задачи, найденные сканером, попадают в длинный список ожидания, а из-за большого объёма кода разработчики просто не успевают исправлять всё.

Как проверить безопасность AI-кода?

• Логировать каждый запрос к AI-ассистенту (текст запроса, время, пользователь, используемая модель).
• Маркировать AI-сгенерированный код в репозитории (например, специальный комментарий // AI-generated).
• Запускать сканирование не только на готовом запросе на слияние, но и на «промежуточных» артефактах — скрипт, который собирает все AI-ответы и проверяет их.
• Проводить ручной review тех фрагментов, где в запросе передавались конфиденциальные данные или бизнес-логика.
• Ограничить контекст, передаваемый в модель: исключать логи, токены, детали инфраструктуры.

Что может пойти не так?

• Недостаточная точность логов — если система не фиксирует полный запрос, вы не сможете отследить, какие данные ушли наружу.
• Снижение скорости разработки — дополнительные проверки могут вернуть часть ускорения, которое обещали AI-ассистенты.
• Сопротивление команды — разработчики могут воспринимать новые ограничения как «надоедание» и обходить их, что только ухудшит контроль.
• Неоднородность инструментов — разные AI-ассистенты имеют свои API и политики хранения данных, что усложняет единый процесс аудита.

Примеры реальных инцидентов

Технические детали интеграции AI-ассистентов

• Прокси-слой для запросов — разместите небольшую службу (например, на Node.js или Go), через которую проходят все обращения к внешним AI-API. Прокси фиксирует тело запроса и ответа, а также добавляет метаданные (ID пользователя, проект, ветка).
• Шифрование журналов — храните логи в зашифрованном хранилище. Доступ к журналам должен быть ограничен только команде безопасности.
• Токен-редактирование — перед отправкой запроса автоматически заменяйте любые строки, соответствующие паттернам секретов, на «***». Это можно реализовать через регулярные выражения или специализированные инструменты.
• CI-плагин для «промежуточных» артефактов — создайте шаг в pipeline, который собирает все файлы, отмеченные как // AI-generated, и прогоняет их через те же инструменты сканирования, что и обычный код.
• Обратная связь в модель — если сканер обнаружил уязвимость в AI-сгенерированном фрагменте, автоматически отправляйте «feedback-запрос» в модель с указанием ошибки, чтобы обучить её избегать подобных паттернов в будущем.

Рекомендации по политике данных

Что может измениться в будущем?

• Модели с локальным развертыванием — компании начнут использовать локальные версии AI-моделей, что уменьшит риск утечки данных за пределы корпоративного периметра, но потребует собственного процесса обновления моделей.
• Контекст-чувствительные сканеры — новые инструменты сканирования будут учитывать, что часть кода пришла из AI, и автоматически применять более строгие правила (например, проверку на использование устаревших библиотек).
• Регулятивные требования — в ЕС и США могут появиться законы, обязывающие фиксировать каждый запрос к генеративному ИИ и предоставлять возможность «права на забвение» для данных запросов.
• Обучаемые политики — организации смогут «подкормить» модели своими внутренними правилами (например, «не использовать прямой доступ к базе данных без ORM»), что снизит количество небезопасных рекомендаций.

Что сделать уже на этой неделе?

Какой вывод делает руководитель информационной безопасности?

Если вы уже используете AI-ассистенты, первым делом внедрите журнал запросов и маркировку AI-кода. Это даст видимость, необходимую для последующего аудита, и позволит быстро оценить, какие данные уже ушли наружу. После этого можно построить более сложные проверки (сканирование промежуточных артефактов, ограничение контекста).

Источники

• Habr: Vibe coding без иллюзий (оригинал) – https://habr.com/ru/companies/infera_security/articles/1054934/