Николай Гончаров, директор департамента мониторинга кибербезопасности 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. Автоматизированный мониторинг:
• Внедрение инструментов сканирования репозиториев: обязательно сигнатурный поиск и энтропийный анализ.
• Выполнение проактивного мониторинга внешнего периметра для обнаружения утечек в реальном времени.
«Ответственность за интеграцию кода, даже если он создан с помощью ИИ, всегда остается за специалистом, – подчеркивает Николай. – Проведенное нами исследование наглядно показало: чрезмерное доверие к решениям, предлагаемым генеративными ИИ-моделями, может привести к уязвимостям в инфраструктуре компаний, особенно в сценариях, при которых игнорируются профессиональная экспертиза и автоматизированные средства контроля. Для минимизации всех рисков, связанных с информационной безопасностью, необходимо применять лучшие практики безопасной разработки и отраслевых стандартов и встраивать контроль непосредственно в сам цикл разработки с использованием ИИ. ИИ ускоряет создание кода, и защита должна успевать за этим темпом».