SBOM für Java-Entwickler – Was bringt mir das im Alltag wirklich – Teil 2

Moderne Java-Anwendungen bestehen längst nicht mehr nur aus eigenem Quellcode. Sie enthalten Frameworks, Libraries, Build-Plugins, transitive Abhängigkeiten sowie je nach Anwendung Frontend-Bestandteile. Gerade bei Webanwendungen mit Vaadin (https://3g3.eu/vdn) wird deutlich, wie produktiv Java-Entwicklung heute sein kann, aber auch, wie komplex die tatsächliche Softwarezusammensetzung im Hintergrund wird. Eine Software Bill of Materials, kurz SBOM, macht diese Zusammensetzung sichtbar und liefert eine maschinenlesbare Grundlage für Sicherheits-, Lizenz- und Release-Entscheidungen. Dieser Artikel zeigt, warum SBOMs für Java-Entwickler im Alltag relevant sind, wie sie mit Maven, Gradle und CycloneDX erzeugt werden können und warum die eigentliche Wirkung erst durch Auswertung entsteht. Als pragmatischer nächster Schritt wird gezeigt, wie eine erzeugte SBOM mit dem freien SBOM-Checker von Exodos Labs (https://3g3.eu/exodos-free-sbom) geprüft werden kann, um aus einer technischen Komponentenliste eine konkrete erste Risikosicht zu gewinnen.

Kommen wir nun zu Teil 2 der Serie.

Vaadin als Praxisbeispiel einer modernen Java-Webanwendung

Bis hierhin haben wir SBOMs vor allem allgemein betrachtet: als Inventar der Softwarebestandteile, als Ergebnis eines Builds und als Grundlage für spätere Analysen. Wirklich greifbar wird das Thema jedoch erst an einem konkreten Anwendungstyp. Eine moderne Java-Webanwendung ist dafür besonders geeignet, weil sie zeigt, dass Software heute selten aus einer einzigen, sauber abgegrenzten Schicht besteht. Ein gutes Beispiel dafür ist eine Anwendung mit Vaadin.

Vaadin ist aus Sicht der Entwickler angenehm, weil sich Weboberflächen weitgehend in Java entwickeln lassen. Man beschreibt Views, Komponenten, Layouts, Events und Datenbindung im gewohnten Java-Modell. Gerade für Teams, die stark aus der Java-Welt kommen, reduziert das die mentale Distanz zwischen Backend und UI erheblich. Die Anwendung fühlt sich wie ein Java-Projekt an, wird mit Maven oder Gradle gebaut und läuft am Ende als klassische Serveranwendung, beispielsweise als JAR oder WAR.

Genau diese Vertrautheit kann jedoch dazu führen, dass die tatsächliche Zusammensetzung der Software unterschätzt wird. Eine Vaadin-Anwendung besteht nicht nur aus den eigenen Java-Klassen. Sie enthält Vaadin-Artefakte, serverseitige Komponenten, Build-Unterstützung, transitive Java-Abhängigkeiten sowie je nach Projektkonfiguration Frontend-Bestandteile, die während des Builds verarbeitet werden. Aus Sicht des Entwicklers bleibt vieles davon im Hintergrund. Aus Sicht der Software-Supply-Chain ist es jedoch relevant.

Das bedeutet nicht, dass Vaadin dadurch problematisch wäre. Im Gegenteil: Gerade weil Vaadin viele technische Details integriert und für Java-Entwickler produktiv zugänglich macht, eignet es sich gut als Beispiel. Die Anwendung zeigt, wie moderne Java-Projekte funktionieren: Man schreibt fokussierten Anwendungscode, nutzt ein Framework und verlässt sich darauf, dass der Build-Prozess die notwendigen Bestandteile zusammenführt. Eine SBOM hilft dabei, dieses Zusammenführen sichtbar zu machen.

Nehmen wir eine typische interne Geschäftsanwendung. Sie umfasst eine Vaadin-Oberfläche, einige Services, ein Datenmodell, Validierungslogik, gegebenenfalls eine Persistenzschicht sowie verschiedene Hilfsbibliotheken. In der pom.xml stehen direkte Abhängigkeiten, etwa zu Vaadin, Logging, JSON-Verarbeitung, Testing oder weiteren technischen Bausteinen. Diese direkten Abhängigkeiten ziehen wiederum transitive Abhängigkeiten nach sich. Einige davon sind offensichtlich, andere sieht man im Alltag kaum. Trotzdem können sie im fertigen Artefakt oder im Build-Prozess eine Rolle spielen.

Eine SBOM macht genau diese Ebene sichtbar. Sie zeigt nicht nur, dass das Projekt Vaadin verwendet, sondern auch, welche konkreten Artefakte und Versionen daran beteiligt sind. Sie kann sichtbar machen, welche weiteren Bibliotheken über das Framework oder andere direkte Dependencies in das Projekt gelangen. Dadurch entsteht ein vollständigeres Bild der Anwendung. Für Entwickler ist das hilfreich, weil die Anwendung dadurch nicht mehr nur als eigener Quellcode plus ein paar bekannte Libraries erscheint, sondern als nachvollziehbarer Komponentenverbund.

Besonders wichtig ist dabei der Release-Bezug. Im Alltag wird häufig über den aktuellen Stand des Quellcodes gesprochen. Für Sicherheitsfragen ist jedoch entscheidend, was tatsächlich ausgeliefert wurde. Eine Vaadin-Anwendung kann im Entwicklungsmodus anders aussehen als im produktiven Build. Entwicklungswerkzeuge, Testabhängigkeiten oder Build-Hilfen können in einem Kontext relevant sein und in einem anderen nicht. Eine SBOM sollte deshalb bewusst für das Artefakt erzeugt werden, das später bewertet oder ausgeliefert wird.

Das ist auch der Grund, warum der Scope der SBOM für Vaadin-Anwendungen klar definiert werden sollte. Soll die SBOM die produktive Serveranwendung beschreiben? Soll sie zusätzlich Build-Zeit-Abhängigkeiten berücksichtigen? Geht es um ein JAR, ein WAR, ein Container-Image oder ein vollständiges Deployment? Für einen ersten praktischen Einstieg ist meistens die produktive Anwendungssicht am wertvollsten. Sie beantwortet die Frage, welche Komponenten im Artefakt enthalten sind, das betrieben oder an Kunden ausgeliefert wird.

In einem Security-Kontext ergeben sich daraus sehr konkrete Fragen. Welche Vaadin-Version wird verwendet? Welche transitiven Bibliotheken bringt diese Version mit? Gibt es bekannte Schwachstellen in einer dieser Komponenten? Ist die betroffene Komponente Teil des produktiven Artefakts oder nur im Build- oder Testkontext relevant? Welche Lizenzen gelangen über direkte und indirekte Abhängigkeiten in das Projekt? Hat sich zwischen zwei Releases eine sicherheitsrelevante Komponente verändert?

Ohne SBOM müssen diese Fragen oft über Maven- oder Gradle-Ausgaben, manuelle Analyse und Projektwissen beantwortet werden. Das kann funktionieren, ist aber fehleranfällig. Besonders wenn mehrere Anwendungen, verschiedene Release-Stände oder unterschiedliche Kundeninstallationen vorliegen, wird es schwierig, eine belastbare Aussage zu treffen. Eine SBOM reduziert diese Unsicherheit, da sie den Zustand eines konkreten Builds dokumentiert.

Für Vaadin-Projekte kommt noch ein weiterer Aspekt hinzu: Die Grenze zwischen klassischer Java-Anwendung und moderner Webanwendung ist technisch fließend. Der Entwickler arbeitet primär in Java, die ausgelieferte Anwendung enthält jedoch eine UI-Schicht, die im Browser sichtbar wird, und deren technische Bestandteile durch den Build-Prozess vorbereitet werden. Dadurch wird die Frage nach der Softwarezusammensetzung breiter gefasst als bei einer kleinen Kommandozeilenanwendung oder einer einfachen Library. Eine SBOM hilft, diese Breite strukturiert zu erfassen.

Wichtig bleibt dabei: Die SBOM ersetzt nicht das Verständnis der Anwendung. Sie nennt nicht automatisch, welche Risiken im konkreten fachlichen Kontext relevant sind. Sie erklärt auch nicht, ob eine Schwachstelle tatsächlich ausnutzbar ist. Aber sie liefert die Ausgangsdaten, ohne die eine solche Bewertung kaum seriös möglich ist. Gerade bei frameworkbasierten Anwendungen ist diese Grundlage wertvoll, weil viele Komponenten nicht bewusst einzeln ausgewählt, sondern über das Framework und dessen Ökosystem eingebracht werden.

SBOM auswerten: Schwachstellen, Lizenzen und veraltete Abhängigkeiten

Eine SBOM zu erzeugen ist nur der erste Schritt. Solange sie lediglich im target-Verzeichnis liegt oder als zusätzliches Artefakt im Build gespeichert wird, bleibt sie eine Beschreibung der Softwarezusammensetzung. Wertvoll wird sie, wenn daraus konkrete Fragen beantwortet werden: Welche Komponenten sind angreifbar? Welche Lizenzen muss ich beachten? Welche Abhängigkeiten sind veraltet? Welche Änderungen haben sich gegenüber dem letzten Release ergeben?

Für Java-Entwickler ist die naheliegendste Frage häufig die nach bekannten Schwachstellen. Wird eine neue CVE veröffentlicht, beginnt in vielen Teams die Suche nach betroffenen Komponenten. Ohne SBOM muss diese Suche oft über Projektdateien, Dependency-Trees, Build-Logs oder manuelle Prüfungen erfolgen. Mit einer SBOM liegt bereits ein maschinenlesbares Inventar vor. Ein Analysewerkzeug kann die enthaltenen Komponenten und Versionen gegen Schwachstellendatenbanken prüfen und Hinweise darauf geben, welche Bestandteile genauer untersucht werden müssen.

Eine SBOM zeigt zunächst, ob eine betroffene Komponente in einer bestimmten Version vorhanden ist. Ob daraus ein echtes Risiko entsteht, hängt vom Anwendungskontext ab. Wird die betroffene Klasse überhaupt verwendet? Ist der verwundbare Codepfad erreichbar? Ist die Komponente Teil des produktiven Artefakts oder nur im Testkontext vorhanden? Gibt es eine schützende Konfiguration? Diese Bewertung kann die SBOM nicht allein übernehmen. Aber sie liefert die Ausgangsdaten, ohne die eine solche Bewertung kaum belastbar ist.

Gerade bei transitiven Abhängigkeiten ist diese Ausgangsbasis wichtig. Eine Schwachstelle betrifft möglicherweise nicht die Bibliothek, die das Team direkt eingebunden hat, sondern eine Komponente, die über ein Framework oder eine Hilfsbibliothek in das Projekt gelangt ist. In diesem Fall reicht der Blick in die direkte Dependency-Liste nicht aus. Die SBOM kann sichtbar machen, dass die problematische Komponente vorhanden ist und über welche Beziehung sie ins Projekt gelangt. Dadurch wird die nächste Entscheidung einfacher: Muss eine direkte Abhängigkeit aktualisiert werden? Muss eine transitive Version überschrieben werden? Muss ein Framework-Update eingeplant werden? Oder ist die Komponente im konkreten Artefakt gar nicht relevant?

Neben Schwachstellen ist Lizenzen ein zweiter wichtiger Auswertungsbereich. Open Source ist ein zentraler Bestandteil der modernen Java-Entwicklung. Die meisten Projekte nutzen zahlreiche Bibliotheken, ohne dass jede Lizenz im Alltag einzeln betrachtet wird. Eine SBOM kann Lizenzinformationen bündeln und sichtbar machen. Dadurch lässt sich früh erkennen, ob eine Anwendung Komponenten enthält, deren Lizenzbedingungen genauer geprüft werden sollten.

Ein weiterer Nutzen liegt im Umgang mit veralteten Abhängigkeiten. Nicht jede alte Version ist automatisch unsicher. Aber sehr alte oder lange nicht aktualisierte Komponenten erhöhen das Wartungsrisiko. Sie können bekannte Schwachstellen enthalten, mit neueren Plattformen inkompatibel sein oder von Projekten stammen, die kaum noch gepflegt werden. Eine SBOM kann dabei helfen, solche Komponenten systematisch zu identifizieren. Sie zeigt, welche Versionen tatsächlich verwendet werden, und schafft damit eine Grundlage für geplante Updates.

Besonders nützlich ist die Auswertung, wenn mehrere SBOMs miteinander verglichen werden. Welche Komponenten sind in diesem Release neu hinzugekommen? Welche wurden aktualisiert? Welche sind verschwunden? Hat ein scheinbar kleines Framework-Update eine größere Anzahl transitiver Abhängigkeiten verändert? Solche Fragen sind im Alltag relevant, weil Risiken nicht nur durch offensichtliche Codeänderungen entstehen. Auch Änderungen in der Software-Supply-Chain können sicherheitsrelevant sein.

Die Auswertung einer SBOM kann zudem helfen, sowohl die interne als auch die externe Kommunikation zu verbessern. Wenn ein Kunde fragt, ob eine bestimmte Schwachstelle relevant ist, kann das Team gezielter darauf antworten. Wenn ein Security-Team eine Risikobewertung benötigt, muss nicht zuerst eine manuelle Komponentenliste erstellt werden. Wenn ein Release freigegeben werden soll, kann die SBOM als Grundlage für eine technische Prüfung dienen. Das spart Zeit und reduziert Unsicherheit.

Dabei sollte eine SBOM-Auswertung nicht als einmaliger Sonderfall verstanden werden. Der größte Nutzen entsteht, wenn die Auswertung wiederholbar ist. Ein Team sollte nicht erst bei einer kritischen Schwachstelle beginnen, seine Abhängigkeiten zu erfassen. Es ist sinnvoller, die SBOM regelmäßig zu erzeugen und bei Bedarf zu prüfen. So entsteht im Laufe der Zeit ein besseres Verständnis der eigenen Softwarelieferkette.

Trotzdem sollte man den Einstieg pragmatisch angehen. Für den Anfang reicht häufig ein einfacher Ablauf: SBOM erzeugen, Datei mit einem Analysewerkzeug prüfen, Auffälligkeiten bewerten, notwendige Maßnahmen ableiten. Daraus entsteht kein perfekter Security-Prozess, sondern ein konkreter Fortschritt. Das Team erhält eine belastbarere Sicht auf die eigene Anwendung und kann Risiken fundierter priorisieren.

Wichtig ist auch, die Ergebnisse nicht mechanisch zu behandeln. Eine lange Liste von Findings ist noch keine sinnvolle Sicherheitsarbeit. Entscheidend ist die Einordnung. Welche Schwachstellen betreffen produktive Komponenten? Welche Komponenten sind nur im Testkontext relevant? Welche Lizenzen müssen wirklich geprüft werden? Welche Updates sind kurzfristig notwendig und welche können geplant erfolgen? Eine SBOM liefert Daten. Die technische Bewertung bleibt Aufgabe des Teams.

Genau darin liegt aber auch der Vorteil. Die Diskussion verschiebt sich von Vermutungen hin zu überprüfbaren Informationen. Statt allgemein zu fragen, ob eine Anwendung „sichere Dependencies“ verwendet, kann konkret geprüft werden, welche Komponenten in welcher Version enthalten sind. Statt Lizenzrisiken nur abstrakt zu betrachten, lassen sich die tatsächlich verwendeten Bibliotheken analysieren. Statt bei jeder neuen CVE von vorne zu suchen, kann ein vorhandenes Inventar ausgewertet werden.

Typische Fehler: Warum viele SBOMs wertlos bleiben

Eine SBOM kann sehr wertvoll sein. Sie kann aber auch fast wertlos bleiben. Das passiert immer dann, wenn sie nur erzeugt wird, um eine Anforderung formal zu erfüllen, ohne dass sie im Entwicklungsprozess tatsächlich genutzt wird. Dann entsteht zwar eine Datei, aber kein besseres Verständnis der Anwendung. Aus einem potenziell nützlichen Werkzeug wird ein weiteres Artefakt, das irgendwo im Build-Verzeichnis, in einem Repository oder in einem Release-Ordner liegt und kaum jemand beachtet.

Der erste typische Fehler besteht darin, die SBOM nur einmal zu erzeugen. Gerade beim Einstieg ist es verlockend, eine SBOM zu generieren, sie erfolgreich zu öffnen und das Thema damit als erledigt zu betrachten. Software verändert sich jedoch ständig. Dependencies werden aktualisiert, Framework-Versionen wechseln, neue Bibliotheken kommen hinzu, alte verschwinden, transitive Abhängigkeiten ändern sich. Eine SBOM beschreibt immer nur einen konkreten Zustand. Wenn dieser Zustand nicht regelmäßig aktualisiert wird, verliert die Datei schnell an Wert.

Ein zweiter Fehler ist der fehlende Bezug zu einem konkreten Artefakt oder Release. Eine SBOM ist nur dann wirklich hilfreich, wenn klar ist, wofür sie da ist. Beschreibt sie den aktuellen Entwicklungsstand? Den letzten erfolgreichen Build? Ein bestimmtes JAR? Ein WAR? Ein Container-Image? Eine produktive Kundeninstallation? Ohne diese Zuordnung wird die spätere Analyse unscharf. Dann kann zwar eine Komponente in der SBOM stehen, aber bleibt unklar, ob sie tatsächlich in der ausgelieferten Version enthalten war.

Gerade für Java-Projekte ist dieser Punkt wichtig. Der aktuelle Quellcode entspricht nicht automatisch dem produktiven Release. Ein Kunde kann noch eine ältere Version betreiben. Ein Hotfix kann mit einem anderen Stand entwickelt worden sein. Ein Entwicklungsbranch kann bereits aktualisierte Abhängigkeiten enthalten, während die produktive Version noch ältere Komponenten nutzt. Eine SBOM ohne Release-Bezug beantwortet dann nicht die entscheidende Frage: Was steckt wirklich in der Software, die gerade betrieben oder ausgeliefert wird?

Ein dritter Fehler besteht darin, die SBOM nicht auszuwerten. Die Generierung allein ist noch keine Sicherheitsmaßnahme. Sie erzeugt zunächst nur ein Inventar. Dieses Inventar muss mit Schwachstellendaten, Lizenzregeln, internen Richtlinien oder Wartungsinformationen abgeglichen werden. Wenn diese Auswertung nicht erfolgt, bleibt die SBOM inaktiv. Sie kann zwar im Ernstfall helfen, liefert dem Team im Alltag jedoch keine konkreten Hinweise.

Daran schließt sich ein weiterer Fehler an: Ergebnisse werden mechanisch behandelt. Eine Analyse kann viele Ergebnisse liefern. Nicht jedes Finding ist gleich kritisch, nicht jede alte Version ist sofort ein Sicherheitsproblem und nicht jede Lizenzangabe ist automatisch ein Blocker. Umgekehrt darf eine lange Liste auch nicht ignoriert werden, nur weil sie unbequem ist. Entscheidend ist die technische Einordnung. Welche Komponente ist produktiv relevant? Welche Schwachstelle betrifft einen erreichbaren Codepfad? Welche Lizenz muss wirklich geprüft werden? Welche Aktualisierung ist dringend und welche kann geplant erfolgen?

Ein fünfter Fehler ist eine zu breite oder unklare Scope-Definition. Manche SBOMs enthalten Test-Abhängigkeiten, Entwicklungswerkzeuge oder Build-Time-Komponenten, obwohl eigentlich das produktive Artefakt bewertet werden soll. Andere SBOMs sind zu eng gefasst und lassen relevante Bestandteile aus. Beides kann zu falschen Schlussfolgerungen führen. Wenn Test-Dependencies als produktive Risiken erscheinen, entsteht unnötiger Lärm. Wenn produktive Komponenten fehlen, entsteht eine gefährliche Scheinsicherheit.

Auch Multi-Modul-Projekte bringen typische Fallstricke mit sich. Wird nur ein einzelnes Modul betrachtet, obwohl das ausgelieferte Produkt aus mehreren Modulen besteht, bleibt das Inventar unvollständig. Wird dagegen eine aggregierte SBOM erzeugt, muss klar sein, welche Module tatsächlich zum Produkt gehören. Gerade bei Anwendungen mit Core-Modul, Server-Modul, UI-Modul und internen Hilfsbibliotheken ist diese Frage nicht nebensächlich. Die SBOM muss zur Architektur und zum Auslieferungsmodell passen.

Ein weiterer häufiger Fehler ist die fehlende Versionierung der SBOM. Wenn mehrere SBOM-Dateien existieren, aber nicht klar ist, welche zu welchem Build gehören, wird deren spätere Nutzung erschwert. Sinnvoll ist eine saubere Ablage zusammen mit den Release-Artefakten oder zumindest eine eindeutige Benennung und Zuordnung. Die SBOM sollte nicht irgendeine Datei sein, sondern Teil der nachvollziehbaren Release-Historie.

Problematisch ist auch, wenn die SBOM-Erzeugung nicht reproduzierbar ist. Wird sie manuell auf einem Entwicklerrechner erzeugt, mit unklarer Plugin-Version, wechselnden Profilen oder lokalen Besonderheiten, können unterschiedliche Ergebnisse entstehen. Für erste Experimente ist das in Ordnung. Für belastbare Aussagen sollte die Erzeugung jedoch möglichst kontrolliert erfolgen. Die Plugin-Version sollte festgelegt sein, der Build sollte nachvollziehbar sein und der erzeugte Scope sollte dokumentiert werden.

Ein weiterer Fehler liegt in falschen Erwartungen. Eine SBOM ist kein vollständiger Sicherheitsnachweis. Sie ersetzt weder ein Code-Review noch Tests noch eine Architekturprüfung noch die Bewertung der tatsächlichen Ausnutzbarkeit. Sie gibt auch nicht automatisch an, ob eine Anwendung sicher oder unsicher ist. Wer eine SBOM als abschließendes Prüfsiegel versteht, überschätzt sie. Wer sie als strukturiertes Inventar versteht, nutzt sie richtig.

Umgekehrt sollte man die SBOM nicht unterschätzen. Manche Teams betrachten sie nur als Compliance-Dokument, das für Kunden oder Auditoren erstellt wird. Damit verschenken sie einen großen Teil des Nutzens. Für Entwickler ist die SBOM vor allem ein Werkzeug, um die eigene Anwendung besser zu verstehen. Sie zeigt, welche Komponenten vorhanden sind, welche Versionen verwendet werden und wo sich Risiken konzentrieren können.

Ein letzter, sehr praktischer Fehler ist die fehlende Verantwortung. Wenn im Team niemand weiß, wer die SBOM erzeugt, prüft, bewertet oder bei Auffälligkeiten reagiert, bleibt der Prozess unvollständig. Es muss nicht sofort ein großes Governance-Modell entstehen. Aber es sollte klar sein, wer bei kritischen Findings entscheidet, wer Updates einplant und wer mit Security, Betrieb oder Kunden kommuniziert. Ohne diese Zuständigkeiten wird aus der SBOM schnell ein technisches Artefakt ohne Wirkung.

Die meisten dieser Fehler haben eine gemeinsame Ursache: Die SBOM wird als Datei verstanden, nicht als Teil eines Arbeitsablaufs. Genau hier sollte der Perspektivwechsel stattfinden. Eine SBOM ist dann wertvoll, wenn sie reproduzierbar erzeugt, einem konkreten Artefakt zugeordnet, regelmäßig geprüft und fachlich bewertet wird. Sie muss nicht perfekt sein, um nützlich zu sein. Aber sie muss benutzt werden.

Für den Einstieg reicht deshalb eine einfache Leitfrage: Welche Entscheidung soll diese SBOM unterstützen? Soll sie dabei helfen, auf CVEs zu reagieren? Soll sie Lizenzrisiken sichtbar machen? Soll sie Release-Änderungen nachvollziehbar machen? Soll sie Kundenfragen beantworten? Wenn diese Frage klar ist, wird auch klarer, wie die SBOM erzeugt, abgelegt und ausgewertet werden sollte.

Eine wertlose SBOM ist meist nicht technisch falsch, sondern organisatorisch isoliert. Sie existiert, beeinflusst aber keine Entscheidung. Eine nützliche SBOM dagegen ist Teil des Entwickleralltags. Sie hilft dem Team, Abhängigkeiten zu verstehen, Risiken zu priorisieren und nachvollziehbar über die Sicherheit der Software-Supply-Chain zu sprechen.

Pragmatischer Einstieg: erzeugen, prüfen, automatisieren

Nach den typischen Fehlern stellt sich die praktische Frage: Wie beginnt man sinnvoll, ohne aus dem Thema sofort ein großes Governance-Projekt zu machen? Genau dieser pragmatische Einstieg ist wichtig. Eine SBOM entfaltet ihren Wert nicht erst dann, wenn ein Unternehmen bereits eine vollständig automatisierte Security-Pipeline, zentrale Richtlinien und ein ausgereiftes Risikomanagement besitzt. Der Nutzen beginnt viel früher: bei einem Entwicklerteam, das wissen möchte, woraus die eigene Anwendung tatsächlich besteht.

Der erste Schritt ist deshalb bewusst einfach: Die SBOM wird erzeugt. Für ein Java-Projekt bedeutet das in der Regel, den bestehenden Maven- oder Gradle-Build zu erweitern. Es muss kein separates Dokument gepflegt und keine manuelle Komponentenliste erstellt werden. Das Build-System kennt die aufgelösten Abhängigkeiten bereits. Die SBOM macht diese Informationen sichtbar und speichert sie in einem Format, das später analysiert werden kann.

Für den Anfang reicht es vollkommen aus, eine CycloneDX-SBOM lokal zu erzeugen und sich das Ergebnis anzusehen. Schon dieser Schritt ist oft aufschlussreich. Viele Teams stellen dabei fest, dass ihre Anwendung deutlich mehr Komponenten enthält, als ihnen im Alltag bewusst war. Besonders transitive Abhängigkeiten, ältere Bibliotheksversionen oder unerwartete Lizenzen werden dadurch sichtbar. Der erste Gewinn ist also nicht Automatisierung, sondern Transparenz.

Wichtig ist, diesen ersten Schritt nicht zu kompliziert zu machen. Es muss nicht sofort jede Sonderform des Builds, jedes Deployment-Ziel und jedes mögliche Artefakt abgedeckt werden. Sinnvoller ist ein klar begrenzter Startpunkt: eine Anwendung, ein Build, ein produktionsnaher Scope, eine SBOM-Datei. Für eine typische Java-Webanwendung kann das beispielsweise bedeuten, die SBOM beim package-Build zu erzeugen und als target/bom.json abzulegen.

Der zweite Schritt ist die Prüfung. Eine SBOM nur zu erzeugen, reicht nicht aus. Sie muss ausgewertet werden. Dafür kann die Datei an ein Analysewerkzeug übergeben werden, das die enthaltenen Komponenten gegen bekannte Schwachstellen, Lizenzinformationen oder andere Risikodaten prüft. Aus der statischen Komponentenliste wird dadurch eine Arbeitsgrundlage. Das Team sieht, welche Punkte genauer betrachtet werden müssen.

Diese Prüfung sollte bewusst als Einstieg in eine Bewertung verstanden werden, nicht als automatisches Urteil. Wenn ein Werkzeug eine bekannte Schwachstelle meldet, ist das ein Hinweis. Danach muss geprüft werden, ob die betroffene Komponente im produktiven Kontext relevant ist, ob der verwundbare Codepfad erreichbar ist und welche Maßnahme sinnvoll ist. Manchmal ist ein Update notwendig. Manchmal reicht eine Konfigurationsänderung. Manchmal betrifft der Fund nur eine Test-Abhängigkeit oder einen nicht genutzten Teil einer Bibliothek. Die SBOM liefert die Daten, die Bewertung bleibt technische Arbeit.

Dasselbe gilt für Lizenzinformationen. Eine Analyse kann zeigen, welche Lizenzen in den verwendeten Komponenten auftauchen. Daraus entsteht aber noch keine vollständige juristische Bewertung. Für Entwickler ist trotzdem viel gewonnen, weil potenzielle Lizenzthemen früh sichtbar werden. Das Team kann rechtzeitig klären, ob bestimmte Komponenten zum eigenen Produkt, zur geplanten Auslieferung oder zu internen Vorgaben passen.

Der dritte Schritt ist die Wiederholung. Eine einmal erzeugte und einmal geprüfte SBOM ist ein guter Anfang, aber noch kein stabiler Prozess. Abhängigkeiten ändern sich mit der Zeit. Deshalb sollte die Erzeugung der SBOM reproduzierbar werden. Zunächst kann das ein dokumentierter Maven- oder Gradle-Aufruf sein. Später kann daraus ein fester Bestandteil des Builds werden. Entscheidend ist, dass die SBOM nicht von zufälligen lokalen Einstellungen abhängt, sondern nachvollziehbar entsteht.

Erst danach lohnt sich die Automatisierung. Viele Teams machen den Fehler, sofort mit dem Zielbild zu starten: Pipeline-Gates, zentrale Dashboards, Richtlinien, Eskalationsprozesse und Reporting. Das kann später sinnvoll sein, überfordert aber den Einstieg. Besser ist eine stufenweise Entwicklung. Zuerst wird die SBOM erzeugt. Dann wird sie geprüft. Dann wird der Ablauf wiederholbar gemacht. Dann wird er automatisiert. Und erst wenn genügend Erfahrung vorliegt, werden harte Regeln oder blockierende Build-Schritte eingeführt.

Ein pragmatischer Ablauf für ein Java-Team kann daher so aussehen: Bei einem Release-Build wird eine SBOM erzeugt. Diese SBOM wird zusammen mit dem Artefakt abgelegt. Anschließend wird sie mit einem Analysewerkzeug geprüft. Die Ergebnisse werden nicht blind übernommen, sondern technisch eingeordnet. Kritische Punkte führen zu Updates, Konfigurationsänderungen oder dokumentierten Risikoentscheidungen. Mit der Zeit wird dieser Ablauf so selbstverständlich wie Tests, Code-Reviews oder Dependency-Updates.

Für Vaadin-Anwendungen ist dieser Ablauf besonders gut nachvollziehbar. Das Team baut eine serverseitige Java-Webanwendung, nutzt Vaadin als UI-Framework und erzeugt am Ende ein konkretes Artefakt. Die SBOM beschreibt genau dieses Artefakt. Sie zeigt, welche Vaadin-Komponenten, Java-Bibliotheken und transitiven Abhängigkeiten beteiligt sind. Bei einem Framework-Update kann das Team später prüfen, welche Komponenten sich verändert haben. Bei einer neuen Schwachstelle kann schneller festgestellt werden, ob die Anwendung betroffen sein könnte.

Der praktische Einstieg sollte außerdem klar zwischen Experiment und belastbarer Nutzung unterscheiden. Ein lokaler Test ist hervorragend, um das Thema zu verstehen. Für echte Release-Entscheidungen braucht es jedoch mehr Disziplin. Die Plugin-Version sollte festgelegt sein. Der Build sollte reproduzierbar sein. Der Scope der SBOM sollte bewusst gewählt werden. Die Datei sollte eindeutig einem Artefakt oder Release zugeordnet sein. Dadurch wird aus einem Experiment ein belastbares Arbeitsmittel.

Hilfreich ist auch eine einfache Namens- und Ablagestruktur. Eine SBOM sollte nicht anonym als irgendeine Datei herumliegen. Sie sollte erkennbar zu einem Projekt, einer Version und einem Build gehören. Ob sie später im Release-Ordner, im Artefakt-Repository oder in einem separaten Security-System gespeichert wird, ist zunächst weniger wichtig als die eindeutige Zuordnung. Wer Monate später eine Kundeninstallation bewertet, muss wissen, welche SBOM zu welcher ausgelieferten Version gehört.

Ein weiterer pragmatischer Punkt ist die Begrenzung der ersten Fragestellungen. Ein Team muss nicht sofort alle denkbaren Risiken bewerten. Für den Einstieg reichen wenige konkrete Fragen: Enthält die Anwendung bekannte kritische Schwachstellen? Gibt es auffällige oder unerwartete Lizenzen? Werden sehr alte Komponenten verwendet? Hat sich die Dependency-Landschaft seit dem letzten Release deutlich verändert? Diese Fragen sind konkret genug, um handlungsfähig zu werden, ohne den Prozess zu überfrachten.

Mit der Zeit kann dieser Ablauf wachsen. Aus der lokalen SBOM-Erzeugung wird ein Build-Schritt. Aus der manuellen Prüfung wird eine regelmäßige Analyse. Aus einzelnen Auffälligkeiten werden definierte Entscheidungspfade. Aus informellen Absprachen entstehen einfache Teamregeln. Erst wenn dieser Grundprozess funktioniert, lohnt es sich, über striktere Policies, automatische Build-Abbrüche oder zentrale Dashboards nachzudenken.

Der entscheidende Punkt ist: Eine SBOM muss nicht perfekt eingeführt werden, um nützlich zu sein. Ein unvollständiger, aber bewusst genutzter Einstieg ist wertvoller als ein großes Konzept, das nie umgesetzt wird. Für Java-Entwickler beginnt der Nutzen genau dort, wo aus dem eigenen Build ein prüfbares Inventar entsteht. Danach kann das Team Schritt für Schritt entscheiden, welche Auswertungen, Prüfungen und Automatisierungen wirklich sinnvoll sind.

So wird die SBOM vom abstrakten Security-Begriff zu einem normalen Bestandteil des Entwicklungsalltags. Sie wird erzeugt, geprüft, verstanden und später automatisiert. Nicht als Selbstzweck, sondern als Werkzeug, um bessere Entscheidungen über Abhängigkeiten, Updates, Lizenzen und Risiken zu treffen.

Exodos Labs als freier SBOM-Checker

Nach der Erzeugung einer SBOM stellt sich die entscheidende Anschlussfrage: Was mache ich jetzt mit dieser Datei? Genau an dieser Stelle sollte der Leser nicht mit einer abstrakten Empfehlung zurückgelassen werden. Wenn die SBOM als bom.json vorliegt, braucht es einen einfachen nächsten Schritt. Ein naheliegender Einstieg ist ein freier SBOM-Checker, mit dem die Datei analysiert und erste Risiken sichtbar gemacht werden können.

Hier bietet sich Exodos Labs als praktischer nächster Schritt an. Der freie SBOM Risk Analyzer von Exodos Labs (https://3g3.eu/exodos-free-sbom) erlaubt es, eine vorhandene SBOM hochzuladen und eine erste Risikoeinschätzung zu erhalten. Akzeptiert werden CycloneDX JSON und SPDX JSON. Damit passt der Dienst gut zu dem zuvor beschriebenen Maven- oder Gradle-Workflow, bei dem eine CycloneDX-SBOM als JSON-Datei erzeugt wird.

Wichtig ist die richtige Einordnung. Ein solcher Checker ersetzt nicht die technische Bewertung durch das Entwicklerteam. Er ist kein Freifahrtschein und kein finales Sicherheitszertifikat. Er ist ein schneller Realitätscheck. Die erzeugte SBOM wird nicht nur geöffnet oder archiviert, sondern tatsächlich genutzt. Aus der Komponentenliste entsteht eine erste Analyseansicht: Welche Schwachstellen werden gefunden? Welche Lizenzthemen tauchen auf? Gibt es Auffälligkeiten in der Softwarelieferkette?

Für den Alltag eines Java-Teams ist genau dieser Übergang wertvoll. Viele Entwickler können eine SBOM technisch erzeugen, bleiben danach aber bei der Frage stehen, wie die Datei konkret interpretiert werden soll. Ein Analysewerkzeug senkt diese Einstiegshürde. Es nimmt die maschinenlesbare Datei entgegen, korreliert die enthaltenen Komponenten mit bekannten Risikoinformationen und macht die Ergebnisse greifbarer. Dadurch wird die SBOM aus dem Build-Artefakt zu einem Gesprächsanlass für Security, Architektur und Release-Entscheidungen.

Der Ablauf ist bewusst einfach. Zuerst wird die Java-Anwendung gebaut. Dabei entsteht über das CycloneDX-Maven-Plugin oder ein entsprechendes Gradle-Setup eine SBOM, beispielsweise als target/bom.json. Diese Datei wird anschließend im Checker analysiert. Danach liegen erste Hinweise vor, die das Team bewerten kann. Dieser Ablauf ist niedrigschwellig genug, um ihn auch ohne große Plattformeinführung auszuprobieren.

Gerade für eine Vaadin-Anwendung ist das ein guter Test. Das Team sieht nicht nur die eigenen direkten Abhängigkeiten, sondern auch die weiteren Komponenten, die über Framework, Build und transitive Dependencies in das Projekt gelangen. Wenn der Checker Auffälligkeiten meldet, kann das Team gezielt prüfen, ob diese Komponenten im produktiven Artefakt relevant sind, ob ein Update notwendig ist oder ob die Meldung im konkreten Kontext anders bewertet werden muss.

Dabei sollte man die Ergebnisse nicht mechanisch übernehmen. Eine Schwachstellenmeldung bedeutet zunächst, dass eine Komponente in einer Version bekannt ist, für die ein Risiko beschrieben wurde. Daraus folgt noch nicht automatisch, dass die eigene Anwendung ausnutzbar ist. Ebenso bedeutet eine Lizenzauffälligkeit nicht automatisch, dass ein Produkt nicht ausgeliefert werden darf. Die Analyse liefert Hinweise. Die fachliche Einordnung bleibt Aufgabe des Teams.

Der Nutzen eines solchen freien Checks liegt deshalb vor allem in der Beschleunigung des Einstiegs. Statt eine SBOM nur theoretisch zu besprechen, kann ein Team sofort sehen, welche Informationen darin praktisch verwertbar sind. Das ist auch didaktisch stark: Wer einmal eine eigene SBOM hochgeladen und die Analyseergebnisse gesehen hat, versteht schneller, warum das Thema mehr ist als Compliance. Die Abhängigkeiten werden sichtbar. Risiken werden diskutierbar. Maßnahmen lassen sich konkreter ableiten.

Fazit: SBOM als Entscheidungsgrundlage, nicht als Compliance-Ablage

Eine SBOM ist kein Selbstzweck. Sie wird nicht wertvoll, weil sie existiert, sondern weil sie Entscheidungen unterstützt. Genau darin liegt der wichtigste Unterschied zwischen einer SBOM als Pflichtdokument und einer SBOM als Werkzeug im Entwickleralltag. Eine Datei, die nur erzeugt und abgelegt wird, verändert wenig. Eine SBOM, die geprüft, verstanden und in konkrete Entscheidungen einbezogen wird, kann dagegen den Umgang mit Abhängigkeiten deutlich verbessern.

Für Java-Entwickler ist dieser Nutzen besonders greifbar. Moderne Java-Anwendungen bestehen nicht nur aus eigenem Quellcode. Sie enthalten direkte und transitive Abhängigkeiten, Framework-Komponenten, Build-Plugins, interne Module und je nach Anwendung weitere Bestandteile aus dem Web- oder Deployment-Umfeld. Maven und Gradle helfen dabei, diese Komponenten zu verwalten und daraus ein lauffähiges Artefakt zu bauen. Eine SBOM ergänzt diesen Prozess, indem sie die Zusammensetzung des Ergebnisses sichtbar macht.

Damit beantwortet sie eine einfache, aber zentrale Frage: Woraus besteht meine Anwendung wirklich? Diese Frage klingt banal, ist im Alltag aber oft schwer zu beantworten. Besonders dann, wenn eine neue Schwachstelle veröffentlicht wird, ein Kunde nach verwendeten Komponenten fragt, eine Lizenz bewertet werden muss oder ein Release nachträglich untersucht werden soll. Ohne Inventar beginnt die Analyse häufig mit Sucharbeit. Mit einer SBOM liegt zumindest eine belastbare Ausgangsbasis vor.

Gleichzeitig sollte man die SBOM nicht überschätzen. Sie macht eine Anwendung nicht automatisch sicher. Sie ersetzt keine Architekturarbeit, keine Tests, keine Code-Reviews und keine Bewertung der tatsächlichen Ausnutzbarkeit einer Schwachstelle. Sie ist auch kein finales Gütesiegel. Ihre Stärke liegt nicht darin, alle Antworten zu liefern, sondern die richtigen Fragen auf eine konkrete Datengrundlage zu stellen.

Genau deshalb passt die SBOM so gut in den praktischen Security-Alltag. Sie verschiebt Diskussionen von Vermutungen hin zu überprüfbaren Informationen. Statt allgemein über „unsichere Dependencies“ zu sprechen, kann ein Team konkrete Komponenten, Versionen und Beziehungen betrachten. Statt Lizenzfragen nur abstrakt zu diskutieren, kann geprüft werden, welche Lizenzen über direkte und transitive Abhängigkeiten tatsächlich in der Anwendung auftauchen. Statt bei jeder neuen CVE von vorn zu beginnen, kann ein vorhandenes Inventar ausgewertet werden.

Der Einstieg muss dabei nicht groß sein. Ein Java-Team kann mit einem einfachen Ablauf beginnen: SBOM erzeugen, prüfen, Ergebnisse bewerten und den Vorgang wiederholen. Daraus entsteht Schritt für Schritt ein reiferer Prozess. Erst lokal, dann im Build, später in Release-Abläufen und gegebenenfalls in weitergehender Automatisierung. Entscheidend ist nicht, sofort ein perfektes System zu etablieren. Entscheidend ist, überhaupt Transparenz zu schaffen und diese Transparenz zu nutzen.

Vaadin zeigt als Praxisbeispiel gut, warum das relevant ist. Eine moderne Java-Webanwendung fühlt sich für Entwickler oft wie ein geschlossenes Java-Projekt an. Tatsächlich entsteht aber ein Softwareprodukt aus eigenen Klassen, Framework-Artefakten, transitiven Abhängigkeiten und Build-Ergebnissen. Eine SBOM macht diese Zusammensetzung sichtbar. Sie hilft dadurch nicht nur Security-Teams, sondern auch den Entwicklern selbst, ihre Anwendung realistischer zu betrachten.

Der nächste sinnvolle Schritt nach der Erzeugung ist die Analyse. Eine SBOM sollte nicht ungenutzt im Projektverzeichnis liegen bleiben. Sie sollte mit einem geeigneten Werkzeug geprüft werden, damit aus der Komponentenliste eine erste Risikosicht entsteht. Ein freier SBOM-Checker wie der von Exodos Labs kann dafür ein pragmatischer Einstieg sein: SBOM erzeugen, Datei prüfen, Auffälligkeiten verstehen und daraus technische Maßnahmen ableiten.

Am Ende bleibt eine einfache Erkenntnis: Software-Supply-Chain-Sicherheit beginnt nicht mit großen Begriffen, sondern mit Transparenz. Wer nicht weiß, welche Komponenten in einer Anwendung stecken, kann Risiken nur unvollständig bewerten. Wer eine SBOM erzeugt und auswertet, schafft eine Grundlage für bessere Entscheidungen. Nicht perfekt, nicht vollständig, aber konkret genug, um den Blindflug zu beenden.

Eine SBOM ist deshalb kein weiteres Dokument für die Ablage. Sie ist eine technische Bestandsaufnahme der eigenen Software. Richtig eingesetzt wird sie zu einem Werkzeug, mit dem Java-Entwickler Abhängigkeiten verstehen, Risiken priorisieren, Updates begründen und gegenüber Security, Betrieb und Kunden nachvollziehbarer kommunizieren können. Genau darin liegt ihr praktischer Wert im Alltag.