За последний год в разработке произошёл сдвиг, который многие компании пока недооценивают. ИИ-ассистенты перестали быть «умным автодополнением» и стали полноценными участниками инженерного процесса. Разработчики используют GitHub Copilot, Claude Code, Cursor, Codeium, Tabnine, локальные LLM и внутренние AI-агенты не только для генерации тестов или рефакторинга, но и для написания бизнес-логики, инфраструктурного кода, CI/CD-конфигураций, миграций БД и API-контрактов.

На практике это часто выглядит так: разработчик не столько пишет код, сколько ведёт диалог с моделью, быстро принимает её решения и сразу отправляет результат в pull request. Этот стиль получил название vibe coding.

Vibe coding действительно ускоряет разработку. Но с точки зрения информационной безопасности он меняет саму модель контроля. Организация начинает терять прозрачность в двух критичных точках:

• какие данные уходят в ИИ-модель;

• откуда взялся сгенерированный код, насколько он безопасен и кто фактически принял инженерное решение.

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

В этой статье разберём:

• что ломается в привычной модели DevSecOps при переходе к vibe coding;

• какие новые риски появляются у AI-сгенерированного кода;

• почему контролировать нужно не только код, но и все взаимодействия разработчиков и AI-агентов с LLM.

Что такое vibe coding

Под vibe coding будем понимать не просто автодополнение кода в IDE, а режим разработки, при котором разработчик ведёт постоянный диалог с ИИ-моделью, передаёт ей контекст проекта, просит сгенерировать функции, тесты, конфиги, миграции, обработчики API, Terraform-манифесты или скрипты автоматизации.

В этом режиме роль разработчика смещается: раньше он самостоятельно проектировал и писал код, а теперь он формулирует задачу, управляет контекстом и быстро принимает или отклоняет результат модели.

Где ломается привычная модель безопасности?

Vibe coding меняет реальный процесс разработки, и он всё чаще начинает выглядеть так:

• Разработчик отправляет модели большой фрагмент проекта: код, конфиги, API-контракты, stack trace, логи, иногда данные из тикетов.

• Модель генерирует решение.

• Разработчик слегка адаптирует результат.

• Патч уходит в pull request.

• Review проводится быстро, потому что «тесты зелёные».

• SAST или DevSecOps-конвейер что-то находит, создаётся задача, но большая часть задач уходит в далёкий бэклог.

• Уязвимости попадают в релиз, т.к. объем кода очень большой и, соответственно, количество сработок тоже, исправить все разработчики просто не успевают.

Формально процесс контролируется. Фактически часть разработки произошла вне зоны видимости AppSec, CISO и платформенной команды.

Возникают новые вопросы, на которые без использования средств контроля сложно будет ответить:

• какие данные были отправлены в модель;

• были ли среди них секреты, персональные данные, внутренние алгоритмы, код критичных систем;

• какой фрагмент кода был написан человеком, а какой с помощью ИИ;

• проверялась ли логика, которую предложила модель;

• не внедрила ли модель небезопасный паттерн;

• не сгенерировала ли она зависимость с известными CVE;

• не создала ли она конфигурацию с избыточными правами;

• не появился ли в коде новый класс уязвимостей, который старые проверки не покрывают,

• удалось ли проверить весь код, который был написан и особенно тот, что был сгенерирован ИИ.

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

Основные риски vibe coding

1. Утечки секретов, персональных данных и коммерческой информации через AI

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

В этом контексте могут оказаться API-ключи, JWT-токены, пароли к тестовым или production-средам, приватные ключи, персональные данные, сведения об инфраструктуре, адреса внутренних сервисов, фрагменты кода критичных систем.

Если эти данные уходят во внешний LLM-сервис, организация фактически теряет контроль над их дальнейшей обработкой. Даже если провайдер заявляет, что не использует данные для обучения, остаются вопросы логирования, доступа персонала к этим данным, хранения, инцидентов и соответствия требованиям регуляторов.

Для российских компаний это особенно важно в контексте152-ФЗ, коммерческой тайны, требований к КИИ и внутренних политик обработки данных. Отправка кода и конфигураций во внешнюю модель может быть не просто техническим риском, а нарушением режима обработки информации.

Что делать:

• пропускать все обращения к LLM через контролируемый шлюз;

• использовать решения класса LLM Firewall / AI Firewall;

• проверять prompt и context на наличие секретов, ПДн и чувствительных данных;

• ограничивать, какие модели можно использовать для каких проектов;

• логировать факты обращения к ИИ;

• применять маскирование и редактирование чувствительных данных до отправки в модель;

• отдельно контролировать ответы модели, так как она тоже может вернуть секрет, небезопасную инструкцию или вредоносный код.

В такой архитектуре LLM/AI Firewall выступает как единая точка контроля взаимодействий с LLM. Он анализирует запросы и ответы, выявляет секреты, персональные данные, подозрительные инструкции, prompt injection, jailbreak-попытки и рискованные сценарии использования.

И важно дополнять этот слой на стороне кода: искать секреты в репозиториях, проверять валидность ключей, выявлять раскрытие чувствительной информации, небезопасную обработку данных и уязвимости, которые могли появиться в результате AI-генерации.

2. Массовое тиражирование уязвимых паттернов

LLM генерирует код на основе статистически вероятных паттернов. Проблема в том, что в обучающих данных много небезопасного кода. Модель может уверенно предложить решение, которое выглядит привычно, проходит тесты, но содержит уязвимость.

Типовые примеры: SQL-запросы через конкатенацию строк, отсутствие параметризации, SSRF через неконтролируемый URL, небезопасная десериализация, command injection через os.system, subprocess, Runtime.exec, слабая криптография, отключение TLS verification и многое другое.

Опасность в том, что один и тот же небезопасный паттерн может быть сгенерирован десятки раз в разных сервисах. Разработчик воспринимает ответ модели как «нормальное дефолтное решение», особенно если код выглядит аккуратно и проходит unit-тесты.

Скорость появления таких ошибок становится пропорциональна скорости генерации кода. Если раньше команда писала 1000 строк в неделю, а теперь с помощью ИИ пишет 5000, то и поверхность атаки растёт кратно.

Что делать:

• проверять AI-сгенерированный код в реальном времени;

• подсвечивать уязвимости прямо в IDE;

• использовать SAST, SCA, Secrets, IaC scanning, DAST, API Fuzzing и Fuzzing как единый контур;

• не ограничиваться сигнатурами, а подтверждать уязвимости доказательствами;

• автоматически создавать pull request с исправлением;

• помечать код, сгенерированный ИИ, и применять к нему более строгие политики.

3. Разрыв между скоростью генерации и скоростью контроля

ИИ радикально ускоряет создание кода. Но review, AppSec, тестирование и исправление уязвимостей не ускоряются автоматически.

В результате появляется новый дисбаланс: кода становится больше, изменений становится больше, pull request становятся чаще, AppSec-команда остаётся прежнего размера, SAST и SCA генерируют ещё больше алертов, а разработчики начинают игнорировать результаты проверок.

Классическая проблема AppSec – это «шум». Команда подключает SAST, DAST, SCA сканеры и получает сотни алертов. Около 70–80% из них оказываются false positive, дубликатами или низкоприоритетными находками. В итоге разработчик видит 247 «критических» проблем и закрывает вкладку.

С vibe coding эта проблема усиливается. Если ИИ ускорил разработку в несколько раз, то и поток потенциальных уязвимостей вырос в несколько раз.

Что делать:

• внедрять Shift Left и Shift Everywhere;

• проверять код уже в IDE, до коммита;

• блокировать pipeline только по подтверждённым High/Critical;

• применять AutoTriage;

• дедуплицировать находки между SAST, DAST, Fuzzing и API Fuzzing;

• автоматически формировать remediation и pull request;

• выделять AI-сгенерированный код как зону повышенного внимания.

В ГОСТ Р56939-2024 «Защита информации. Разработка безопасного программного обеспечения» закреплена логика раннего выявления и устранения дефектов безопасности. Vibe coding делает этот подход ещё более актуальным: если проверка начинается только в конце pipeline, она уже опоздала.

4. Уязвимости в зависимостях, которые предлагает ИИ

Ещё один недооценённый риск: LLM часто предлагает подключить библиотеку, пакет или Docker image, не проверяя его безопасность.

Но модель может предложить устаревшую версию пакета, использовать библиотеку с известными CVE, сослаться на заброшенный open-source проект, сгенерировать Dockerfile с уязвимыми зависимостями, использовать небезопасный пример из старой документации и т.д.

Особенно опасны атаки на supply chain. Если модель рекомендует пакет, похожий по названию на популярную библиотеку, разработчик может не заметить подмену. В экосистемах npm, PyPI, RubyGems и Maven подобные атаки давно стали массовыми.

Что делать:

• проверять все новые зависимости через SCA;

• строить SBOM на каждый билд;

• контролировать источники пакетов;

• проверять лицензии;

• использовать private registry и allowlist;

• отслеживать reachability уязвимых зависимостей;

• блокировать критичные CVE в CI/CD.

Но важно не просто найти CVE, а понять, достижима ли уязвимость из вашего кода. Если зависимость уязвима, но опасная функция не вызывается, то приоритет один. Если есть путь от пользовательского ввода до уязвимого sink, то приоритет должен выставляться другой.

5. Ошибки авторизации и бизнес-логики

ИИ хорошо генерирует типовой код. Но он плохо понимает контекст прав доступа, бизнес-ограничений и внутренних правил компании, если они явно не описаны.

Поэтому AI-сгенерированный код часто страдает от ошибок авторизации, т.к. пользователь может получить чужой объект по ID, админская функция может стать доступна обычному пользователю, отсутствует проверка владельца ресурса, API может возвращать лишние поля и т.д.

Это классы BOLA, BFLA, IDOR, mass assignment, excessive data exposure. Они плохо ловятся классическим SAST и плохо покрываются обычными unit-тестами.

Что делать:

• использовать multi-role DAST;

• применять API Fuzzing на основе OpenAPI, GraphQL schema, .proto, AsyncAPI;

• проверять роли и scopes;

• сравнивать ответы под разными пользователями;

• искать аномалии авторизации на call graph;

• выполнять negative testing API;

• включать бизнес-правила в security checks.

6. Prompt injection и атаки на AI-агентов

Следующий уровень риска – это AI-агенты. Это уже не просто ассистент в IDE, а система, которая может читать репозиторий, запускать команды, создавать pull request, вызывать API, читать почту или документацию, принимать решения на основе внешнего контента.

Для AI-агентов появляются новые классы угроз: prompt injection, data exfiltration через модель, выполнение нежелательных команд, подмена зависимостей, обход политик и многое другое.

Что делать:

• запускать агентов в sandbox;

• ограничивать права по принципу least privilege;

• разделять read-only и write-действия;

• требовать approval для опасных операций;

• контролировать каждый вызов инструмента (tool calls);

• фильтровать входящий и исходящий контекст через LLM Firewall;

• логировать действия агентов как действия привилегированных пользователей;

• иметь возможность быстро отключить агента;

• проверять навыки, плагины и инструментарий агентов.

Все современные LLM/AI Firewall в этой архитектуре должны контролировать поток общения агента с LLM, выявлять prompt injection, попытки обхода политик, утечки данных и небезопасные инструкции. Это важно, потому что агент с доступом к репозиторию, CI/CD и облаку становится частью attack surface компании.

7. «Цифровой двойник» компании во внешней модели

Есть риск, который редко обсуждают в контексте обычного AppSec, но он важен для крупных предприятий, промышленности, банков, телекома, госсектора и объектов КИИ.

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

Это можно назвать «цифровым двойником» предприятия, созданным без явного согласия бизнеса и службы безопасности.

Что делать:

• классифицировать проекты по допустимости использования внешних моделей;

• для критичных контуров использовать локальные LLM;

• внедрять LLM Firewall как обязательный шлюз;

• запрещать передачу секретов, ПДн, конфигураций и критичного кода во внешние модели;

• вести аудит всех AI-взаимодействий;

• использовать self-hosted DevSecOps-инструменты;

• применять локальный анализ кода.

Как отличать реальные риски от «шума»

SAST остаётся важным инструментом, но в мире vibe coding он уже не закрывает весь риск. Поэтому нужен не один сканер, а единая платформа, которая объединяет разные сканеры и умеет отличать реальные риски от «шума».

INFERA AI.SafeCode как раз закрывает этот сценарий. Платформа объединяет SAST, SCA, Secrets, DAST, Pentest, Code Fuzzing и API Fuzzing в единый DevSecOps / MLSecOps-контур. Она не просто показывает список подозрений, а подтверждает уязвимости через proof-based подход: HTTP-ответ, crash-log, OOB-callback, taint-chain или воспроизводимый PoC.

INFERA AI.SafeCode построен именно как комплексная платформа для DevSecOps / MLSecOps. Она объединяет:

• SAST – анализ исходного кода в реальном времени прямо в среде разработки;

• SCA – анализ open-source зависимостей;

• Secrets – поиск и верификация секретов;

• DAST – динамический анализ работающего приложения;

• Pentest – AI-агент для имитации ручного пентеста;

• Code Fuzzing – поиск crash и edge-case уязвимостей;

• API Fuzzing – анализ REST, GraphQL, gRPC и WebSocket API.

Все сканеры работают как единая система, а не как набор отдельных инструментов. К каждой подтвержденной уязвимости прилагается рекомендация с исправлением, а проблема подсвечивается прямо во время написания кода с предложением quick-fix (параметризация SQL, экранирование HTML и т.д.). Комментарии отображаются на проблемных строках с доказательством и кнопкой «применить AutoFix».

Запрещать ИИ в разработке уже поздно

Команды всё равно будут использовать AI-инструменты: официально или неофициально. Более реалистичная задача – не запретить, а встроить ИИ в управляемую модель риска.

Эшелон 1. Контроль всех взаимодействий с ИИ через LLM Firewall

Первый слой должен находиться до репозитория и до CI/CD — в момент общения разработчика, IDE, агента или внутреннего сервиса с LLM.

INFERA AI.Firewall закрывает именно этот слой. Он позволяет не просто «разрешить или запретить ChatGPT», а управлять использованием ИИ в разработке: какие модели доступны, какие данные можно отправлять, какие сценарии запрещены, какие действия требуют дополнительного контроля.

Эшелон 2. Контроль AI-сгенерированного кода в IDE

Чем раньше найдена уязвимость, тем дешевле её исправить. Поэтому проверка должна происходить не только в CI/CD, но и прямо в IDE.

INFERA AI.SafeCode интегрируется в среду разработки и позволяет разработчику видеть проблему до коммита. Это особенно важно при vibe coding: если модель сгенерировала небезопасный код, разработчик должен узнать об этом сразу, а не через неделю после nightly scan.

Эшелон 3. Контроль в pull request

Pull request остаётся ключевой точкой инженерного контроля, но он должен быть усилен.

Эшелон 4. Контроль в CI/CDCI/CD должен быть не местом, где команда впервые узнаёт об уязвимости, а последней линией защиты

Главное правильно настроить блокировки. Если pipeline падает на каждое неподтверждённое предупреждение, разработчики быстро начнут обходить контроль. Поэтому INFERA AI.SafeCode блокирует только по подтверждённым High/Critical-уязвимостям.

Эшелон 5. Наблюдаемость и аудит

Для CISO и AppSec важно иметь возможность ответить на вопросы после инцидента: кто использовал ИИ, какую модель, для какого проекта, какие данные отправлялись и т.д. Без такого аудита расследование превращается в догадки.

INFERA AI.Firewall закрывает аудит взаимодействий с LLM, а INFERA AI.SafeCode – аудит жизненного цикла уязвимостей, действий пользователей, агентов, LLM-judge, AutoTriage и AutoFix.

Эшелон 6. Контроль AI-агентов

Если в разработке используются AI-агенты, их нужно рассматривать как привилегированных пользователей и как новую поверхность атаки. AI-агент, который умеет читать репозиторий, создавать PR и запускать pipeline, не должен работать без контроля. Иначе достаточно одного indirect prompt injection, чтобы он начал выполнять действия в интересах злоумышленника.

Vibe coding – это не временный тренд, а новая нормальность разработки

Vibe coding ускоряет команды, снижает порог входа, помогает быстрее создавать функции, тесты и инфраструктуру. Но одновременно он меняет и увеличивает поверхность атаки.

Раньше основным объектом контроля был код в репозитории. Теперь контролировать нужно ещё и диалог с моделью, передаваемый контекст, ответы LLM, действия AI-агентов и происхождение инженерных решений.

Компании, которые попытаются просто запретить ИИ, скорее всего получат теневое использование инструментов без какого-либо контроля. Компании, которые встроят ИИ в управляемый DevSecOps / MLSecOps-контур, смогут сохранить скорость разработки и не потерять безопасность.

Минимальная рабочая модель выглядит так: все LLM-взаимодействия проходят через AI Firewall, AI-сгенерированный код проверяется в IDE, pull request и CI/CD, критичные находки подтверждаются доказательствами, pipeline блокируется только по реальным рискам, а действия пользователей, моделей и агентов остаются в аудите.

Именно такой подход позволяет использовать главное преимущество vibe coding без потери контроля над данными, кодом и инфраструктурой.