Опубликовано: 24.09.2026 | Источник: CNews (новости)

Secure by Design в дипломе: конструктивная безопасность как тема ВКР с измеримым результатом

25 марта 2026 года «Лаборатория Касперского» расширила бесплатный курс «Введение в кибербезопасность» модулем «Конструктивная безопасность». Это не просто новость для ленты — это сигнал рынку. Компании устали латать дыры после инцидентов и требуют специалистов, которые умеют закладывать защиту в архитектуру с первого спринта, а не после первого взлома. Для выпускника такой сдвиг открывает окно возможностей: тема на стыке проектирования, разработки и ИБ одновременно современна, проверяема и хорошо ложится на стандарты. Ниже — как превратить эту новость в защищаемую ВКР, а не в реферат. Покажу структуру, метрики, диаграммы и подводные камни, о которые спотыкаются почти все.

Вопросы, которые задают на консультации по ИБ-дипломам

Нужно ли писать реальные эксплойты, чтобы работа считалась технической?

Нет. Для ВКР по конструктивной безопасности важнее доказать, что угрозы описаны формально, а контрмеры — проверяемы. Пентест может быть одной из задач, но не основой. Разбор STRIDE или OWASP ASVS-матрицы даёт больше научного веса, чем найденная XSS на учебном стенде.

Где брать данные, если нет реального заказчика?

Три источника: 1) открытые датасеты уязвимостей (NVD, GitHub Advisory), 2) собственный стенд на Docker, 3) внутренние отчёты стажировки, обезличенные под NDA. Третье — самое ценное, но о безопасности стенда нужно договориться письменно.

Как считать эффективность, если «безопасность» кажется неизмеримой?

Метрики есть, и они не про «стало лучше». Считайте плотность дефектов безопасности на 1 KLOC, время реакции на критичный дефект (MTTR), долю требований безопасности, закрытых автотестами, и покрытие кода SAST-проверками. Всё это числа, их легко защитить на слайде.

Обязательно ли оформлять по ГОСТ 34 или можно по 19?

Зависит от того, что вы проектируете. ГОСТ 34 — для системных решений (АС в целом, ТЗ, техпроект). ГОСТ 19 — для программных документов (описание программы, руководство оператора). На кафедре часто путают, поэтому уточните у научного руководителя до того, как напишете 20 страниц не в том формате.

Три темы ВКР, готовые к защите

Тема 1. Модель угроз по STRIDE для веб-приложения и её интеграция в CI/CD.
Актуальность: прямо связана с модулем курса «Лаборатории Касперского» — конструктивная безопасность начинается с модели угроз.

Цель: снизить число дефектов безопасности, попадающих в релиз, за счёт shift-left подхода.

Задачи: 1) построить DFD-модель приложения; 2) составить матрицу «угроза — контрмера — тест»; 3) встроить SAST и проверку зависимостей в пайплайн; 4) сравнить метрики до/после.

Структура: Гл.1 — Secure by Design, ISO/IEC 25010 (аспект Security), ГОСТ 34; Гл.2 — архитектура, DFD, STRIDE, пайплайн; Гл.3 — замер метрик и A/B стабильности сборки.
Тема 2. Оценка зрелости процессов безопасной разработки по OWASP SAMM.
Актуальность: заказчики всё чаще просят не «отчёт пентеста», а управляемый процесс. SAMM даёт шкалу от 0 до 3 и объективную почву для выводов.

Цель: сформировать дорожную карту повышения зрелости для выбранной организации или учебного проекта.

Задачи: интервью и сбор артефактов, оценка 15 практик SAMM, приоритизация по рискам, план внедрения на два квартала.

Структура: Гл.1 — обзор моделей зрелости (SAMM, BSIMM, ISO 27001); Гл.2 — методика оценки; Гл.3 — результаты и рекомендации.
Тема 3. Автоматизированное формирование SBOM и контроль цепочки поставок.
Актуальность: атаки на зависимости (XZ, event-stream) превратили SBOM из моды в требование. Тема редкая — конкуренции на защите почти нет.

Цель: обеспечить прослеживаемость компонентов и автоматическое определение уязвимых версий.

Задачи: генерация SBOM (CycloneDX/SPDX), сопоставление с NVD, интеграция в пайплайн, dashbord с CVSS-скором.

Структура: Гл.1 — supply chain risks, ГОСТ Р 5ххх/ISO; Гл.2 — архитектура решения; Гл.3 — метрики обнаружения и время реакции.

Как уложить конструктивную безопасность в главы ВКР

Глава 1: теория, которая не превращается в пересказ Википедии

Возьмите три опоры: принципы Secure by Design (Касем и коллеги, 2020), модель качества ISO/IEC 25010 в части Security и требования ГОСТ 34 к проектированию АС. Дальше — сравнение подходов: реактивный (пентест после релиза) против проактивного (threat modeling). Таблица «подход — стоимость исправления — время до релиза» отлично смотрится на защите: она показывает, что вы понимаете экономику безопасности, а не только софт.

Глава 2: проектирование и DFD-модель

Стройте диаграмму потоков данных (DFD) по уровням: контекст (Level 0), декомпозиция процессов (Level 1), границы доверия (trust boundaries). По каждой границе — таблица STRIDE. Именно здесь ваш материал из курса пригодится на 100%. Ниже — заготовка модели угроз в формате YAML, которую можно вставить в приложение к диплому как машиночитаемое описание:

threat_model:
  system: "student-portal"
  methodology: STRIDE
  boundaries:
    - id: B1
      from: "internet"
      to: "api-gateway"
      threats:
        - type: Spoofing
          scenario: "Подбор JWT-секрета"
          control: "ротация ключа раз в 24ч, alg=RS256"
          test: "jwt_tool brute-force in CI"
        - type: DoS
          scenario: "Флуд логина"
          control: "rate-limit 10 req/min per IP"
          test: "k6 сценарий"
    - id: B2
      from: "api-gateway"
      to: "auth-service"
      threats:
        - type: Tampering
          scenario: "Изменение роли в теле запроса"
          control: "server-side re-check roles, mTLS"
          test: "pytest + mTLS cert mismatch"

Глава 3: тестирование и метрики, которые считаются честно

Не смешивайте метрики производительности и безопасности. Заведите два среза: до внедрения практик и после. Минимальный набор — MTTR по критичным дефектам, плотность дефектов безопасности на 1 KLOC, покрытие требований безопасности автотестами (в процентах), время сканирования SAST в пайплайне. Ниже — фрагмент пайплайна, который можно описать в тексте и приложить как листинг.

stages: [build, sast, sca, test, report]
semgrep_scan:
  stage: sast
  rules: p/owasp-top-ten, p/cwe-top-25
  allow_failure: false
  artifacts: reports/semgrep.sarif
sca_scan:
  stage: sca
  script:
    - syft . -o cyclonedx-json > sbom.json
    - grype sbom.json --fail-on high
metrics:
  - name: security_defect_density
    expr: defects_security / (loc / 1000)
  - name: mttr_critical
    expr: avg(close_time - open_time) WHERE sev = "critical"

Метрика	Формула	Целевое значение	Источник данных
Плотность дефектов ИБ	defects / (KLOC)	≤ 1.5 на 1 KLOC	Jira + SonarQube
MTTR критичных	Σ(t_close − t_open) / N	≤ 72 ч	Трекер, дежурный лог
Покрытие требований тестами	tests_ok / tests_total	≥ 80 %	Allure / CI
Доля релизов с блокировкой SCA	blocked / total	снижение ≤ 5 %	Пайплайн-логи

Оформление: где ГОСТ ломает хорошие работы

Схемы делайте в одном нотации-стиле: C4 для контейнеров, DFD для потоков данных, UML — только там, где он реально нужен (диаграмма классов сервиса). Подписи — по ГОСТ 2.316, ссылки на рисунки в тексте обязательны. Если пишете ТЗ — по ГОСТ 34.602, если руководство оператора — ГОСТ 19.505. Мелочь, но именно из-за неё защита может превратиться в молчание на замечаниях нормоконтроллера.

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

Строить модель угроз и защищать её перед комиссией через конкретные сценарии, а не «список из интернета».
Настраивать SAST/SCA в CI и объяснять, почему сборка падает — тоже результат.
Считать метрики ИБ и выдерживать один и тот же способ измерения в Главе 3 и в приложениях.
Оформлять проектную и программную документацию по ГОСТ без переделок за ночь до сдачи.
Аргументировать выбор OWASP ASVS вместо «мы просто включили все проверки».

Чек-лист перед сдачей ИБ-диплома

Задачи из введения буквально совпадают с выводами по главам.
Каждая угроза имеет минимум одну контрмеру и один проверяющий тест.
Все схемы пронумерованы, подписаны и упомянуты в тексте.
Метрики посчитаны на одной выборке до и после, без «подгонки».
Ссылки на OWASP, ISO/IEC 25010 и ГОСТ оформлены единообразно.
Приложения с кодом и SBOM лежат в артефактах, а не только в тексте.
Проверка на заимствования пройдена, листинги — с указанием источника, если заимствованы.

Три ошибки, которые я вижу у 8 из 10 студентов

Модель угроз ради модели. Огромная таблица STRIDE, никак не связанная с кодом и тестами. Комиссия спросит: «Где это в реализации?» — и защита посыпется. Решение: на каждую угрозу ссылайтесь на номер задачи в трекере и на автотест.
Метрики без базовой линии. «Мы внедрили SAST, стало безопаснее» — не аргумент. Снимите показатели до внедрения хотя бы на одном спринте, иначе выводы недоказуемы.
Игнорирование цепочки поставок. Модуль «Конструктивной безопасности» из курса «Лаборатории Касперского» подчёркивает: уязвимость может прийти через библиотеку. Если в дипломе нет SCA и SBOM — тема выглядит вчерашней.

Нужна рука помощи? У нас есть 120 часов свободных слотов в этом месяце на консультации по ИБ-темам: разберём модель угроз, поможем выстроить пайплайн и привести главы в соответствие с ГОСТ. Первая встреча — бесплатная, без обязательств. Если решите заказать диплом целиком или частично — обсудим объём на созвоне.

Материал подготовлен экспертами компании [Название сайта]. Мы помогаем студентам с 2010 года. Если вам нужна помощь в разработке темы или оформлении работы, наши специалисты готовы подсказать.

Последнее обновление: 2026-09-24

Источник: В бесплатном онлайн-курсе «Лаборатории Касперского» для студентов появился модуль по конструктивной безопасности (опубликовано 2026-03-25)