🔍 Was beobachte ich?

Zwei Versäumnisse, oft gleichzeitig: Ein SBOM wird einmalig erzeugt – nicht für jeden Build. Welche Komponentenversionen im letzten Release stecken? Unbekannt. Und selbst wo SBOMs existieren, werden sie nicht beobachtet. Ein neuer CVE für eine enthaltene Komponente bleibt unsichtbar – bis jemand zufällig nachschaut.

🎯 Was soll eigentlich erreicht werden?

Zwei Dinge: wissen, was deployed ist – und wissen, ob das noch sicher ist. Der SBOM beantwortet die erste Frage: Er dokumentiert Komponentenversionen eines Builds. Die zweite beantwortet er nur, wenn er kontinuierlich gegen Schwachstellendatenbanken geprüft wird.

⚠️ Warum funktioniert das nicht?

Beide Ebenen können unabhängig voneinander scheitern. Ohne SBOM je Build fehlt das Bild: Welche Version steckt in welchem Release? Transitive Dependencies fehlen häufig, weil viele Tools nur Top-Level-Abhängigkeiten erfassen. Ohne kontinuierliches Monitoring hilft auch der sorgfältigste SBOM nicht: Ein CVE, der heute veröffentlicht wird und eine Komponente aus einem Build von vor vier Monaten betrifft, bleibt unbemerkt. Der EU Cyber Resilience Act verlangt ab Dezember 2027 maschinenlesbare, aktuelle SBOMs für alle digitalen Produkte im EU-Markt. Ein einmaliger Build-Export wird das nicht erfüllen.

💡 Was funktioniert besser?

Ebene eins: Jeder Build erzeugt automatisch einen neuen, versionierten SBOM – in der CI/CD-Pipeline, nicht daneben. Ebene zwei: Tools wie OWASP Dependency-Track beobachten jeden dieser SBOMs kontinuierlich. Taucht ein neuer CVE auf, der eine bereits ausgelieferte Komponente betrifft, wird das sofort sichtbar – unabhängig davon, wann der Build erzeugt wurde. Der SBOM wird damit vom Snapshot zum Frühwarnsystem.

📚🔍