Эксперты Security Vision разобрали, как ИИ-код без контроля приводит к утечкам, показав методы OSINT-разведки и меры защиты инфраструктуры
На форуме ГосСОПКА Николай Гончаров, директор департамента мониторинга кибербезопасности Security Vision, вместе с аналитиками SOC Андреем Максимовым и Михаилом Корниловым в своем выступлении рассмотрели риски, связанные с использованием генеративного ИИ в разработке (так называемый «вайбкодинг»). На примере исследования, посвященного оценке возможностей ИИ при создании проектов, а также анализа публично доступных артефактов для удаленного администрирования информационных систем, была продемонстрирована опасность бесконтрольного применения нейросетей. В качестве иллюстрации специалисты представили кейс, в котором отсутствие учета принципов безопасной разработки может привести к утечке чувствительных данных в открытые репозитории. Также были обозначены подходы к снижению подобных рисков и безопасному решению задач в рамках таких проектов.
С появлением больших языковых моделей подход к разработке кардинально изменился. Вайбкодинг — практика генерации кода на основе запросов на естественном языке — существенно ускоряет создание прототипов и снижает порог входа. Однако, как показало исследование Security Vision, у этой медали есть обратная сторона.
«Вайбкодинг напоминает «джина», который исполняет запрос буквально, — комментирует Николай Гончаров. — Модель оптимизирует решение под заданный запрос, игнорируя все, что явно не указано: управление доступом, защиту учетных данных и ключей, аутентификацию и журналирование. Пользователь без достаточной экспертизы получает формально рабочий, но потенциально опасный код. Аккуратный внешний вид кода часто создает ложное чувство надежности и иллюзию качества».
В ходе исследования специалисты Security Vision применили методику OSINT (анализ открытых источников), структурированную по модели «4П» (Предметная область, Понятия, Процессы, Потоки информации). Используя публичные доменные имена, методы DNS‑резолвинга и специализированные поисковые запросы (дорки), команда выявила в открытом доступе проекты, содержащие различные артефакты, принадлежащие как организациям, так и частным пользователям: учетные данные веб-панелей разрабатываемых ресурсов (логины, пароли, почты) в исходных кодах, по своей структуре напоминающие реальные данные; URL веб-интерфейсов управления в проектах, ведущие на различные сервисы; SSH-ключи и конфигурации для подключения к стендам.
Получение этих данных не требует использования специальных программ или особых знаний в тестировании на проникновение, однако ставит под угрозу инфраструктуру, которой эти данные принадлежат.
Для проверки гипотезы об опасности слепого доверия генеративным сетям, с их помощью был написан проект, позволяющий осуществлять удаленное администрирование систем тестового сегмента от лица доверенного пользователя.
В качестве запросов к модели использовались формулировки, написать которые может любой пользователь, далекий от мира информационной безопасности. В ходе работы специально не акцентировалось внимание на подходах безопасной разработки. Реализация проекта показала следующие важные особенности сгенерированного кода: LLM предлагала опубликовать проект в публичном репозитории в системе контроля версий, не уделяя внимания вопросам управления доступом. Логика добавления данных для подключения устройств не предусматривала вынесение секретов за пределы директории проекта и при этом модель не указала на риски подобной реализации. По умолчанию отсутствовали механизмы аудита действий пользователей, что затруднило бы проведение расследований при использовании решения в реальной инфраструктуре. Реализованная система логирования допускала редактирование записей без фиксации факта и содержания изменений. Отсутствовали файлы и настройки, предотвращающие публикацию чувствительных данных. После написания проекта, модель старалась убедить пользователя в безопасности кода, предлагая опубликовать его, вместо того чтобы провести тестирование. Все данные для подключения и описание функциональности были размещены в файле README.md, что повышает риск раскрытия чувствительной информации.
Фактически, реализация подобного проекта в реальной системе пользователями, не понимающими, как следует разрабатывать продукт, настраивать видимость репозитория и отделять конфиденциальные данные от данных проекта, может привести к полной компрометации системы.
Для описания сценария реализации атаки в случае реализации подобного проекта была построена цепочка полной компрометации (килчейн): разведка (поиск IP-адресов и артефактов в открытых репозиториях), доступ (использование найденных учетных данных от веб-панели), сбор данных (извлечение SSH-ключей из конфигураций панели) и управление (полный контроль над инфраструктурой через веб-интерфейс).
По итогам исследования эксперты компании сформулировали обязательные меры защиты, которые должны применяться при использовании вайбкодинга и работе с репозиториями. Первая группа мер касается проверки предлагаемых нейросетями решений поставленной задачи: необходим обязательный многоуровневый контроль, включая проверку архитектуры и логики работы, а также обязательное изучение всего сгенерированного кода. Любой сгенерированный фрагмент кода должен быть явно помечен. Важно проверить наличие механизмов аутентификации (MFA, ограничение попыток входа, смена пароля при первом входе), обеспечить отсутствие секретов в коде (вынос в переменные окружения) и запустить автоматизированный статический анализ (SAST) с использованием специализированных инструментов. Также необходимо обязательное добавление в логику программы необходимой и достаточной системы логирования действий без возможности редактирования зафиксированных событий.
Вторая группа мер направлена на защиту чувствительной информации и правила эксплуатации репозиториев: политика приватности должна подразумевать, что по умолчанию все репозитории закрыты. Требуется обязательное добавление файла .gitignore до первого коммита. Недопустимо хранение в коде файлов .env, ключей (.key, .pem) и баз данных, следует использовать защищенные хранилища секретов.
Третья группа мер предполагает автоматизированный мониторинг: внедрение инструментов сканирования репозиториев, где обязательно сигнатурный поиск и энтропийный анализ, а также выполнение проактивного мониторинга внешнего периметра для обнаружения утечек в реальном времени.
«Ответственность за интеграцию кода, даже если он создан с помощью ИИ, всегда остается за специалистом, — подчеркивает Николай. — Проведенное нами исследование наглядно показало: чрезмерное доверие к решениям, предлагаемым генеративными ИИ-моделями, может привести к уязвимостям в инфраструктуре компаний, особенно в сценариях, при которых игнорируются профессиональная экспертиза и автоматизированные средства контроля. Для минимизации всех рисков, связанных с информационной безопасностью, необходимо применять лучшие практики безопасной разработки и отраслевых стандартов и встраивать контроль непосредственно в сам цикл разработки с использованием ИИ. ИИ ускоряет создание кода, и защита должна успевать за этим темпом».
Выбор редакции
Публикации, которые получают больше внимания и попадают в Сюжеты РБК
Рекомендации партнеров: