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

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

OWASP Dependency-Track

Для чего

Dependency-Track — серверная платформа, которая принимает SBOM (CycloneDX) по проектам и держит их непрерывно сопоставленными с источниками уязвимостей. В отличие от разовых CLI-сканеров, это «портфель»: загруженный однажды SBOM продолжает переоцениваться при появлении новых advisories, а дашборд показывает риск по всем проектам сразу. Дополнительно ведёт учёт лицензий и применяет политики на уровне организации.

Как применяют

SBOM генерируется в CI отдельным инструментом (Syft/cdxgen/Trivy) и публикуется в Dependency-Track через REST API; платформа сама запускает анализ:

Публикация SBOM в CI

curl -X POST "https://dtrack.local/api/v1/bom" \
  -H "X-Api-Key: $DT_API_KEY" \
  -F "project=$PROJECT_UUID" \
  -F "bom=@sbom.cdx.json"

Гейт строят не на самом факте уязвимости, а на нарушении политики: в Policy задаются условия по severity/лицензии/возрасту компонента, а CI опрашивает endpoint вердиктов:

Проверка нарушений политики

curl -s "https://dtrack.local/api/v1/violation/project/$PROJECT_UUID" \
  -H "X-Api-Key: $DT_API_KEY"

Источники подключаются модулями (NVD mirror, OSS Index, GitHub Advisories, OSV, при необходимости — внутренние фиды). Поддерживается приём VEX (CycloneDX VEX) для подавления неэксплуатируемых находок без удаления факта. Принимать VEX в портфель можно только как утверждение ответственного issuer с status, justification и evidence; порядок — VEX в процессе РБПО.

Сильные стороны

Непрерывная переоценка: новый CVE автоматически «подсвечивает» все ранее загруженные SBOM, где есть уязвимый компонент, — не нужен повторный прогон CI.
Портфельный взгляд: единый дашборд риска, метрики, тренды и сравнение проектов — то, чего не даёт ни один CLI-сканер.
Политики и приём VEX/VDR: гейт строится на бизнес-правилах и решениях о неэксплуатируемости, а не на сыром списке CVE.
Разделяет роли: генерация SBOM (CI) и хранение/анализ/политики (платформа) — масштабируется на много команд и исполнителей.

Ограничения

Сам SBOM не генерирует — нужен внешний инструмент; качество анализа полностью наследует качество входного SBOM.
Это сервис: требует развёртывания, СУБД, обслуживания, бэкапов и контроля доступа — операционная нагрузка выше, чем у CLI.
Каждый встроенный источник нужно отдельно настроить и зеркалировать; интеграция БДУ ФСТЭК «из коробки» отсутствует и требует кастомного фида.
Для нативного C/C++ остаётся та же проблема координат: если PURL/CPE в SBOM пусты, анализатор не находит уязвимости.
Подавление finding в UI без оформленного VEX и evidence не является управлением уязвимостью; это аудиторский стоп-сигнал.

Offline / on-premise

Да, это профильный сценарий. Платформа разворачивается on-premise (контейнеры API-server и frontend + СУБД PostgreSQL), внешние источники работают через зеркала: NVD mirror, локальная база OSS Index/OSV. После настройки зеркал и отключения внешних вызовов система функционирует в закрытом контуре. Подходит как «сервис аудита/вердиктов» уровня организации.

Связанные темы

М06 Поиск уязвимостей и VDR/VEX · М10 Много исполнителей и корпоративная модель продукта · М11 Генератор фактов и сервис вердиктов Справка: VEX в процессе РБПО Практика: П08. Dependency-Track как портфель SBOM · П35. VEX triage · П28. Поставка от нескольких исполнителей Смежные карточки: CycloneDX · OpenVEX · OSS Index · Syft · cdxgen · OWASP Dependency-Check