SBOM, Trivy und Admission

SBOM — Software Bill of Materials — ist ein Inventar der Softwarekomponenten in einem Container-Image. Alle genutzten Libraries, Frameworks, Systempakete, mit Versionsinformation. Klingt nach Compliance-Bürokratie. Wird aber zunehmend gesetzlich gefordert — in den USA durch Executive Order 14028, in der EU durch den Cyber Resilience Act, der SBOM-Pflichten für Produkte mit digitalen Elementen mitbringt.

Der eigentliche Wert zeigt sich aber nicht im Audit, sondern im Ernstfall. Als Log4Shell im Dezember 2021 bekannt wurde, lautete die erste Frage in jedem Unternehmen: „Wo läuft bei uns überall Log4j?” Teams mit SBOMs hatten die Antwort in Minuten — eine Abfrage über das SBOM-Archiv. Teams ohne haben Tage damit verbracht, Images zu entpacken und JAR-Dateien zu durchsuchen.

SBOM generieren: das einfache Drittel

Trivy ist der praktischste Einstieg:

trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/checkout:1.4.2

CycloneDX und SPDX sind die beiden verbreiteten Formate; beide werden von gängigen Analyse-Tools verstanden. Inhaltlich erfasst Trivy OS-Pakete (apt, apk, rpm) und Sprachabhängigkeiten aus Lockfiles und Paket-Metadaten — bei statisch kompilierten Binaries ohne eingebettete Metadaten kann das Inventar dagegen lückenhaft sein. Das ist eine ehrliche Grenze des Ansatzes: ein SBOM ist so gut wie das, was die Tools aus dem Image herauslesen können.

Trivy kann ein vorhandenes SBOM auch direkt als Scan-Input verwenden (trivy sbom sbom.cdx.json) — der CVE-Abgleich läuft dann gegen das Inventar statt gegen das Image. Das ist deutlich schneller und genau der Mechanismus, der das Archiv-Szenario von oben möglich macht: neue CVE erscheint, alle archivierten SBOMs durchscannen, betroffene Images identifizieren, ohne ein einziges Image anzufassen.

Vom Scan zur Durchsetzung

Ein Workflow, der in Produktion funktioniert, hat drei Stationen:

In der CI-Pipeline generiert Trivy das SBOM und scannt auf CVEs. Mit --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed schlägt der Build nur fehl, wenn Critical- oder High-CVEs mit verfügbarem Fix gefunden werden. Das SBOM wird anschließend mit Cosign als Attestation an das Image gehängt — kryptografisch an den Image-Digest gebunden, abgelegt in der Registry neben dem Image:

cosign attest --predicate sbom.cdx.json --type cyclonedx registry.example.com/checkout:1.4.2

Im Cluster prüft eine Admission-Policy (Kyverno hat dafür verifyImages, bei OPA Gatekeeper läuft es über externe Daten-Provider), ob eine signierte SBOM-Attestation vom erwarteten CI-System vorliegt. Damit erzwingst du nicht „das Image ist CVE-frei” — das wäre unhaltbar — sondern „das Image ist durch unsere Pipeline gelaufen und dokumentiert”. Das ist die durchsetzbare Aussage.

Im Archiv landen die SBOMs versioniert nach Image-Digest. Registry mit OCI-Artifact-Support reicht dafür; manche Teams nutzen zusätzlich eine Dependency-Track-Instanz, die SBOMs kontinuierlich gegen neue CVEs abgleicht und alertet.

Was in der Praxis schiefgeht

Der klassische Fehler ist Zero-Tolerance: jede Medium-CVE blockiert den Build. Das klingt sicher, scheitert aber an der Realität — fast jedes nicht-triviale Image hat Medium- und Low-Findings in Basispaketen, oft ohne verfügbaren Fix. Nach zwei Wochen Build-Blockaden gibt es entweder eine wild wuchernde Ignore-Liste oder Teams umgehen den Scan ganz. Pragmatischer: hart blockieren nur bei Critical und High mit Fix, alles andere reporten und in regelmäßigen Reviews abarbeiten. Eine .trivyignore mit begründeten, idealerweise befristeten Ausnahmen gehört ins Repo und in den Review-Prozess, nicht in eine zentrale Datei, die niemand pflegt.

Der zweite Fehler: SBOM einmal generieren und nie wieder anschauen. Ein SBOM veraltet nicht, aber seine Bewertung — das Image von vor drei Monaten war beim Build sauber und hat heute zwei Critical-CVEs. Ohne kontinuierliches Re-Scanning des Bestands (Trivy Operator im Cluster oder Dependency-Track über das Archiv) ist das SBOM nur ein Snapshot, kein Sicherheitsinstrument.

Ein dritter, subtilerer Punkt: nicht jede CVE in einer Komponente ist im konkreten Produkt ausnutzbar — die verwundbare Funktion wird vielleicht nie aufgerufen. Dafür gibt es VEX (Vulnerability Exploitability eXchange): ein maschinenlesbares Dokument, in dem der Hersteller oder das eigene Security-Team erklärt, welche CVEs für ein Produkt relevant sind und welche nicht. Trivy kann VEX-Dokumente beim Scan berücksichtigen und so dokumentierte False Positives unterdrücken — sauberer als eine wachsende Ignore-Liste, weil die Begründung Teil des Formats ist. Für die Praxis heißt das: Findings nicht nur wegfiltern, sondern die Einschätzung festhalten, warum sie nicht relevant sind.

Das Tooling-Ökosystem — Syft, Grype, Trivy, Snyk — konvergiert auf dieselben Formate; welches Tool du nimmst, ist weniger wichtig, als ob du es konsistent und automatisiert einsetzt. Wie SBOM, Signaturen und Provenance zusammen eine belastbare Supply Chain ergeben, zeigt der Artikel zu Cosign und SLSA und vertieft der Lernpfad Supply Chain Security.