Уязвимости Java и Python в эпоху LLM: обоснование для диплома и примеры внедрения
Согласно исследованию группы компаний «Солар» (март 2026), даже самые популярные большие языковые модели — ChatGPT и DeepSeek — пропускают от 40 до 50% уязвимостей в приложениях на Java и Python. Это означает, что полагаться только на LLM при аудите безопасности кода пока рискованно. Для студентов IT-направлений такой тренд открывает сразу несколько точек роста: от выбора адекватного инструментария до проектирования гибридных систем, где нейросети сочетаются с классическими SAST-решениями. В этой статье разберём, как конкретно привязать эту новость к структуре ВКР, какие метрики взять для расчётов и как обосновать стек перед научным руководителем.
Темы ВКР, которые можно построить вокруг исследования «Солар»
| Направление | Актуальность (отсылка к статье) | Цель | 3–4 задачи |
|---|---|---|---|
| Разработка гибридного SAST-сканера с LLM-валидацией | LLM сами по себе пропускают до 50% уязвимостей — нужно дообучение или эскалация к классическим статическим анализаторам. | Создать прототип системы, где ChatGPT/DeepSeek выступают фильтром ложных срабатываний для SonarQube или Checkmarx. | 1) Сравнить точность 3–4 LLM на датасете OWASP Low/Medium; 2) Разработать пайплайн «SAST → LLM → вердикт»; 3) Оценить время детекции и F1-score. |
| Анализ эффективности LLM в DevSecOps-пайплайнах для Java/Python | Исследование «Солар» показывает, что модели по-разному находят CWE — нужно эмпирическое исследование для CI/CD. | Определить, на каком этапе (pre-commit, PR-check, nightly) LLM дают наибольший выигрыш. | 1) Развернуть GitLab CI с эталонным сканером; 2) Интегрировать OpenAI и DeepSeek через API; 3) Замерить Recall, Precision и время; 4) Сформулировать рекомендации по порогу срабатывания. |
| Метрики безопасности кода при использовании LLM-ассистентов | Без метрик невозможно доказать, что LLM улучшает (или ухудшает) качество кода. | Построить дашборд (Prometheus + OpenTelemetry) с метриками плотности дефектов, времени исправления и охвата. | 1) Собрать историю коммитов с уязвимостями; 2) Внедрить тегирование LLM- и ручного кода; 3) Сравнить метрики ISO/IEC 25010: reliability, security. |
Как привязать статью к разделам диплома
Аналитическая глава: обоснование стека и границ исследования
В первой главе обычно проводят обзор аналогов. Результаты «Солар» дают вам готовый аргумент: «Ни одна LLM не обеспечивает приемлемого качества безопасности кода без дополнительной верификации». Можно построить сравнительную таблицу, где колонками будут ChatGPT, DeepSeek, Claude, а строками — классы уязвимостей (SQLi, RCE, XSS). Источник: CNews, 2026. Важно указать, что данные получены на датасете из 500+ примеров — это повышает доверие к вашему анализу. В этой же главе стоит упомянуть стандарты: ГОСТ 34.602-89 (ТЗ на АС) и ISO/IEC 25010 (модель качества). Если пишете «ВКР на заказ» без погружения в тему, такие отсылки часто упускают — а зря, руководители их ждут.
Проектная часть: архитектура решения
Опишите, как вы интегрируете несколько инструментов. Пример схемы:
Код → SonarQube (SAST) → ChatGPT API (верификация) → GitLab Issue
↓
OpenTelemetry → Prometheus → Grafana (метрики F1, задержка)Такой гибридный подход снижает процент ложных срабатываний и компенсирует 40–50% пропусков LLM. В проектной части обязательно приведите UML-диаграммы (варианты использования, последовательность). Многие студенты боятся рисовать схемы, но это как раз то, за что эксперты хвалят на защите. Используйте PlantUML или draw.io — главное, чтобы все элементы были подписаны по ГОСТ 34.
Тестирование и метрики: нагрузка, RTO/RPO, мониторинг
Здесь вы отвечаете на типичный вопрос студента: «Как измерить производительность в дипломе?». Для вашей системы подойдут:
- Нагрузочное тестирование — сколько запросов к LLM выдержит ваш пайплайн (JMeter, k6).
- Метрики безопасности — Recall (полнота), Precision (точность) и F1-score по классам уязвимостей из OWASP Top 10.
- RTO/RPO — если сканер упадёт, сколько времени потребуется на восстановление. Свяжите это с требованиями ISO 25010.
- OpenTelemetry — собирайте трейсы каждого вызова LLM, чтобы потом доказать, что задержка < 1 секунды (или наоборот, что это узкое место).
Не забудьте указать, что тестовые данные вы взяли из открытых датасетов (SARD, CWE) или сгенерировали на основе реальных CVE. Это снимает претензии по плагиату и нехватке исходных данных.
Типичные ошибки студентов (и как их избежать)
- Подмена терминов без обоснования. Пишут «SaaS-решение», хотя в дипломе речь о standalone-инструменте. Всегда привязывайте термин к архитектуре: если используете API облачной LLM — это SaaS; если локальная модель (Llama) — on-premise.
- Отсутствие метрик эффективности. Выводы «система стала лучше» без цифр не принимают. Обязательно приведите F1-меру, Recall, Precision и сравните с базовым SAST-сканером.
- Игнорирование ГОСТ 34.602-89 при оформлении ТЗ. Даже если диплом практический, техническое задание должно содержать разделы «Требования к функции», «Требования к надёжности», «Порядок контроля». Шаблон легко найти, но студенты часто опускают — и теряют баллы.
FAQ по практической части
Обязательно ли писать код в дипломе по такой теме?
Да, но не обязательно с нуля. Допустимо взять open-source SAST-сканер (например, SpotBugs для Java) и написать модуль-адаптер к LLM. Руководитель оценит интеграцию, а не объём строк. Если совсем нет времени — можно заказать ВКР с прототипом, но я советую хотя бы собрать пайплайн в Docker Compose и приложить скриншоты.
Где брать тестовые данные для расчёта метрик?
Используйте публичные датасеты: OWASP Benchmark, SARD (Software Assurance Reference Dataset) или CWE-связанные примеры из GitHub. Ещё вариант — взять 50-100 реальных уязвимостей из открытых репозиториев (CVE-2024-xxx) и разметить их вручную. Второе займёт время, но повысит уникальность.
Как оформить UML/диаграммы, чтобы не забраковали?
Рисуйте в draw.io или LucidChart. Для ВКР достаточно диаграммы вариантов использования (use case) и диаграммы последовательности (sequence). Подпишите все акторы, включите комментарии по потоку данных. Важно: диаграммы не должны противоречить тексту — частая ошибка, когда на схеме одни компоненты, а в описании другие.
Чек-лист «Что проверить перед сдачей»
- ✓ Есть ссылка на источник (CNews, 2026) в списке литературы или сноске.
- ✓ Задачи и выводы соответствуют: если в задачах было «сравнить модели», то в заключении должны быть цифры Recall/Precision.
- ✓ Приведена хотя бы одна схема архитектуры (можно в приложении).
- ✓ Таблицы числовых данных соответствуют требованиям ГОСТ 7.32 (подписи, единицы измерения).
- ✓ В разделе «Экономика» (если требуется) указан хотя бы прирост метрик безопасности в процентах.
- ✓ Код (если есть) не содержит ключей API — используйте переменные окружения.
- ✓ Доклад на защите укладывается в 5–7 минут, с акцентом на проблему из статьи «Солар».
Чему вы научитесь, проработав эту тему
- Обосновывать выбор архитектуры с опорой на реальные бенчмарки (а не авторитет «так принято»).
- Интегрировать LLM в CI/CD-пайплайн, настраивать мониторинг через OpenTelemetry.
- Рассчитывать метрики безопасности (F1, полнота) и связывать их с требованиями ISO/IEC 25010.
- Оформлять техническую документацию по ГОСТ 34.602-89 — навык, который пригодится на первой же работе.
Нужна консультация или готовая ВКР? Мы предлагаем помощь с дипломом любой сложности — от технико-экономического обоснования до внедрения Kubernetes-кластеров. Первая консультация (до 120 часов по объёму работ) — бесплатно. Оставляйте заявку, и эксперт подберёт тему под ваши сроки и требования вуза.
Источник: Уязвимости в тени: ChatGPT и DeepSeek пропускают от 40 до 50% уязвимостей в приложениях на Java и Python (опубликовано 2026-03-16)
```