П06. Grype поверх готового SBOM

Контекст Grype не обязан заново разбирать исходники: он умеет принимать на вход готовый SBOM (sbom:<файл>). Это и есть паттерн SBOM-first — состав фиксируется один раз (в М05), а сканер только сопоставляет координаты компонентов с базой уязвимостей. Так VDR воспроизводим: тот же SBOM + та же база дают тот же результат.

Цель

Получить VDR (список фактов «CVE затрагивает компонент») из заранее сгенерированного CycloneDX-SBOM, не пересканируя файловую систему, и сохранить его в машиночитаемом виде для последующего триажа.

Проверяемый результат: файл vdr.cdx.json в формате CycloneDX, где раздел vulnerabilities[] непустой, а каждая находка связана через affects[].ref с bom-ref компонента из входного SBOM.

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

Вход — SBOM из практики П03. Генерация SBOM через Syft или П05. Trivy как генератор и сканер (файл sbom.cdx.json).

# 1. Зафиксировать версию инструмента и базы (это часть evidence)
grype version
grype db status

# 2. Скан готового SBOM, человекочитаемый вид
grype sbom:./sbom.cdx.json -o table

# 3. Тот же скан в VDR (CycloneDX JSON) — это артефакт для триажа
grype sbom:./sbom.cdx.json -o cyclonedx-json --file vdr.cdx.json

# 4. (опционально) включить gate по severity для CI
grype sbom:./sbom.cdx.json --fail-on high

Где взять базу без интернета grype db status показывает дату и путь к локальной БД. Для offline-стенда базу выкачивают один раз (grype db update) и переносят; переменная GRYPE_DB_AUTO_UPDATE=false отключает попытки автообновления при каждом запуске.

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

Табличный вывод (-o table) выглядит так:

NAME       INSTALLED  FIXED-IN  TYPE  VULNERABILITY        SEVERITY
log4j-core 2.14.1     2.16.0    java  CVE-2021-44228       Critical
semver     7.3.7      7.5.2     npm   CVE-2022-25883       High
lodash     4.17.19    4.17.21   npm   GHSA-35jh-r3h4-6jhm  High

Скелет VDR-фрагмента в vdr.cdx.json:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2022-25883",
      "source": { "name": "github:language:javascript" },
      "ratings": [{ "severity": "high", "method": "CVSSv31", "score": 7.5 }],
      "affects": [{ "ref": "pkg:npm/semver@7.3.7" }]
    }
  ]
}

Ориентир по числу находок: для типового сервиса со 100–300 компонентами Grype выдаёт десятки строк (нередко 50+), большинство — High/Critical по CVSS Base. Это нормально: цель практики — получить факты, а не сразу их закрыть. Пустой vulnerabilities[] при заведомо «грязном» SBOM — сигнал, что что-то пошло не так (см. ниже).

Быстрая проверка артефакта jq '.vulnerabilities | length' vdr.cdx.json — число находок; jq '[.vulnerabilities[].ratings[0].severity] | group_by(.) | map({(.[0]): length})' vdr.cdx.json — распределение по severity.

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

Типичные ошибки - 0 vulnerabilities found на заведомо уязвимом SBOM. Чаще всего у компонентов в SBOM нет качественных PURL/CPE — сопоставлять не с чем. Проверьте вход: jq '.components[] | select(.purl==null) | .name' sbom.cdx.json. Корень — генерация SBOM, а не Grype (см. П04. Генерация SBOM через cdxgen для C C++). - could not determine source / Grype сканирует не то. Забыли префикс sbom:. Без него grype ./sbom.cdx.json воспринимается как путь к каталогу/образу, а не как SBOM. - database is too old или скан падает на обновлении. На offline-стенде не перенесена БД либо включён автоапдейт без сети. Зафиксируйте GRYPE_DB_AUTO_UPDATE=false и проверьте grype db status. - CI всегда «зелёный», хотя находки есть. Не задан --fail-on. Сам по себе скан возвращает 0; gate включается явным порогом severity.

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

Показать преподавателю: 1. вывод grype version и grype db status (версия инструмента и дата базы — это evidence); 2. файл vdr.cdx.json с непустым vulnerabilities[]; 3. число находок и распределение по severity (через jq); 4. одно предложение: какой --fail-on уместен как CI-gate именно для этого проекта и почему.

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

М06. Поиск уязвимостей и управление VDR/VEX · Grype · NIST SP 800-218 SSDF (RV.1 — выявление уязвимостей) · OWASP SCVS · Политика управления уязвимостями компонентов · Требования к CI security gate

Смежные практики: П07. OSV-Scanner и lockfiles · П09. VDR и VEX различие факта и решения · П35. VEX triage