Конспект: как вести этот курс и проводить аттестацию

Зачем модуль

Курс из 16 содержательных модулей и 40 практик легко превратить в демонстрацию инструментов: «вот так запускается Syft, вот так Grype». Тогда слушатель уносит набор команд, но не способность объяснить аудитору, почему релиз можно поставлять. Этот модуль фиксирует методику, которая удерживает фокус на решении, а не на утилите: какие форматы занятий чередовать, как дисциплинировать стенд, какие затруднения предсказуемо возникают и как устроена аттестация, проверяющая навык защиты, а не зубрёжку.

Ключевые идеи

Три формата в каждом занятии. Лекция (10–15 мин) даёт только то, что нельзя получить руками: модель, термины, нормативную рамку. Демо (10–15 мин) — преподаватель показывает один прогон на стенде, проговаривая каждое поле вывода. ПЗ (40–60 мин) — слушатели повторяют на своих данных и упираются в реальный дефект. Перекос в лекцию убивает курс: SCA усваивается на findings, а не на слайдах.

Стенд — это правило, а не апелляция к удаче. Базу ставим один раз в П01 и больше к настройке не возвращаемся. Самая частая аудиторная авария — недоступность внешних реестров и образов. Поэтому заранее проговариваем offline-режим и ограничения прокси (П18, offline-архитектура из М12) и держим локальное зеркало образов.

Карта предсказуемых затруднений. Они одни и те же из потока в поток, и их лучше встречать заранее: - «для C/C++ нет менеджера пакетов» — слушатель ждёт lock-файл; объясняем идентичность из сборки (build evidence в М09) и слепую зону статической линковки (П23); - путают PURL и CPE — первый адресует пакет, второй нужен для сопоставления с CVE (П24, П25); - путают VDR и VEX — один документ говорит «что нашли», другой «применимо ли» (П09); - считают БДУ ФСТЭК и CVE одним списком (П10); - винят инструмент там, где дефектна поставка: пустой findings из-за отсутствия PURL — это дефект данных, а не «сканер плохой».

Как выглядит на практике

Дидактический приём демо — разбирать вывод по полям, а не «общим взглядом». На примере фрагмента CycloneDX:

{
  "components": [
    {
      "type": "library",
      "name": "zlib",
      "version": "1.2.11",
      "purl": "pkg:generic/zlib@1.2.11",
      "licenses": [{ "license": { "id": "Zlib" } }]
    }
  ]
}

Здесь преподаватель спрашивает аудиторию: достаточно ли purl: pkg:generic/... для поиска CVE? (Нет — для NVD нужен CPE.) Есть ли evidence происхождения версии? (Нет.) Так одно поле превращается в три минуты содержательного разбора.

Приём «дефект как материал» Не прячьте сломанные данные. Заранее подложите слушателям SBOM без PURL и форк с собственными патчами: затруднение, найденное руками, запоминается лучше любого слайда.

Слепые зоны самой методики

• Перекос времени в лекцию — главный риск; держите долю ПЗ не ниже половины занятия.
• «Зелёный отчёт» как иллюзия успеха: пустой список CVE чаще означает нераспознанные координаты, а не безопасность.
• Аттестация «на пересказ»: вопрос «что такое SBOM» проверяет память, а не навык; спрашивайте «какой gate включите и кто владелец решения».
• Расхождение оценок экспертов без калибровки рубрики — двое могут поставить за один проект 70 и 90.

Связь с нормативкой

Требования к компетентности персонала и доказательности процесса опираются на ГОСТ Р 56939-2024 (РБПО) и ISO/IEC 27034. Итоговый проект требует матрицы соответствия — образец в Матрица соответствия требованиям.

Что уносим в работу

1. Каждое занятие строим как лекция → демо → ПЗ, отдавая не менее половины времени практике.
2. Стенд и offline-режим проверяем до занятия по П01.
3. Готовим «сломанные» данные под каждую тему — затруднения вводим намеренно.
4. Финальную отработку строим вокруг П36 и П29.
5. Оцениваем по единой рубрике из Итогового проекта; калибруемся на одном билете до старта.