Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

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

П05. Trivy как генератор и сканер

Цель

Показать на одном инструменте два разных режима работы и их разделение: сначала Trivy генерирует CycloneDX SBOM (артефакт фактов о составе), затем тем же Trivy сканирует этот SBOM на уязвимости (артефакт решения о рисках). Проверяемый результат — файл trivy-bom.json без уязвимостей внутри и отдельная таблица findings, полученная из него командой trivy sbom.

Команда или действие

Берём контейнерный образ (учебный или базовый, например python:3.11-slim). Шаг 1 — генерация SBOM, шаг 2 — сканирование готового SBOM. Разделение шагов наглядно показывает, что генерация и поиск уязвимостей — две разные операции.

trivy --version

# шаг 1 — ГЕНЕРАТОР: образ → CycloneDX SBOM (только состав, без CVE)
trivy image --format cyclonedx --output trivy-bom.json python:3.11-slim

# шаг 2 — СКАНЕР: тот же Trivy матчит готовый SBOM на уязвимости
trivy sbom trivy-bom.json

trivy sbom <файл> сам определяет формат как cyclonedx-json и по умолчанию включает сканирование уязвимостей — отдельный флаг не нужен. Для воспроизводимости в оффлайн-контуре БД уязвимостей загружают заранее (trivy image --download-db-only), иначе Trivy попытается обновить её из сети.

Что вы должны увидеть

Шаг 1 пишет на диск trivy-bom.json — чистый CycloneDX без блока уязвимостей. Скелет:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "metadata": {
    "tools": { "components": [ { "name": "trivy", "version": "0.x.x" } ] }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.11-1~deb12u2",
      "purl": "pkg:deb/debian/openssl@3.0.11-1~deb12u2"
    }
  ]
}

Шаг 2 печатает в терминал сводку и таблицу findings — это и есть «слой решения», которого в самом SBOM нет:

trivy-bom.json (debian 12.x)

Total: 37 (UNKNOWN: 0, LOW: 12, MEDIUM: 18, HIGH: 6, CRITICAL: 1)

┌───────────────┬────────────────┬──────────┬───────────────────┬───────────────┐
│    Library    │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │
├───────────────┼────────────────┼──────────┼───────────────────┼───────────────┤
│ openssl       │ CVE-2023-xxxxx │ HIGH     │ 3.0.11-1~deb12u2  │ 3.0.11-1~..u3 │
└───────────────┴────────────────┴──────────┴───────────────────┴───────────────┘

Точное число findings зависит от образа и даты БД — важен не модуль числа, а то, что таблица непустая и severity-разбивка присутствует.

Один инструмент — два слоя SBOM — это факт («в образе есть openssl@3.0.11»), а findings — производное решение («у этой версии есть CVE-2023-xxxxx»). Trivy умеет и то, и другое, но в trivy-bom.json уязвимостей нет: они появляются только на шаге trivy sbom. Это правильное разделение — SBOM долговечен, а вердикты по нему пересчитываются при каждом обновлении БД.

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

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

Показать преподавателю: файл trivy-bom.json (открыть и убедиться, что блока vulnerabilities в нём нет), вывод trivy sbom trivy-bom.json со строкой Total: и severity-разбивкой, строку trivy --version. Объяснить одним предложением, почему уязвимости не записаны в SBOM, а считаются отдельно.

Нормативная связка