🔍 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.

📚🔍