Логотип

Статья

«Джин из бутылки»: почему вайбкодинг может обернуться катастрофой для бизнеса

Генеративный ИИ ускоряет разработку, но одновременно создает новые бреши в безопасности. Эксперты Security Vision провели исследование и выяснили, что неконтролируемое использование нейросетей для написания кода (вайбкодинг) приводит к утечкам ключей, паролей и конфиденциальных данных в открытые репозитории. В материале — на реальном кейсе и с конкретными рекомендациями, как снизить риски.

Когда скорость разработки убивает безопасность

С приходом больших языковых моделей процесс создания кода изменился до неузнаваемости. Вайбкодинг — практика генерации программного кода на основе запросов на естественном языке — резко ускорил появление прототипов и снизил порог входа в профессию. Однако, у этого ускорения есть темная сторона.

«Вайбкодинг напоминает джина, который исполняет запрос буквально, — комментирует Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision. — Модель оптимизирует решение под заданный запрос, игнорируя все, что явно не указано в задаче: управление доступом, защиту учетных данных и ключей, аутентификацию и журналирование. Пользователь без достаточной экспертизы получает формально рабочий, но потенциально опасный код. Аккуратный внешний вид кода часто создает ложное чувство надежности и иллюзию качества».

Открытые источники как кладезь секретов

В ходе исследования специалисты Security Vision применили методику OSINT (анализ открытых источников), структурированную по модели «4П» (Предметная область, Понятия, Процессы, Потоки информации). Используя публичные доменные имена, методы DNS-резолвинга и специализированные поисковые запросы, команда выявила в открытом доступе проекты, содержащие различные артефакты, принадлежащие как организациям, так и частным пользователям. Среди находок — учетные данные веб-панелей разрабатываемых ресурсов (логины, пароли, почты) в исходном коде, по своей структуре напоминающие реальные данные; URL веб-интерфейсов управления в проектах, ведущие на различные сервисы; а также SSH-ключи и конфигурации для подключения к стендам. Получение этих данных не требует специальных программ или глубоких знаний в пентестинге, однако ставит под угрозу инфраструктуру, которой эти данные принадлежат.

Эксперимент: написали проект на ИИ и чуть не «утекли»

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

Реализация проекта выявила ряд критических особенностей сгенерированного кода. LLM предлагала опубликовать проект в публичном репозитории в системе контроля версий, не уделяя внимания вопросам управления доступом. Логика добавления данных для подключения устройств не предусматривала вынесение секретов за пределы директории проекта, и при этом модель не указала на риски подобной реализации. По умолчанию отсутствовали механизмы аудита действий пользователей, что затруднило бы проведение расследований при использовании решения в реальной инфраструктуре. Реализованная система логирования допускала редактирование записей без фиксации факта и содержания изменений. Отсутствовали файлы и настройки, предотвращающие публикацию чувствительных данных. После написания проекта модель старалась убедить пользователя в безопасности кода, предлагая опубликовать его, вместо того чтобы провести тестирование. Все данные для подключения и описание функциональности были размещены в файле README.md, что повышает риск раскрытия чувствительной информации.

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

Как хакеры возьмут вашу инфраструктуру за несколько шагов

Для описания сценария реализации атаки в случае реализации подобного проекта была построена цепочка полной компрометации. Первый этап — разведка: поиск IP-адресов и артефактов в открытых репозиториях. Второй — доступ: использование найденных учетных данных от веб-панели. Третий — сбор данных: извлечение SSH-ключей из конфигураций панели. Четвертый — управление: полный контроль над инфраструктурой через веб-интерфейс.

Что делать: меры защиты от «опасного кода»

Какие же обязательные меры защиты должны применяться при использовании вайбкодинга и работе с репозиториями?

Первое — проверка предлагаемых нейросетями решений поставленной задачи. Необходим обязательный многоуровневый контроль, включая проверку архитектуры и логики работы, обязательное изучение всего сгенерированного кода. Любой сгенерированный фрагмент кода должен быть явно помечен. Также нужно проверить наличие механизмов аутентификации (MFA, ограничение попыток входа, смена пароля при первом входе), отсутствие секретов в коде (вынос в переменные окружения), запустить автоматизированный статический анализ (SAST) с использованием специализированных инструментов, а также обязательно добавить в логику программы необходимую и достаточную систему логирования действий без возможности редактирования зафиксированных событий.

Второе — защита чувствительной информации и правила эксплуатации репозиториев. По умолчанию все репозитории должны быть закрытыми (политика приватности). Обязательно добавление файла .gitignore до первого коммита. Недопустимо хранение в коде файлов .env, ключей (.key, .pem) и баз данных. Необходимо использовать защищенные хранилища секретов.

Третье — автоматизированный мониторинг. Нужно внедрить инструменты сканирования репозиториев с обязательным сигнатурным поиском и энтропийным анализом, а также выполнять проактивный мониторинг внешнего периметра для обнаружения утечек в реальном времени.

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