Security Vision: вайбкодинг — это опасно

Безопасность

30 Апреля 2026 11:57 30 Апр 2026 11:57

| Поделиться

Security Vision: вайбкодинг — это опасно

Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, вместе с аналитиками SOC Андреем Максимовым и Михаилом Корниловымрассмотрели риски, связанные с использованием генеративного ИИ в разработке (так называемый вайбкодинг). На примере исследования, посвященного оценке возможностей ИИ при создании проектов, а также анализа публично доступных артефактов для удаленного администрирования информационных систем, была продемонстрирована опасность бесконтрольного применения нейросетей. В качестве иллюстрации специалисты представили кейс, в котором отсутствие учета принципов безопасной разработки может привести к утечке чувствительных данных в открытые репозитории. Также были обозначены подходы к снижению подобных рисков и безопасному решению задач в рамках таких проектов.

Новые вызовы: когда ИИ упрощает, но не обеспечивает безопасность

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

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

Результаты OSINT-разведки: доступ к инфраструктуре за несколько запросов

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

• Учетные данные веб-панелей разрабатываемых ресурсов (логины, пароли, почты) в исходных кодах, по своей структуре напоминающие реальные данные.
• URL веб-интерфейсов управления в проектах, ведущие на различные сервисы.
• SSH-ключи и конфигурации для подключения к стендам.

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

Снижение порога входа в разработку

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

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

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

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

Для описания сценария реализации атаки в случае реализации подобного проекта была построена цепочка полной компрометации (килчейн):

• Разведка: поиск IP-адресов и артефактов в открытых репозиториях.
• Доступ: использование найденных учетных данных от веб-панели.
• Сбор данных: извлечение SSH-ключей из конфигураций панели.
• Управление: полный контроль над инфраструктурой через веб-интерфейс.

Как снизить риски

По итогам исследования эксперты компании сформулировали обязательные меры защиты, которые должны применяться при использовании вайбкодинга и работе с репозиториями:

1. Проверка предлагаемых нейросетями решений поставленной задачи:

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

2. Защита чувствительной информации и правила эксплуатации репозиториев:

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

3. Автоматизированный мониторинг:

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

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

• CNews Forum Кейсы 2026

Поделиться

Подписаться на новости

Короткая ссылка