Опубликовано: 05.09.2026 | Источник: SecurityLab (RSS)

В марте 2026 года SecurityLab сообщил, что GPT-3.5 позволяет продвинутым хакерам собирать рабочие вирусы даже тем, кто не умеет программировать. Это не спектакль в логах, а реальная эксплуатация LLM как «компилятора» вредоносного кода с интерфейсом на естественном языке. Для студента ИТ-специальности это непривычно «свежая» рамка: защита информационной системы теперь строится в условиях, когда злоумышленник использует генеративные нейросети для автоматизации атак. Если вы хотите, чтобы ВКР выглядела современно и имела практическую ценность, стоит связать её именно с этой угрозой.

Из статьи можно вытащить три прикладных вектора: исследование методик генерации вирусов, разработку модели обнаружения подозрительного кода и анализ социальной инженерии с поддержкой ИИ. Каждый из них легко разворачивается в полноценную работу: от постановки задачи до прототипа и метрик. Ниже — проверенная схема «от кейса к диплому».

Темы ВКР: от новостного кейса к актуальному исследованию

Любая из этих тем позволяет выполнить требования ГОСТ 19/34 и одновременно использовать современную методологию проектирования — будь то диаграммы UML/C4, или описание процесса по PMBOK 7, если руководитель ждёт акцента на управлении разработкой. Не пытайтесь объять всё сразу. В тексте статьи есть ключевая фраза: «от бесполезных спектаклей в логах до вынесения смертных приговоров системе». Она подчёркивает главную проблему: нынешние SIEM и антивирусы нередко не замечают генеративный код, до последнего момента считая его «мусором». Эту гипотезу можно легко проверить в третьей главе.

Основная часть: как перевести кейс в вашу ВКР

Глава 1. Аналитическая база без «воды»

В первом разделе работы важно доказать актуальность и создать понятийный аппарат. Вместо общих слов «в современном мире» приведите конкретный оцененный сценарий, который вынесли из статьи:

• доступность LLM-инструментов в открытых библиотеках (OpenAI API, Hugging Face);
• низкий порог входа для создания рабочих вредоносных скриптов;
• неготовность классических «песочниц» обрабатывать полиморфный контент, который генерируют нейросети.

Обязательно соотнесите классификацию угроз с OWASP. Так атаки на веб-приложения и использование поддельных запросов к API станут систематичными, а не «по картинке из статьи». Добавьте хотя бы одну схему C4 (контейнеры), показывающую место вашего модуля обнаружения в инфраструктуре организации.

Глава 2. Проектирование: стандарты и инструменты

Здесь вы создаёте собственный компонент или методику. Покажите, как именно вы собираетесь детектировать продукт работы нейросети — например, по статистическим признакам токенов, длине конструкций или отсутствию типичных паттернов, которые вносит человек при ручной правке.

Если в проекте нужен код, приведите фрагмент скрипта предобработки логов. Вместо опасного примера генерации вредоносного ПО лучше показать безопасный анализатор — например, снятие признаков с исполняемого файла в песочнице:

import re, hashlib
def extract_features(file_data: bytes) -> dict:
    """Минимальный набор признаков для подозрительного ELF/PE файла."""
    entropy = 0.0  # placeholder
    suspicious_strings = 0
    if len(file_data) < 1000:
        return {'entropy': entropy, 'suspisious_strings': suspicious_strings}
    # Упрощённый расчёт энтропии и нестандартных строк 
    for byte in file_data[:4096]:
        entropy -= (byte / 255) * (byte / 255)  # псевдо-формула, реальная реализация длиннее
    # детекция струй «умных» подсказок: Base64, "llm", "exe"
    suspicious_strings = len(re.findall(rb'(Base64|eval|exec|powershell)', file_data))
    return {'entropy': round(entropy, 3), 'suspisious_strings': suspicious_strings}

Такой материал усиливает вашу ВКР: вы не просто пишете теорию, а демонстрируете владение методами Data Engineering и ИБ. Если вопрос — «как написать ВКР, чтобы руководитель не уснул на первой главе», покажите подобный листинг уже в презентации.

Для соответствия ГОСТ 34 используйте шаблон технического задания на автоматизированную систему. В любой из тем проекта есть раздел «Требования к функциям» — именно там опишите сценарий обработки лога атаки, сгенерированного GPT. Также можно вставить один артефакт по PMBOK 7 — например, реестр рисков («нейросеть устарела», «обучающая выборка утекла»).

Глава 3. Метрики и доказательная база

Почему работа защищаема? Потому что у вас есть цифры. Если вы разработали детектор, посчитайте:

• Precision и Recall по выборке из примеров вредоносного кода (можно собрать в открытых репозиториях, см. FAQ);
• F1-score и сравнение с базовым антивирусом;
• Время детекции в секундах на один файл (если применимо).

Для качества информационной системы в целом используйте ISO/IEC 25010: функциональность, производительность, совместимость, надёжность. Например, сделайте таблицу оценки своей системы по этому стандарту. Рецензенты это любят: видно, что студент мыслит не просто кодом, а критериями качества.

Чему вы научитесь в процессе работы

Помимо классических навыков проектировщика, вы получите конкретные применимые умения:

1. Собирать датасет и валидировать данные для ML-задачи в ИБ без риска нарушить закон.
2. Выявлять аномалии в логах и различать «шум» и реальную LLM-атаку.
3. Строить архив тестовых сценариев для Red Team и Blue Team.
4. Оформлять проект по стандартам ГОСТ и использовать UML/C4-нотацию в пояснительной записке.
5. Понятно защищать результаты: переводить метрики детектора на язык бизнес-рисков.

Типичные ошибки студентов в ВКР по Cybersecurity

FAQ: вопросы, которые реально мучают студентов

1. У меня тема «просто разработка приложения». Как вставить ИИ-угрозы в первый раздел?

Попробуйте позиционировать вашу систему не как веб-сервис, а как средство, устойчивое к атакам с помощью LLM. В первой главе раздела «Анализ угроз» опишите сценарий, где злоумышленник через GPT-3.5 генерирует SQL-инъекции или модифицирует запросы. Если даже диплом не про кибербезопасность, один такой параграф сильно повышает актуальность.

2. Где брать данные для экспериментов?

Для детекта генераций GPT можно попросить модель сгенерировать примеры безвредного кода и перенести их в изолированную среду (VirusTotal не требуется). Используйте открытые датасеты: репозитории OWASP, наборы из Kaggle по фишингу и сборки GitHub с «мусорными» байт-кодами. Для чистоты эксперимента берите не менее 100-200 образцов, чтобы метрики не «скакали».

3. Как быстро проверить F1-метрику, если нет готовой ML-модели?

Начните с простой логистической регрессии на энтропии и количестве опасных строк. Она считается на pandas/sklearn в 30 строк. Если модель окажется слабой — переходите на градиентный бустинг. Главное — отобразить процесс в ВКР: гипотеза → эксперимент → результат. Такой честный путь закроет большинство вопросов рецензента.

4. Что важнее в пояснительной записке: описание по ГОСТ или «красивые» ML-термины?

Баланс: в главах 1 и 2 используйте строгий научно-технический стиль, а в приложении кода допускаются комментарии на русском. Термины (Precision, LLM, SIEM) обязательно расшифруйте. Если сомневаетесь в оформлении схемы C4/UML — попросите шаблон у нормоконтролера заранее, а не за день до сдачи.

Чек-лист: что проверить перед сдачей

Источник: Нейросети на службе хакеров: от бесполезных спектаклей в логах до вынесения смертных приговоров системе (опубликовано 2026-03-22)