Практическая работа: от SBOM к VEX-триажу

Цель

Из готового SBOM получить VDR двумя инструментами, сверить находки с национальным источником и оформить полноценный VEX-триаж: каждая обработанная находка получает состояние, обоснование, владельца, SLA и условие ретеста.

Вход

• sbom.cdx.json уязвимого сервиса (берётся из практики генерации SBOM, М05) либо package-lock.json проекта.
• Развёрнутый стенд по П01. Стенд WSL2 Docker и базовая гигиена.
• Обязательное чтение перед шагом 6: VEX в процессе РБПО.

Шаги

1. Зафиксировать контекст анализа

Запишите: репозиторий, commit/tag, имя и версию SBOM-генератора, дату, дату последнего обновления баз сканера. Без этого VDR неповторяем.

2. Получить VDR через Grype поверх SBOM

grype sbom:./sbom.cdx.json -o cyclonedx-json > vdr.cdx.json
grype sbom:./sbom.cdx.json -o table   # для глаз

Детали — П06. Grype поверх готового SBOM.

3. Получить второй VDR через OSV-Scanner

osv-scanner --lockfile=package-lock.json --format=json > osv.json

Сравните списки. Найдите минимум одну находку, которая есть в одном инструменте и отсутствует в другом, и объясните почему. Детали — П07. OSV-Scanner и lockfiles.

4. Загрузить SBOM в Dependency-Track

Через UI или API загрузите sbom.cdx.json как проект, получите портфельный список уязвимостей. Это рабочее место для непрерывного триажа — П08. Dependency-Track как портфель SBOM.

5. Сверить с БДУ ФСТЭК

Возьмите 3 наиболее серьёзные CVE и проверьте их наличие в БДУ ФСТЭК. Отметьте расхождения с NVD/OSV — П10. БДУ ФСТЭК как национальный источник.

6. Оформить VEX по 5 находкам

Для пяти находок составьте VEX-записи. В каждой записи укажите, кто в вашей организации является issuer решения для этой версии продукта: Product Security / PSIRT / AppSec / РБПО совместно с владельцем продукта и разработчиком. Обязательно: одна not_affected с корректным justification, одна affected с response, одна under_investigation. Подход — VEX в процессе РБПО, П09. VDR и VEX различие факта и решения, П35. VEX triage.

{
  "vulnerability": { "id": "CVE-2022-25883" },
  "affects": [{ "ref": "pkg:npm/semver@7.3.7" }],
  "analysis": {
    "state": "not_affected",
    "justification": "code_not_reachable",
    "detail": "semver используется только build-time на доверенном вводе",
    "response": ["will_not_fix"]
  }
}

7. Дополнить триаж управленческими полями

К каждой VEX-записи добавьте таблицей: issuer / владелец решения (роль), SLA (срок по severity), дата ретеста / триггер пересмотра. Сканер, NVD, БДУ или upstream advisory не являются issuer вашего VEX; они дают evidence для решения.

Ожидаемый результат

• два VDR-файла (Grype, OSV-Scanner) и проект в Dependency-Track;
• объяснённое расхождение между сканерами (минимум 1 находка);
• отметка о сверке 3 CVE с БДУ ФСТЭК;
• 5 VEX-записей в JSON с обязательным justification для not_affected;
• таблица с issuer/владельцем/SLA/ретестом по каждой записи.

Если не получилось

Частые сбои - Grype нашёл 0 находок — почти всегда SBOM беден на PURL/CPE (проблема входа из М04/М05), а не «всё чисто». - OSV-Scanner ругается на lockfile — указали не тот файл; нужен именно lock (package-lock.json, go.sum, poetry.lock), а не манифест. - not_affected без justification — Dependency-Track/CycloneDX не примет такой VEX как валидный триаж; выберите значение из списка. - VEX от имени базы уязвимостей — так нельзя. NVD, БДУ, OSV и GHSA подтверждают внешний факт, но VEX для продукта выпускает владелец продукта / Product Security / PSIRT. - Базы устарели — Grype/OSV без свежей БД дают неполный VDR; обновите перед прогоном.

Критерий зачёта

Показать преподавателю: (1) два VDR с объяснённым расхождением, (2) пять корректных VEX-записей с обязательными justification, (3) заполненную таблицу issuer/владелец/SLA/ретест, (4) отметку о сверке с БДУ. Опора на регламент — VEX в процессе РБПО, Политика управления уязвимостями компонентов, Порядок загрузки VDR из Dependency-Track.