Риски vibe coding: как ИИ-разработка меняет безопасность

Архитектурный сдвиг: контроль перемещается за пределы репозитория

Классический DevSecOps построен на предположении, что код создаётся внутри контролируемой среды. Изменения проходят code review, затем SAST, SCA, DAST и другие проверки. При массовом vibe coding часть разработки происходит до репозитория, до pull request и до CI/CD. Именно там возникает новый слой риска.

На практике это выглядит так: разработчик отправляет модели большой фрагмент проекта — код, конфиги, API-контракты, stack trace, логи, иногда данные из тикетов. SAST-конвейер что-то находит, создаётся задача, но большая часть уходит в далёкий бэклог. Уязвимости попадают в релиз, потому что объём сгенерированного кода велик, а количество сработок превышает пропускную способность команды. Формально процесс контролируется. Фактически — нет.

Контроль теперь нужно смещать не только влево (Shift Left), но и выше по цепочке: к моменту взаимодействия разработчика с ИИ-моделью.

Три точки уязвимости, которые не покрывают традиционные проверки

Первая: утечка контекста. AI-ассистенты работают лучше с широким входным контекстом. Разработчик отправляет в модель не одну функцию, а соседние файлы, конфигурации,.env-файлы, stack trace, фрагменты логов, JSON-примеры, API-контракты. Среди них могут оказаться секреты, персональные данные, внутренние алгоритмы, код критичных систем. Этот контекст покидает периметр организации до того, как проходит хотя бы одну проверку.

Вторая: атрибуция кода. Ответить на вопрос «какой фрагмент кода был написан человеком, а какой сгенерирован ИИ» — в текущих инструментах практически невозможно. Без этой метаданны невозможно корректно оценить покрытие проверками и определить ответственность за инженерное решение.

Третья: слепые зоны SAST. Сгенерированный код может содержать классы уязвимостей, которые существующие анализаторы не распознают. Статические проверки обучены на паттернах, написанных людьми; генеративные модели воспроизводят и комбинируют паттерны из обучающих данных — в том числе устаревшие и небезопасные.

Практический чек-лист для команд

• Инвентаризация точек взаимодействия. Определить, какие AI-инструменты используются, какой контекст передаётся, на какие внешние сервисы уходят данные.
• Политика контекста. Запретить передачу в модели секретов,.env, credentials, персональных данных и конфиденциальных конфигов. Автоматизировать фильтрацию.
• Логирование и атрибуция. Внедрить метки (например, в git trailers или специализированные расширения), фиксирующие, какой фрагмент кода сгенерирован ИИ. Это критично для аудита.
• Адаптация CI/CD. Добавить в конвейер проверки, заточенные на паттерны генеративного кода: нестандартные обработчики ошибок, неделегированные валидации, «фантазирующие» хелперы с несуществующими API.
• Лимит на объём AI-кода в одном PR. Крупные генерации сложнее ревьюить; разбивать на мелкие коммиты с явной разметкой.
• Обучение команды. Разработчики должны понимать, что «модель предложила» не равно «безопасно проверено». Решение принимает инженер, а не LLM.

Vibe coding — не временное увлечение, а структурный сдвиг в процессе разработки. Игнорировать его бесполезно. Задача платформенных и AppSec-команд — построить контрольные плоскости вокруг нового процесса, а не пытаться вернуть старый.