По данным ГК «Солар», облачные LLM несут риски пропуска критичных уязвимостей и утечки исходного кода. Компания представила анализ эффективности шести больших языковых моделей на этапах триажа и исправления уязвимостей кода в безопасной разработке. Это облачные платформы GigaChat 3 PRO, ChatGPT 5.2, Deepseek 3.2.
Нейросетевая поддержка
На фоне дефицита квалифицированных AppSec-специалистов и стремительного роста объемов кода, генерируемого с помощью нейросетей и low-code платформ, понимание ограничений и возможностей текущих моделей критически важно для минимизации рисков и предотвращения дорогостоящих инцидентов безопасности. В этой связи ГК «Солар» представила результаты исследования эффективности шести больших языковых моделей (LLM), которые используются для самых трудоемких этапов верификации (triage, триаж) и исправления уязвимостей кода (codefix, кодфикс) в безопасной разработке.
Ситуация на рынке IT-разработки характеризуется высокой скоростью выхода продуктов в промышленную эксплуатацию (продакшн), что зачастую идет в ущерб качеству проверки безопасности. Среди факторов, усложняющих этот процесс, авторы исследования выделили основные. В частности, для полноценной защиты приложения требуется проведение от двух до трех и более циклов проверки в зависимости от объема обнаруженных уязвимостей. Кроме того, существуют жесткие нормативные требования к безопасности кода, в частности со стороны ФСТЭК России, которые разработчики обязаны соблюдать при выпуске ПО.
В то же время полный ручной цикл проверки, включающий триаж и исправление кода, занимает в среднем от четырех рабочих дней одного профильного специалиста. При масштабировании разработки нагрузка на экспертов растет нелинейно, создавая «бутылочное горлышко». В результате наблюдается острая нехватка кадров: дефицит ИБ-специалистов, недостаточный уровень экспертизы у существующих сотрудников и частые конфликты мнений экспертов замедляют процесс принятия решений.
Как указано в исследовании, уже к началу 2025 года, по предварительным оценкам, более 70% новых приложений создавались с помощью GenAI и low-code/no-code инструментов. Это еще сильнее увеличивает разрыв между скоростью написания кода и скоростью его верификации. Таким образом, недостаток ресурсов приводит к накоплению технического долга, стоимость устранения которого напрямую зависит от этапа жизненного цикла разработки (SDLC).
К примеру, на поздних этапах разработки стоимость возрастает в 10 раз по сравнению с ранним обнаружением. На этапе непосредственного запуска приложения в эксплуатацию стоимость увеличивается в 640 раз. В случае возникновения реального инцидента безопасности, когда приложением уже пользуются миллионы клиентов, стоимость ликвидации последствий возрастает в тысячу раз. Чтобы ускорить процесс безопасной разработки, компании начинают использовать доступные LLM для этих этапов, таким образом оптимизируя время и затраты на AppSec-специалистов.
Итоги исследования
Эксперты Solar appScreener проанализировали 20 приложений на языках Java и Python. Выбор обусловлен их доминирующим положением на рынке: Java (45,4% популярности в РФ) преобладает в банковском секторе и финтехе, Python (61,8%) является стандартом для машинного обучения, анализа данных и веб-разработки. Объем кода в каждом проекте составил более 100 тыс. строк. Список тестируемых моделей включал облачные платформы (GigaChat 3 PRO, ChatGPT 5.2, DeepSeek 3.2), on-premise версии (ChatGPT OSS 20b, Mistral 14b) и специализированное решение DerTriage/DerCodeFix. Предварительно был проведен SAST-анализ, выявивший около 12 000 уникальных срабатываний, из которых 20% имели высокую критичность.
Как указывают авторы исследования, структура запроса к LLM предполагала передачу следующих параметров: название и подробное описание типа выявленной уязвимости, релевантный сегмент исходного кода, содержащий подозрительную конструкцию, трассу достижимости, описывающую путь прохождения данных от источника до потенциально небезопасной функции. Плюс дополнительные идентификаторы уязвимостей в соответствии с классификацией CWE и специальный пользовательский паттерн, наставляющий модель проводить анализ с позиции опытного аналитика по информационной безопасности.
Эффективность работы языковых моделей оценивалась по четырем ключевым метрикам: точность, процент ошибок, прецизионность и полнота (способность модели обнаружить все реально существующие уязвимости в представленном проекте).
По итогам работы моделей было выявлено наличие значительного риска при полной передаче функций безопасности на сторону ИИ. В частности, модели ChatGPT и DeepSeek демонстрируют пропуск от 40% до 50% уязвимостей в коде на Java и Python, что создает ложное чувство защищенности. Несмотря на высокую скорость генерации кода с помощью GenAI, этап триажа и верификации остается критическим звеном, где LLM пока не могут полностью заменить человека.
В связи с этим, как указывают авторы исследования, использование LLM оправдано только как вспомогательный инструмент для оптимизации времени AppSec-специалистов, но не как автономная система принятия решений. Эффективность моделей чувствительна к качеству входных данных (SAST-результаты, контекст и CWE), однако даже при детальных промптах сохраняется высокий процент пропусков критических проблем.
По мнению руководителя операционной поддержки Solar appScreener Антона Прокофьева, LLM на этапе верификации уязвимостей кода в разы оптимизируют время, но иллюзия скорости на масштабных проектах создает риски пропуска критичных уязвимостей в конечном софте, поэтому точность работы и процент ошибок используемой LLM - важнейшие показатели. «Кроме того, облачные LLM становятся каналом утечки исходного кода, что создает дополнительные риски для информационной безопасности продукта. Поэтому рекомендуем обратить внимание на локальные (on-premise) LLM, которые используются в закрытом контуре компании», - добавил он.
Фото: Шедеврум.