Всем привет, на связи Solar appScreener!
В этой статье расскажем о нашем опыте использования ИИ в нашем собственном продукте.
ИИ‑агенты уже стали неотъемлемой частью процесса разработки, это больше не мимолетный хайп, а новая реальность. По данным исследования Sonar (State of Code Developer Survey 2026, https://www.sonarsource.com/state‑of‑code‑developer‑survey‑report.pdf), 72% разработчиков, попробовавших использовать ИИ, стали использовать его ежедневно. А 42% всего написанного кода уже сгенерирован ИИ, или существенно им доработан. Какие‑то запредельные числа. Стоит признать, что мы живем в новой реальности, в которой вайбкодинг — это новый стиль программирования.
Но остается незакрытым вопрос — а что там происходит с безопасностью этого кода?! И тут данные неутешительны. ИИ продолжает генерировать код с уязвимостями. 45% образцов кода, генерируемых ИИ, оказались небезопасными (Veracode. GenAI Code Security Report, https://www.veracode.com/blog/genai‑code‑security‑report/). Это как подбросить монетку, безопасный ли код был сгенерирован или нет. Не то, что хочется от видеть в разрезе безопасности. Вот несколько основных причин, почему так происходит:
Модели обучались на огромных массивах публичного кода, перенимая паттерны и стиль его написания. И там было много уязвимостей и небезопасных шаблонов кода
ИИ не «понимает» что такое безопасность как концепция в написании кода, а продолжает статистически вероятную последовательность токенов
ИИ пока не может держать «в уме» весь проект целиком, где в нем и как курсирует чувствительная информация, например, определение пользователя, поэтому ошибается.
Но это не значит, что ИИ не может решать проблемы безопасности. Может, и еще как!
Сейчас все больше вендоров идут в сторону умного внедрения ИИ в свои продукты. Наиболее успешными кейсами по текущим исследованиям (Veracode. GenAI Code Security Report, https://www.veracode.com/blog/genai‑code‑security‑report/, Checkmarx 2025 Trends on AI Security, https://checkmarx.com/learn/ai‑security/2025-trends‑on‑ai‑security‑how‑appsec‑must‑evolve‑with‑the‑ai‑shifted‑sdlc/) является применение ИИ для триажа найденных уязвимостей и генерации для них исправлений. Интересный факт — никто не пророчит замену ИИ классических SAST/DAST анализаторов, напротив, они получают дополнительный буст для развития за счет ИИ.
Как выглядит классический SAST:
Почему на классический триаж не хватает времени?
Поэтому возникает вопрос: как автоматизировать всю эту рутину и получать сэмплы безопасного кода? Может ИИ?
А вот здесь стоит задать себе еще несколько вопросов:
Какие данные передавать ИИ?
Где взять ИИ?
Автоматизируем ли мы на самом деле триаж с помощью ИИ?
Автоматизируем ли мы на самом деле исправление кода с помощью ИИ?
Что произойдет с конфиденциальностью моего кода и данных?
Зная все эти «боли», мы в «Соларе» за несколько лет до того, как вайб‑кодинг стал повседневностью, начали разработку ИИ‑плагина для нашего продукта Solar appScreener. Он называется DerAI и включает две технологии: DerTriage (триаж уязвимостей, которые находит анализатор SAST) и DerCodeFix (генерация исправленного кода для таких сработок). И всё это даже в on‑prem, а не только в «облаке»!
Как это работает
В appScreener давно существовал механизм для фильтрации ложных сработок — Fuzzy Logic Engine. Это запатентованная нами технология использует математический аппарат нечеткой логики для определения истинности срабатывания. Мы 7 лет анализировали и размечали различные Open Source проекты, как заведомо уязвимые, так и обычные проекты, исследовали документацию библиотек и фреймворков, писали соответствующие тест‑кейсы для оттачивания этого механизма. И весь этот накопившийся объем размеченных данных лег в основу обучения нашей собственной модели.
Мы протестировали различные Open Source LLM, выявили оптимальную модель, и принялись за ее дообучение накопленной нами информацией. Поскольку вся разметка исходных данных изначально происходила с помощью appScreener, то и итоговая модель заточена под него, и они отлично работают в тандеме, конкретные цифры будут ниже.
А вот как DerTriage и DerCodeFix выглядят в интерфейсе.
На вход для обработки подается не просто код‑семпл, а вся информация, доступная анализатору. Это описания правил, рекомендации и примеры по исправлению, вся трасса уязвимости с дополнительным контекстом для каждого узла, и другие метаданные. Дополнительные инструкции по правильной работе с имеющейся кодовой базой для сохранения ее работоспособности. Это важно при генерации фиксов.
Все это позволило получить на выходе компактную оптимизированную модель, обладающую отличными показателями точности и эффективности. Всё по заветам Брюса Ли.
Чем это лучше, чем просто спросить у ИИ‑модели:
Широкопрофильная LLM «захламлена» лишней информацией. Возвращаемся к тезису, что генерирует код она плохо, и безопасность там 50/50. Также это высокое потребление ресурсов в on‑prem варианте: чем больше модель, тем больше она потребляет. Плюс риски потери конфиденциальности кодовой базы при отправке ее сканирования в «облако» к зарубежным компаниям.
Отметим и сложность поиска. Попробуйте скинуть ей большой файл с кодом и попросите найти в нем уязвимости. А потом просканируйте его разными SAST‑анализаторами. Результаты совпадать не будут. А что с межпроцедурным анализом? А межфайловым? А с анализом во время сборки? Такое обычная LLM не сможет, а вот SAST+LLM вполне.
Итак, теперь самое интересное. Перейдем к баттлу облачных и локальных LLM в AppSec
Из больших облачных LLM мы рассматривали:
ChatGPT 5.2
DeepSeek 3.2
Gigachat
Из сопоставимых по размеру локальных моделей выбрали:
ChatGPT OSS openai/gpt‑oss-20b 05/08/2025
Mistral 14b-2512 02/12/2025
LocalChat
Сначала мы проанализировали 20 приложений, написанных на Java и Python. Почему именно эти языки? Во‑первых, они относятся к категории самых простых и сложных языков для ИИ в разрезе безопасности (Veracode. GenAI Code Security Report, https://www.veracode.com/blog/genai‑code‑security‑report/), во‑вторых, они очень распространены: их доля составляет 45,4% и 61,8% среди основных языков программирования в России.
Все приложения довольно масштабные — от 100 000 строк кода, поэтому массив данных собрали большой. Выявили около 12 000 уникальных сработок анализатора, при этом пятая часть уязвимостей относилась к категории критических.
Дальше мы сформировали единый промпт. Он включал системные данные: название уязвимости, описание, сегмент кода, трассу достижимости (путь данных до небезопасной функции), дополнительные идентификаторы уязвимостей (CWE). Мы также добавили пользовательский паттерн «Представь, что ты опытный AppSec». Таким образом все модели получили на вход одинаковый массив информации и промт, все кристально идентично.
Итак, триаж: что оцениваем?
Будем оценивать 4 метрики — общая точность, прецизионность, полнота и процент ошибок:
Общая точность — насколько верно LLM определяет истинность и ложность срабатывания. Рассчитывается как (TP+TN)/ALL
Прецизионность — сколько реальных уязвимостей среди тех, что LLM отметила, как истинные. Рассчитывается как TP/(TP+FP).
Полнота — сколько из реальных уязвимостей проекта были выявлены LLM. Рассчитывается как TP/(TP+FN).
Процент ошибок — насколько часто LLM ошибается в процессе разметки. Рассчитывается как (FP+FN)/ALL.
На всякий случай напомним, что это за аббревиатуры:
TP — LLM верно подтвердила истинное срабатывание
TN — LLM верно отклонила ложное срабатывание
FP — LLM ошибочно подтвердила ложное срабатывание
FN — LLM ошибочно отклонила истинное срабатывание
Java‑проекты
Например, при обработке результатов сканирования проекта vulnado модели показали такие результаты:
При анализе на всей подборки Java‑проектов, и суммаризации результатов, получаем такие метрики:
Ремарка по поводу полноты 100% у ChatGPT. Это достигнуто за счет заметного ухудшения других оценок. Если все сработки анализатора подтвердить, то FN будет = 0, а значит полнота = 100%. Но это не значит, что LLM отлично справилась, напротив, она не смогла отфильтровать ложные сработки, что и повлекло снижение остальных метрик.
Python‑проекты
Например, при обработке результатов сканирования проекта vulpy модели показали такие результаты:
При анализе на всей подборки Python‑проектов, и суммаризации результатов, получаем такие метрики:
ChatGPT ведет себя диаметрально противоположно, и устремил не FN=0, а FP=0, путем отклонения массы истинных сработок, что отражено в других метриках.
Результирующая таблица
Из тестов видно, что как на более сложном для организации безопасности для ИИ Java, так и на более простом Python, специальная заточенная под AppSec модель DerAI показывает себя значительно лучше конкурентов для триажа уязвимостей.
Теперь время DerCodeFix
С ним проще. Будем оценивать исправляет ли предложенный фикс уязвимость (Good), или нет (Not Good), и смотреть на точность обработки.
Результирующая таблица
По исследования задача генерации исправления заметно труднее, чем триаж уязвимостей. И это наглядно подтверждается статистикой. Здесь натренированность и заточенность модели DerAI под решение конкретных задач прослеживается как нельзя лучше.
Наши выводы:
ИИ более чем применим в AppSec, и индустрия к этому активно движется. Но использование классических LLM для решения текущих задач непродуктивно: дешевле и проще подбрасывать монетку при триаже, а эффективность будет не хуже больших LLM. Но решение есть, это узкопрофильные, заточенные под безопасность модели, интегрируемые в сам анализатор безопасности кода, такие как DerAI в appScreener. Такие модели показывают отличные результаты уже сегодня и более чем применимы в жизни в настоящее время.
Ждем ваши мысли, идеи в комментариях!