SBOM и vulnerability triage: почему CVE без контекста шумит

Проблема

Команда получает сотни CVE из контейнеров и зависимостей, но не понимает, какие из них влияют на production-риск.

Разные сканеры могут расходиться из-за источников данных, package naming, backported fixes и особенностей distro. Это нормально, если есть triage-слой.

Решение

Сначала формируется SBOM, затем vulnerability scan, затем нормализация: severity, exploit maturity, internet exposure, runtime usage, compensating controls.

В отчете важно явно разделять: fix now, schedule, monitor, accepted risk, false positive/backport verified.

Что проверить руками

• Сравнить SBOM контейнера и репозитория.
• Пометить runtime dependencies отдельно от dev/test.
• Для каждого high/critical спросить: пакет загружается в runtime или просто лежит в образе?
• Проверить vendor advisory, backport и наличие compensating controls.

Безопасный пример кода

Мини-рейтинг CVE для remediation roadmap. Пример рассчитан на owned/lab-среду и не выполняет вредоносных действий.

def priority(vuln: dict) -> str:
    score = 0
    if vuln.get("severity") in {"Critical", "High"}:
        score += 2
    if vuln.get("internet_exposed"):
        score += 2
    if vuln.get("runtime_reachable"):
        score += 2
    if vuln.get("known_exploited"):
        score += 3
    if vuln.get("fixed_version"):
        score += 1
    if score >= 6:
        return "fix-now"
    if score >= 3:
        return "schedule"
    return "monitor"

print(priority({
    "severity": "High",
    "internet_exposed": True,
    "runtime_reachable": True,
    "known_exploited": False,
    "fixed_version": "2.4.1",
}))

Как это должно попасть в отчёт

• Inventory: image, digest, SBOM format, scanner version.
• Triage: exploitability, exposure, package role, fix availability.
• Retest: новый образ с фиксированным digest и повторный scan без regression.