Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
План занятия (90 минут)
Цели
К концу занятия слушатель умеет:
- получить VDR из готового SBOM тремя инструментами (Grype, OSV-Scanner, Dependency-Track) и объяснить, какой из них для какого входа;
- словами и в JSON различить VDR (факт) и VEX (решение);
- расставить четыре состояния VEX (not_affected, affected, fixed, under_investigation) с обязательным justification;
- назвать источники (NVD/OSV/GHSA/БДУ ФСТЭК) и сказать, чем они отличаются;
- привязать к каждой находке владельца, SLA и условие ретеста.
Материалы
- Стенд из П01. Стенд WSL2 Docker и базовая гигиена (Grype, OSV-Scanner, Dependency-Track в Docker).
- Заранее подготовленный
sbom.cdx.jsonуязвимого сервиса (вход из М05). - Конспект М06, шаблон Политика управления уязвимостями компонентов.
- VEX в процессе РБПО — раздать до занятия как обязательное чтение: откуда берется VEX, кто его выпускает, чем
not_affectedдоказывается.
Ход занятия
| Мин | Блок | Что происходит |
|---|---|---|
| 0–10 | Вводный кейс | Показываю один SBOM, прогоняю Grype: 187 находок, 40 Critical. Вопрос аудитории: «что патчим первым?» — фиксируем растерянность как проблему модуля. |
| 10–30 | Лекция: VDR vs VEX | Факт против решения. Четыре состояния VEX и список justification. Источники NVD/OSV/GHSA/БДУ и почему один источник недостаточен. Отдельно: VEX выпускает производитель/ответственный за продукт, а не база уязвимостей. Владелец/SLA/ретест. |
| 30–50 | Демо: три сканера | grype sbom:./sbom.cdx.json -o cyclonedx-json; затем osv-scanner --lockfile=... на том же проекте — сравниваем расхождение в находках. Загрузка SBOM в Dependency-Track, показ портфеля и API VEX. |
| 50–75 | ПЗ в парах | Каждая пара берёт 5 находок из VDR, оформляет VEX-записи: состояние + justification + владелец + SLA. Одна находка должна попасть в under_investigation, одна — сверена с БДУ ФСТЭК. |
| 75–85 | Разбор | Пары показывают самый спорный not_affected. Проверяем: обоснование из разрешённого списка? есть ли срок жизни решения? |
| 85–90 | Рефлексия | Что из этого фиксируем в регламенте Организации: пороги SLA, список justification, периодичность ретеста. Выдача ПР. |
Типичная ошибка на демо Студенты ждут, что Grype и OSV-Scanner дадут одинаковый список. Покажите расхождение явно: OSV точнее по диапазонам версий в lockfile, Grype шире покрывает контейнерные и системные пакеты. Это не баг, а повод сверять источники.
Контрольная точка
Слушатель на одной находке проходит цепочку: факт из VDR → выбор состояния VEX → обоснование → владелец → SLA → когда пересмотреть. Если на любом шаге «не знаю» — материал не усвоен.
Дополнительный контроль: слушатель должен назвать, кто имеет право выпустить VEX для собственного продукта Организации и почему upstream advisory является evidence, но не заменяет VEX Организации.