Vibe coding ускоряет разработку через промпты к LLM, но размывает контроль: данные уходят в модели, уязвимости тиражируются, при этом DevSecOps не успевает за скоростью изменений. Разбираем, где ломается защита и как выстроить архитектуру контроля в эпоху ИИ.
- 1. Введение
- 2. Где ломается привычная модель безопасности
- 3. Основные риски
- 4. Как вернуть контроль: архитектурный взгляд
- 5. Выводы
Введение
За последний год мы всё чаще сталкиваемся с запросами от заказчиков о том, как контролировать vibe coding. Команды разработки уже активно используют искусственный интеллект (ИИ, или AI от англ. Artificial Intelligence), но часто формально процесс нигде не описан и никак не контролируется, а даже если и контролируется, то вопрос безопасности остаётся за пределами текущего перечня задач. Почти все начинают с автогенерации тестов или рефакторинга, но через пару месяцев ИИ уже участвует в написании бизнес-логики, а разработчик не столько пишет код, сколько ведёт диалог с моделью и быстро принимает её решения, не анализируя и не проверяя вовсе.
Главная троица «автопилотов»: GitHub Copilot, Claude Code и Cursor, который очень популярен в России, так как встраивается в среду разработки (IDE, integrated development environment) на основе Visual Studio Code.
Vibe coding — это постоянный диалог разработчика с ИИ, генерация кода «на лету», быстрые итерации без формального дизайна, перенос части инженерных решений в ИИ. Подход ускоряет разработку в десятки раз, но с точки зрения информационной безопасности в этот момент организация теряет контроль над двумя вещами: куда уходят данные и откуда и какого качества генерируется код. И именно здесь классический DevSecOps перестаёт эффективно справляться.
Уже сейчас есть некоторые ресурсы, которые фиксируют открытые инциденты, связанные с результатами vibe coding. И учитывая масштабы компаний, которые подверглись инцидентам, а также их инвестиции в безопасность, можно предположить, какую угрозу сегодня vibe coding представляет для российских предприятий.
В этой статье разберёмся:
- что именно ломается в классическом DevSecOps, когда команда переходит на vibe coding;
- какие риски появляются сверх привычного набора уязвимостей;
- как выстроить архитектуру контроля так, чтобы не запрещать ИИ, а держать его в рамках допустимого риска.
Рост скорости разработки и удобство ИИ-инструментов создают ощущение полного контроля. Но за этим ускорением скрываются изменения, которые незаметно подрывают привычные подходы к обеспечению безопасности.
Где ломается привычная модель безопасности
DevSecOps изначально строился вокруг довольно простого предположения: код создаётся внутри контролируемой среды, его можно проверить до релиза, объём найденных уязвимостей можно обработать вручную. С применением ИИ это уже не совсем так.
Под vibe coding будем понимать не просто «автодополнение умнее, чем в IDE (integrated development environment)», а режим, где разработчик ведёт постоянный диалог с моделью прямо в IDE, модель генерирует код «на лету», дописывает функции, тесты, конфиги, миграции, при этом часть инженерных решений принимает уже не человек. В такой концепции роль разработчика смещается от «пишу код» к «управляю контекстом и быстро принимаю/отклоняю предложения ИИ».
Типичная эволюция процесса выглядит так:
- Команда начинает с генерации тестов и рефакторинга.
- Через пару месяцев ИИ активно участвует в написании бизнес-логики и инфраструктурного кода.
- Ещё чуть позже у ассистента появляются «ручки» в CI/CD (continuous integration/continuous delivery) и облаке — через агентные сценарии и интеграции.
Скорость разработки действительно растёт. Но как только ИИ-диалог становится основным каналом принятия решений, привычная модель безопасности трещит по швам.
В классической концепции DevSecOps до релиза есть время и ресурсы прогнать код через SAST/DAST/SCA (static application security testing / dynamic application security testing / software composition analysis) и ручной review, а объём изменений и частота релизов позволяют AppSec-команде успевать за выпуском новых версий. Vibe coding эти допущения фактически разрушает.
Реальный рабочий процесс сегодня часто выглядит так:
- Разработчик даёт модели большой контекст (часть проекта, конфиги, куски кода или API).
- Модель генерирует блок кода/конфигурации/скрипт миграции.
- Разработчик слегка адаптирует результат.
- Патч уходит в репозиторий и в CI/CD (continuous integration/continuous delivery).
Формально у нас есть pull request, тесты проходят, SAST что-то посмотрел, ревью «по диагонали» состоялось. Фактически часть разработки произошла вне контролируемых процессов, происхождение решений и кода размылось (человек, модель, смешанный вариант), метрики качества и безопасности перестают быть показателями реального риска.
Поэтому контроль теперь должен появляться не только «на уровне репозитория», но и в 2 дополнительных точках:
- В момент взаимодействия с моделью — какие данные мы ей отдаём, какие сценарии ей вообще разрешены, насколько безопасный код она генерирует.
- В момент использования результата работы модели — что именно она сгенерировала и как это попадает в ваш пайплайн.
Когда процессы разработки меняются, вместе с ними трансформируется и профиль угроз. Риски перестают быть точечными и начинают проявляться системно, затрагивая сразу несколько уровней инфраструктуры.
Основные риски
Эти риски не являются теоретическими: они уже проявляются в реальных инцидентах. Рассмотрим ключевые сценарии, которые возникают при использовании AI в разработке.
Утечки секретов, чувствительной информации через ИИ
Большинство ассистентов расширяют контекст: им нужен не только фрагмент вокруг нужного куска кода, но и соседние файлы, конфиги, иногда рабочие заметки. Если там лежат токены доступа, API-ключи, пароли, персональные данные пользователей, коммерческая тайна, алгоритмы расчёта, внутренние модели рисков — всё это уходит на сторону провайдера модели (или в ваш внутренний ИИ-кластер), логируется, может использоваться в дообучении или стать объектом компрометации.
Для 152-ФЗ это не «неловкость», а реальный инцидент, т. к. данные ушли третьей стороне с нарушением условий обработки. А в случае с паролями доступа произошла отправка данных для управления вашей инфраструктурой, и ни одна система это не отследила.
Что с этим делать:
- Ставить решения класса LLM/AI Firewall, которые контролируют все взаимодействия с ИИ-моделями, через которые проходят все запросы к внешним и внутренним моделям.
- Контролировать на уровне кода и передаваемых данных отсутствие секретов, персональных данных и другой чувствительной информации в коде и промптах.
INFERA AI.Firewall и INFERA AI.SafeCode позволяют командам разработки использовать ИИ-модели и ИИ-кодинг, включая vibe coding, под полным контролем безопасности.
INFERA AI.SafeCode обнаруживает инъекции команд ОС, секреты в коде, отсутствие защиты от XSS, SQL-инъекций, командных инъекций, некорректную обработку входных данных, раскрытие чувствительной и конфиденциальной информации и многое другое.
На примере работы продемонстрируем анализ кода и уязвимость, которая была обнаружена и раскрывает чувствительную информацию.
Рисунок 1. Обнаружение секретов, встроенных в код, с помощью ИИ-анализатора
INFERA AI.Firewall в реальном времени анализирует все запросы и выявляет секреты в коде, отправляемом на анализ в ИИ-модель.
Рисунок 2. Маскирование и защита секретов при передаче данных в LLM через AI Firewall
Массовое тиражирование уязвимостей
LLM не придумывает код с нуля, она воспроизводит паттерны из обучающих данных. Но вместе с лучшими практиками модель приносит небезопасные обработчики ввода, устаревшие или заведомо слабые криптографические решения, «удобные», но уязвимые конфигурации с широкими правами и многое другое.
Разработчик часто воспринимает ответ модели как «разумное дефолтное решение», особенно если оно совпадает с его ощущением «как обычно делают». В результате:
- один небезопасный паттерн из обучающих данных начинает масштабироваться в десятки сервисов;
- типовые ошибки (SQL injection, XSS, SSRF — server-side request forgery) получают новую волну распространения;
- инфраструктурные ошибки множатся быстрее, чем их успевают искать.
И главное во всём этом — их количество пропорционально создаваемому коду, а скорость его создания выросла в разы.
Что с этим делать: обнаруживать уязвимости в коде в реальном времени и автоматически либо подсвечивать их разработчику, либо отправлять на автоматическое исправление.
Рисунок 3. Выявление уязвимостей в ИИ-сгенерированном коде (SQL-инъекции, XSS и др.) в среде разработки
Разрыв между скоростью генерации и скоростью контроля
ИИ делает то, для чего его наняли: радикально ускоряет генерацию кода и конфигураций. Всё остальное — тесты, ревью, SAST, AppSec-практики — растут куда медленнее.
В итоге мы получаем взрывной рост количества изменений, AppSec-команда не успевает, и часть проверок становится формальностью.
Публичные инциденты устроены одинаково: ассистент сгенерировал «удобный» скрипт или конфиг, разработчик проверил только реализацию функций, тесты «зелёные», а в проде внезапно открытая база или другая уязвимость.
Что с этим делать:
- Внедрять подход shift left (смещение контроля на ранние этапы разработки) и сдвигать часть контроля «ближе к началу разработки». Именно такой подход рекомендован в ГОСТ Р 56939—2024 «Защита информации. Разработка безопасного программного обеспечения».
- Интегрировать проверки в ранние стадии разработки (до тяжёлых прогонов).
- Перестроить приоритизацию: изменения с высокой долей ИИ-генерации должны автоматически попадать в зону повышенного внимания AppSec-команды (для этого рекомендуется этот код помечать).
Однако риски не ограничиваются отдельными уязвимостями или утечками. На уровне всей организации формируется более глубокая и долгосрочная угроза, связанная с накоплением данных.
«Образ» компании в облаке
То, что не так важно для бизнеса, но стратегически важно для государства. Если проанализировать весь собранный код в облаке, можно понять, чем занимается компания, получить доступ к её знаниям и ресурсам. Иными словами, сформировать «цифровой двойник» предприятия без вашего ведома. И с каждым запросом он будет всё более точным. Вопрос о том, как и кем будут использованы эти данные, особенно в контексте объектов КИИ, является достаточно серьёзным.
Что с этим делать: использовать локальные модели либо разрабатывать сначала весь код вне защищаемого контура, а потом проверять его и использовать.
ИИ-агенты и удобство «на максимуме» с риском потерять всё
Следующий шаг после классического vibe coding — агентные сценарии: ассистент не только пишет код, но и запускает команды, модифицирует инфраструктуру, запускает пайплайны, ходит в тикет-системы и читает почту.
Если такому агенту выдали «удобные» права, а контроль действий слабый, то риск эскалации и случайных или злонамеренных операций становится очень реален.
Если такому незащищённому агенту прислать письмо с промпт-инъекцией, он будет дальше делать то, что ему укажет злоумышленник, но внутри компании и с самыми широкими правами.
Что с этим делать:
- запускать агентов в изолированном окружении, контролировать права;
- с помощью AI Firewall контролировать поток общения агента с LLM для исключения промпт-инъекций и эксплуатации других уязвимостей;
- проверять навыки (skills) агентов;
- логировать и мониторить действия агентов как действия привилегированных пользователей с возможностью быстрого отключения.
Очевидно, что точечные меры здесь не работают. Требуется системный подход, который учитывает новые точки контроля и распределяет ответственность между уровнями архитектуры.
Как вернуть контроль: архитектурный взгляд
Такой подход предполагает многоуровневую модель защиты, где контроль встроен в ключевые этапы работы с AI.
Эшелон 1. Контроль взаимодействий с ИИ
Этот слой чаще всего отсутствует, так как решения класса AI Firewall на рынке появились недавно, и крупные enterprise-компании только сейчас начинают активно пилотировать и внедрять такие системы.
Что важно:
- все обращения к моделям (внутренним и внешним) идут через единую точку контроля;
- на этом уровне применяется политика: какие типы данных можно отправлять, какие сценарии запрещены, какие модели доступны;
- включается контроль утечек данных и секретов для промптов пользователей и ответов модели;
- контролируются атаки на LLM, что особенно важно при применении агентов;
- логируются факты использования ИИ для последующего аудита.
- На практике это выглядит как proxy или gateway для LLM-моделей.
Рисунок 4. Архитектура LLM Gateway (AI Firewall) для контроля взаимодействий с ИИ-моделями
Эшелон 2. Проверка ИИ-сгенерированного кода
Данный этап ближе к привычному AppSec, но с нюансами: ИИ-код нужно проверять строже, важно отдельно отслеживать его происхождение и не только «найти проблему», но и блокировать её попадание в pipeline. Иначе всё снова сведётся к рекомендациям, которые никто не успевает исправлять.
Для сгенерированного кода необходимо ввести дополнительные правила:
- контролировать уязвимости сгенерированного ИИ-кода с помощью специальных инструментов;
- помечать ИИ-фрагменты в репозитории (через метаданные, теги, комментарии).
Важно, чтобы система умела не только находить проблемы, но и блокировать их путь в прод, иначе всё сведётся к бесконечному списку рекомендаций, которые «как-нибудь потом разберём». Конечно, всё должно быть сведено в автоматический CI/CD (continuous integration/continuous delivery).
Эшелон 3. Наблюдаемость и аудит
Их обычно недооценивают до первого инцидента. Важно иметь возможность ответить на вопросы: кто использовал ИИ, для какого проекта, какие данные передавались, какой код был сгенерирован, прошёл ли он проверки. Без этого расследование становится практически невозможным.
Эшелон 4 (если применимо). Защита ИИ агентов
Этап контроля за агентами. Для понимания руководства — это как идеальный сотрудник, который внезапно может решить работать на конкурента и не боится ответственности.
На этом слое необходимо:
- контролировать агентов, ограничивать их возможности «рабочими обязанностями»;
- защищать агентов от внешних посягательств;
- фиксировать всё, что они делают.
Нужно вводить политики использования ИИ, контролировать модели, отслеживать взаимодействия и измерять риски, т. к. ИИ перестаёт быть «инструментом разработчика» и становится частью поверхности атаки (attack surface).
Выводы
Запретить ИИ уже не получится — придётся либо контролируемо внедрять его, либо отстать от конкурентов. Контроля только на уровне DevSecOps недостаточно, нужен отдельный слой управления и контроля ИИ-взаимодействиями.
Vibe coding — это не временный тренд, а новая нормальность разработки. Проблема в том, что он развивается быстрее, чем практики безопасности. Если ничего не менять, организация постепенно потеряет контроль над данными, кодом и всей инфраструктурой.
