Eine SBOM stoppt das nächste Log4j nicht — das hier schon

Im Dezember 2021 lernte die Branche eine demütigende Lektion. Ein kritischer Remote-Code-Execution-Bug in Log4j — Log4Shell, CVE-2021-44228 — setzte das Internet in Brand. Aber die Schwachstelle selbst war nicht das Schlimmste. Das Schlimmste war die Frage, die niemand beantworten konnte: „Nutzen wir überhaupt log4j, und wo?“

Teams verbrachten Tage damit, Build-Systeme zu durchsuchen, sich durch transitive Abhängigkeiten zu graben und Engineers um 2 Uhr nachts zu wecken, um zu klären, welche Services eine Logging-Bibliothek vier Ebenen tief hereinzogen. Der Fix war ein einzeiliger Versionssprung. Jede Stelle zu finden, die ihn brauchte, dauerte Wochen.

Die Lektion, die alle mitnahmen, war „wir brauchen eine SBOM“. Das ist halb richtig — und die falsche Hälfte gibt Teams still das Gefühl von Sicherheit, während sie es nicht sind.

Eine SBOM ist ein Inventar. Sie zu erzeugen stoppt das nächste Log4Shell so wenig, wie ein Packzettel ein Feuer stoppt. Hier ist, was eine SBOM wirklich ist, warum sie keine Verteidigung ist und welche drei Dinge sie zu einer machen.

Was eine SBOM wirklich ist (und was nicht)

Eine Software Bill of Materials ist eine maschinenlesbare Liste der Komponenten in einer Software: Namen, Versionen, kryptografische Hashes, Lizenzen und wie sie voneinander abhängen. Zwei Formate dominieren — SPDX (Linux Foundation, ISO-standardisiert) und CycloneDX (OWASP). Du erzeugst eine aus einem Build mit einem Tool wie Syft, Trivy oder deinem Paketmanager:

# Eine CycloneDX-SBOM für ein Container-Image erzeugen
syft my-registry/app:1.4.2 -o cyclonedx-json > app-1.4.2.sbom.json

Das war’s. Du hast jetzt eine präzise, versionierte Antwort auf „was steckt in diesem Artefakt“. Sie ist wirklich nützlich — und sie ist wirklich untätig. Die SBOM scannt nicht auf Schwachstellen, blockiert keinen schlechten Build und behebt nichts. Sie ist ein Datensatz, keine Kontrolle.

Das ist die Falle: Teams fügen der CI eine SBOM-Generierung hinzu, sehen die Dateien in einem Bucket anwachsen, haken die Compliance-Box ab und glauben, sie hätten das Supply-Chain-Risiko adressiert. Adressiert haben sie dessen Dokumentation. Das Risiko bleibt unberührt.

Warum die Liste allein dich nicht gerettet hätte

Spiel die Log4Shell-Chronik mit einer SBOM in der Hand durch. Am 8. Dezember 2021 listet deine SBOM log4j-core 2.14.1. Null bekannte Schwachstellen. Dein Scanner ist grün. Alles sieht perfekt aus.

Am 9. Dezember wird CVE-2021-44228 veröffentlicht. Nichts in deiner SBOM hat sich geändert — die Welt hat sich geändert. Genau dieselbe Inventarzeile ist jetzt ein Großbrand. Wenn deine SBOM eine einmal erzeugte statische Datei ist, die im Speicher liegt, sagt sie dir nichts, bis ein Mensch auf die Idee kommt, sie erneut zu prüfen.

Der Wert einer SBOM entsteht nicht beim Erzeugen. Er wird in der Zukunft realisiert, jedes Mal, wenn du sie neu gegen das abgleichst, was die Welt gerade dazugelernt hat. Eine Liste, die du nie wieder ansiehst, ist eine Liste, die dich genau an dem Tag im Stich lässt, an dem du sie brauchst.

Die SBOM ist also notwendig, aber bei Weitem nicht hinreichend. Drei Dinge machen aus dem Aktenschrank-Artefakt etwas, das Log4Shell tatsächlich eingedämmt hätte.

Ding 1: Kontinuierliche Korrelation, kein Einmal-Scan

Eine SBOM listet Komponenten; es braucht einen Schwachstellen-Scanner, um diese Liste gegen Datenbanken bekannter CVEs abzugleichen — NVD, OSV, die GitHub Advisory Database — und dir zu sagen, was betroffen ist. Was die meisten Teams übersehen: Du musst dieselbe SBOM wiederholt über die Zeit scannen, nicht einmal beim Build.

# Eine gespeicherte SBOM gegen die heute bekannten Schwachstellen scannen
grype sbom:./app-1.4.2.sbom.json

# Oder direkt die OSV-Datenbank abfragen
osv-scanner --sbom=app-1.4.2.sbom.json

Lass das in einem nächtlichen Job gegen jede jemals ausgelieferte SBOM laufen, nicht nur gegen die von heute Morgen. Wenn jetzt ein neues CVE landet, feuert der Alarm automatisch gegen jedes betroffene Artefakt — und „wo läuft bei uns log4j?“ wird zu einer Abfrage, die in Minuten mit exakten Versionen und Orten zurückkommt. Das ist genau die Fähigkeit, die sich alle im Dezember 2021 gewünscht hatten. Die SBOM macht sie möglich; der kontinuierliche Scan macht sie real.

Das ist dieselbe Disziplin, die eine echte Cloud-Security-Haltung von einem Dashboard grüner Haken unterscheidet. Wenn du diesen Muskel aufbaust, siehe Baue dein eigenes CSPM auf GCP: Security Command Center vs. Open Source.

Ding 2: Provenance, sonst ist die SBOM nur eine Geschichte

Hier die unbequeme Frage: Wenn ein Angreifer deine Build-Pipeline kompromittiert, was hindert ihn daran, dir eine sauber aussehende SBOM zu unterschieben, die die bösartige Komponente auslässt? Nichts — es sei denn, die SBOM ist signiert und trägt Build-Provenance.

Hier kommen Sigstore (über cosign) und SLSA (Supply-chain Levels for Software Artifacts) ins Spiel. Du signierst die SBOM und hängst sie als verifizierbare Attestation an das Artefakt, mit schlüssellosem Signieren, das an die Identität deiner CI gebunden ist:

# Die SBOM als signierte, verifizierbare Attestation an das Image hängen
cosign attest --predicate app-1.4.2.sbom.json \
  --type cyclonedx my-registry/app:1.4.2

# Beim Deploy verifizieren, dass sie wirklich aus deiner Pipeline kam
cosign verify-attestation --type cyclonedx \
  --certificate-identity-regexp '.*@your-org\.com' \
  my-registry/app:1.4.2

Jetzt ist das Inventar vertrauenswürdig: Es stammt beweisbar aus deinem Build-System und wurde nicht verändert. Erzwinge es an der Tür mit einer Admission-Policy, die jedes Image ohne gültige, signierte SBOM-Attestation ablehnt. Eine SBOM, die du nicht verifizieren kannst, ist Inventar-Theater — es fühlt sich wie Kontrolle an und ist keine.

Ding 3: VEX, sonst ertrinkt dein Team in False Positives

Richte einen Scanner auf eine echte SBOM und du bekommst Hunderte „verwundbare“ Funde. Die überwältigende Mehrheit ist in deinem Kontext nicht ausnutzbar: Die verwundbare Funktion wird nie aufgerufen, die Komponente wird zur Laufzeit nicht geladen, oder eine Gegenmaßnahme neutralisiert sie bereits. Gib diese Rohliste einem Security-Team, und es tut, was jeder Mensch mit einem Feuerwehrschlauch voller Rauschen tut — es fängt an, sie zu ignorieren. Genau dann rutscht der eine Fund durch, der zählt.

VEX (Vulnerability Exploitability eXchange) ist die Lösung. Es ist ein Begleitdokument, das pro CVE angibt, ob du tatsächlich betroffen bist — not_affected, affected, fixed, under_investigation — mit einer Begründung:

{
  "vulnerability": { "name": "CVE-2021-44228" },
  "products": ["pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"],
  "status": "affected",
  "action_statement": "Upgrade auf 2.17.1; JNDI-Lookup als Übergangsmaßnahme deaktiviert."
}

VEX verwandelt eine Wand aus Rot in eine kurze, ehrliche Liste dessen, was echt ist. Es ist der Unterschied zwischen einer Security-Queue, auf die Menschen reagieren, und einer, die sie gelernt haben wegzuwischen.

Was Log4Shell tatsächlich eingedämmt hätte

Setz die Teile zusammen, und das Bild ist klar. Es war nie die SBOM. Es war das System darum herum:

1. Jedes ausgelieferte Artefakt bringt eine signierte SBOM mit Build-Provenance mit, zentral gespeichert und abfragbar.
2. Diese SBOMs werden fortlaufend neu gescannt gegen neue CVEs, sodass Log4Shell in der Stunde seiner Veröffentlichung einen Alarm auslöst — über jeden betroffenen Service auf einmal.
3. Provenance bedeutet, du vertraust dem Inventar, statt zu hoffen, dass es ehrlich ist.
4. VEX filtert die Ergebnisse auf das wirklich Ausnutzbare, sodass die Verantwortlichen auf das echte Feuer reagieren, statt Rauschen zu triagieren.

Damit ist „wo läuft bei uns log4j?“ in Minuten beantwortet, die Reaktion ist präzise zugeschnitten, und der Fix ist ausgeliefert, bevor Angreifer mit dem Scannen fertig sind. Die SBOM ist das Fundament — aber das Fundament ist nicht das Haus.

Kontinuierliches Scannen und signierte Provenance gehören in die Pipeline selbst, nicht nachträglich angeschraubt. Zum Härten der Pipeline, die all das erzeugt, siehe Sichere GitLab-CI/CD-Pipelines 2026: Ein praktisches Hardening-Playbook.

Das wird bald Gesetz, kein Nice-to-have

Falls ROI nicht genug war, schließt die Regulierung die Lücke. Die US-Executive-Order 14028 verlangt bereits SBOMs für Software, die an die Bundesregierung verkauft wird. Der EU Cyber Resilience Act geht weiter: Ab 2027 schreibt er SBOMs und Schwachstellen-Handling für praktisch alle Produkte mit digitalen Elementen vor, die in der EU verkauft werden. Die Teams, die SBOM heute als Häkchen behandeln, sind jene, die zu spät merken, dass das Häkchen ein funktionierendes System sein sollte.

Die Regel fürs Feld

Eine SBOM ist ein Inventar, keine Verteidigung — eine zu erzeugen und wegzulegen ist Sicherheitstheater, das Log4Shell nicht gestoppt hätte. Was das nächste stoppt, ist das System um die Liste herum: jede SBOM fortlaufend gegen neue CVEs neu scannen, damit eine frische Schwachstelle in der Stunde ihres Erscheinens einen Alarm auslöst; die SBOM signieren und Build-Provenance anhängen, damit das Inventar vertrauenswürdig statt fälschbar ist; und VEX obendrauf legen, damit der eine echte Fund nicht unter Hunderten nicht erreichbaren begraben wird. Bau das, und das nächste Log4Shell ist eine Abfrage und ein zugeschnittenes Rollout — keine Woche aus Durchsuchen und Beten.