Управление уязвимостями в дипломе: от баг-репорта до метрик MTTR

Поддомен: Cybersecurity. Роль: специалист по ИБ (Application Security / Vulnerability Management).

Сюжет, который разошёлся по ИТ-каналам в конце марта 2026 года, выглядит как бытовая ссора: разработчик, годами присылавший отчёты об уязвимостях в Apple, публично заявил, что их просто складывают в корзину, а в ответ приходит сухая отписка. Неприятную правду, по его словам, долго прятали под ковёр. Для выпускника это не сплетня, а готовый каркас практической части ВКР: здесь есть процесс, участники, сроки, метрики и очевидная проблема — отсутствие прозрачности в обработке отчётов о недостатках безопасности.

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

Частые вопросы до начала работы

Три темы ВКР, которые вырастают из этого кейса

• Тема 1. Автоматизация процесса ответственного раскрытия уязвимостей (VDP) в корпоративной среде.
  Актуальность: публичный конфликт вокруг Apple показал, что даже зрелые компании теряют репутацию и исследователей из-за непрозрачной обработки отчётов.
  Цель: сократить медианное время реакции на отчёт об уязвимости за счёт автоматизации триажа и маршрутизации.
  Задачи: (1) проанализировать ISO/IEC 29147 и ISO/IEC 30111; (2) спроектировать целевую архитектуру VDP по C4; (3) реализовать модуль нормализации и приоритизации отчётов; (4) оценить эффект по метрикам MTTD/MTTR.
  Структура: Глава 1 — анализ практик раскрытия и стандартов; Глава 2 — проектирование и реализация системы триажа; Глава 3 — эксперимент на стенде и оценка эффективности.

• Тема 2. Оценка зрелости программы bug bounty: модель, метрики, чувствительность.
  Актуальность: «ваши отчёты летят в корзину» — это отсутствие измеряемых критериев приёмки; без модели зрелости конфликт исследователя и вендора неизбежен.
  Цель: построить модель оценки зрелости программы вознаграждений и проверить её на выборке открытых программ.
  Задачи: (1) сформировать набор метрик; (2) собрать датасет по публичным программам; (3) реализовать расчёт индекса зрелости; (4) провести анализ чувствительности модели.
  Структура: Глава 1 — теория управления уязвимостями и разбор кейсов; Глава 2 — проектирование модели и её реализация; Глава 3 — расчёты, визуализация, интерпретация.

• Тема 3. Интеграция данных сканеров уязвимостей в SIEM с использованием OpenTelemetry.
  Актуальность: отчёт, попавший в почтовый ящик и не превратившийся в событие безопасности, автоматически «улетает в корзину»; единый конвейер телеметрии такую потерю исключает.
  Цель: обеспечить сквозную наблюдаемость жизненного цикла уязвимости от сканирования до закрытия.
  Задачи: (1) описать модель данных события уязвимости; (2) настроить приём телеметрии; (3) построить дашборд с ключевыми метриками; (4) проверить полноту и задержку доставки событий.
  Структура: Глава 1 — обзор подходов к наблюдаемости и управлению уязвимостями; Глава 2 — проектирование конвейера и реализация; Глава 3 — нагрузочные испытания и оценка задержек.

Как разложить кейс по главам

Глава 1. Анализ: где живёт теория

Первый раздел — не пересказ новости, а постановка проблемы. Начните с хронологии взаимодействия исследователя и вендора, вынесите её в таблицу «дата — действие — результат — срок реакции». Затем разложите нормативную базу: ISO/IEC 29147 описывает обязанности раскрывающей стороны, ISO/IEC 30111 — процесс обработки уязвимостей внутри организации. Добавьте OWASP ASVS как источник требований к проверяемому приложению и ISO/IEC 25010 как рамку для последующей оценки качества — характеристики security и reliability у вас будут измеримыми, а не декларативными.

Диаграммы этого раздела: BPMN-схема «как есть» (отчёт → почта → тишина) и «как должно быть» (отчёт → триаж → воспроизведение → исправление → публикация). Разница между двумя схемами и есть обоснование вашей разработки.

Глава 2. Проектирование и реализация: техническая часть

Здесь важно не уйти в чистую разработку «ещё одного сканера» — комиссия это видела сотни раз. Ваша ценность в конвейере: как разрозненные отчёты становятся приоритизированным потоком работ. Начните с модели данных — сущности «Отчёт», «Уязвимость», «Актив», «Исполнитель», «Решение по отчёту». Дальше покажите расчёт приоритета: он должен быть объяснимым, иначе на защите спросят «почему 7.4, а не 6.8?» и вы замолчите.

from opentelemetry import trace
from dataclasses import dataclass

tracer = trace.get_tracer("vdp.reports")

@dataclass
class Report:
    id: str
    cvss: float
    has_poc: bool
    asset_class: str  # internet | internal | test

WEIGHTS = {"internet": 1.0, "internal": 0.6, "test": 0.2}

def priority(report: Report) -> float:
    """Приоритет = CVSS с поправками на наличие PoC и класс актива."""
    score = report.cvss + (0.5 if report.has_poc else 0.0)
    return round(min(score * WEIGHTS.get(report.asset_class, 0.5), 10.0), 2)

def triage(report: Report) -> dict:
    with tracer.start_as_current_span("triage.report") as span:
        p = priority(report)
        span.set_attribute("report.id", report.id)
        span.set_attribute("report.priority", p)
        span.set_attribute("report.asset_class", report.asset_class)
        return {"id": report.id, "priority": p, "sla_hours": 72 if p >= 7.0 else 168}

Второй артефакт — автоматизация сбора свидетельств. Ниже пример конвейера, который складывает машиночитаемые результаты проверки состава зависимостей в артефакты сборки. Такие файлы удобно прикладывать к ВКР как приложение и как доказательство воспроизводимости эксперимента.

# .github/workflows/security.yml — сбор артефактов для Главы 3
name: sca-scan
on: [push, pull_request]
jobs:
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Формирование SBOM
        run: syft dir:. -o cyclonedx-json > sbom.json
      - name: Поиск уязвимостей в зависимостях
        run: grype sbom:sbom.json -o sarif > report.sarif
      - uses: actions/upload-artifact@v4
        with:
          name: security-artifacts
          path: |
            sbom.json
            report.sarif

Схема процесса, которую стоит вынести на слайд защиты:

Исследователь → Отчёт → Триаж (SLA 72 ч) → Воспроизведение → Оценка CVSS
      ↓                                                              ↓
  Мотивированный отказ ←── Дубликат/информационный ──→ Исправление → Проверка → Бюллетень
                                                                          ↓
                                                        Метрики: MTTD, MTTR, доля принятых

Глава 3. Оценка эффективности: цифры вместо обещаний

Определите базовую линию: зафиксируйте метрики «как есть» на стенде или на исторических данных. Затем прогоните сценарий с вашим решением и сравните. Один прогон — не статистика: минимум 30 отчётов, минимум три повторения, чтобы посчитать разброс. Если используете OpenTelemetry, гистограммы задержек триажа снимаются автоматически — останется только выгрузить квантили.

Для оценки качества результата удобно опереться на ISO/IEC 25010 и расписать три характеристики: functional suitability (решает ли задача приоритизацию корректно), security (защищён ли конвейер от подмены отчётов), reliability (не теряются ли события при отказе узла). Так третья глава перестаёт быть набором скриншотов.

Чему вы научитесь на такой теме

• Проектировать процесс обработки уязвимостей по ISO/IEC 29147 и 30111, а не «по ощущениям».
• Строить архитектурные схемы в C4 и процессные — в BPMN, согласовывая их с ГОСТ 34.601.
• Автоматизировать триаж и приоритизацию отчётов с прозрачной формулой, которую можно защитить.
• Настраивать сбор телеметрии через OpenTelemetry и строить метрики MTTD/MTTR без ручного труда.
• Считать эффективность внедрения и корректно оформлять приложения с конфигурациями и логами.

Источник: «Ваши отчёты летят в корзину». Разгневанный разработчик публично раскритиковал компанию Apple (опубликовано 2026-03-27)