ChatGPT и DeepSeek пропускают от 40 до 50% уязвимостей в приложениях на Java и Python.
Группа компаний «Солар» проанализировала эффективность шести больших языковых моделей (large language model, LLM), которые используются для самых трудоемких этапов верификации (triage, триаж) и исправления уязвимостей кода (codefix, кодфикс) в безопасной разработке. В среднем для полноценной проверки приложения необходимо провести от двух-трех циклов проверки и более в зависимости от объема уязвимостей в ПО перед выходом «в прод».
Дополнительные требования к безопасности кода также предъявляет ФСТЭК России. В среднем полный цикл проверки (триаж и кодфикс) занимает от четырех дней из расчета рабочего времени одного AppSec-специалиста, но при увеличении объема разработки нагрузка возрастает в несколько раз.
Триаж не успевает за разработкой
По данным аналитиков Б1, к 2025 году более 70% новых корпоративных приложений создавались с использованием low-code/no-code и GenAI. А 87% корпоративных ИТ- разработчиков уже используют платформы разработки low-code/no-code для части своих разработок. ИИ ускоряет написание кода, при этом триаж не успевает за разработкой. Команды разработки сталкиваются с нехваткой ИБ-специалистов и опытных разработчиков, с недостаточным уровнем экспертизы, конфликтами мнений экспертов.
Если не хватает ресурсов, то в приложениях закономерно накапливается технический долг, устранение которого с каждым этапом становится все дороже. Так, стоимость устранения уязвимостей возрастает в 10 раз на поздних этапах разработки, в 640 раз – на этапе запуска приложения, и в 1 000 раз, если уязвимость привела к ИБ-инциденту в момент, когда приложение используют миллионы клиентов. Чтобы ускорить процесс безопасной разработки, компании используют доступные LLM для этих этапов, оптимизируя время и затраты на AppSec-специалистов.
Эффективность LLM
Эксперты Solar appScreener проанализировали эффективность нескольких востребованных LLM при проверке кода 20 приложений, написанных на языках Python и Java. Масштаб каждого из софтверных проектов составил более 100 тыс. строк кода. По данным исследования ассоциации «Руссофт», доля языков Java и Python составляет 45,4% и 61,8% среди 10 основных языков программирования в России. Java наиболее распространена при разработке приложений в банковском секторе, финтехе, высоконагруженных веб-сервисов, а также Android-приложений.
Python в свою очередь остается основным инструментом в проектах по машинному обучению, анализу данных, разработке нейросетей. Он также входит в топ-3 популярных языков для создания веб-приложений наряду с JavaScript и PHP. Поэтому выбранные приложения стали релевантной базой для исследования.
Для исследования эксперты выбрали крупные облачные платформы GigaChat 3 PRO, Chat GPT 5.2, Deepseek 3.2. В эксперимент также включили on-premise-версии ChatGPT OSS (openai/gpt-oss-20b 05/08/2025), Mistral (14b-2512 02/12/2025) и специализированную LLM DerTriage/DerCodeFix.
Аналитики Solar appScreener с помощью SAST-анализа выявили около 12 тыс. уникальных срабатываний в исследованных приложениях, при этом доля уязвимостей высокой критичности составила почти 20%. После анализа срабатываний они сформировали единый промпт для всех исследуемых LLM. Запрос включал системные данные: название уязвимости, описание, сегмент кода, трассу достижимости (путь данных до небезопасной функции), дополнительные идентификаторы уязвимостей (CWE). Аналитики также добавили в промпт пользовательский паттерн, чтобы LLM проанализировали данные с позиции опытного аналитика ИБ.
Критерии оценки
Эксперты оценивали возможности LLM на этапе триажа по четырем критериям. Наиболее важные из них – точность (насколько верно языковая модель определяет истинность и ложность срабатываний) и процент ошибок, который отражает, как часто LLM ошибается во время разметки срабатываний. Также эффективность LLM изучали по критериям прецезионности (количество реальных уязвимостей среди тех, которые модель отметила как истинные) и полноты (количество реальных уязвимостей в проекте, которые смогла выявить модель).
В проектах на Java ChatGPT продемонстрировал 60,9 % точности среди облачных LMM. Но в контексте безопасной разработки это означает, что модель пропускает около 40% уязвимостей, что является критичным показателем и требует дополнительных циклов проверки в «ручном» режиме. DeepSeek был точен всего в половине случаев. В проектах на Python DeepSeek показал более 80% точности, а ChatGPT – 52,7%. Среди on-premise моделей наиболее высокие показатели – свыше 80% точности для языков Java и Python – продемонстрировала LLM DerTriage. Другие модели в этой категории были точны в 66–67% случаев.
«LLM на этапе верификации уязвимостей кода в разы оптимизируют время, которое команды разработки используют для циклов проверки софта. Но иллюзия скорости на масштабных проектах создает риски пропуска критичных уязвимостей в конечном софте, поэтому точность работы и процент ошибок, используемой LLM, – важнейшие показатели. Кроме того, облачные LLM становятся каналом утечки исходного кода, что создает дополнительные риски для информационной безопасности продукта. Поэтому рекомендуем обратить внимание на локальные (on-premise) LLM, которые используются в закрытом контуре компании», – пояснил Антон Прокофьев, руководитель операционной поддержки Solar appScreener.
Исправление уязвимостей
Второй этап исследования – исправление уязвимостей (кодфикс). Аналитики «Солара» использовали три основных критерия для оценки. Они включают количество исправлений, которые устраняют реальную уязвимость (good) или не устраняют (not good), а также точность. На этом этапе для приложений на Java ChatGPT продемонстрировал 61,8% точности, DeepSeek – 45,5%, а на Python эти LLM показали 46,6% и 44,8% соответственно. Локальная on-premise модель DerCodeFix продемонстрировала 78,2% точности для Java и 83,1% для Python.
«По итогам нашего исследования мы видим, что общедоступные модели в большинстве случаев неэффективны на самых трудоемких этапах проверки качества кода. Без должного уровня экспертизы команда разработки рискует пропустить в продукте критичные уязвимости, понадеявшись на возможности LLM. Большую часть рисков можно устранить только благодаря комбинации экспертизы и специализированных LLM. Для этого необходимо использовать модели, которые обучены на практике триажа и кодфикса миллионов софтверных проектов, работают в закрытом контуре, а результаты их работы обязательно должны проверяться AppSec-инженером», – рассказал Антон Прокофьев.
Аналитики Solar appScreener отмечают, что практика использования облачных LLM (ChatGPT, DeepSeek и др.) в безопасной разработке приложений наиболее распространена в сфере здравоохранения, образования, финтехе и ритейле с высокой долей операций, связанных с персональными данными клиентов, а также в робототехнике, индустриальном ПО с повышенными требованиями к безопасности кода на уровне цепочки поставок. С учетом выводов исследования, облачные LLM создают дополнительные риски для кибербезопасности софтверных продуктов. Нехватка экспертизы и доверие к выводам ИИ без участия человека в перспективе повышают расходы бизнеса на устранение уязвимостей на более поздних этапах разработки и использования продукта в десятки раз.
Источник: Группа компаний «Солар»
