Software-Bill of Materials oder kurz SBOMs werden zunehmend als essenzielles Werkzeug im Bereich der Softwareentwicklung und -sicherheit angesehen. Ein SBOM ist im Prinzip eine umfassende Liste aller Komponenten, Bibliotheken und Module, die in einer Softwareanwendung verwendet werden. Diese Liste enthält wichtige Metadaten, wie Versionsnummern, Lizenzinformationen, Quellen-URLs und Hashwerte zur Verifizierung der Integrität. Diese Transparenz hilft Unternehmen, ein besseres Verständnis ihrer Softwarelieferkette zu haben und erleichtert das Management von Sicherheitsrisiken, Lizenzkonformen und Support-Themen. Über lange Zeit wurde angenommen und auch postuliert, dass SBOMs aus zwei klar abgegrenzten Bereichen bestehen: einer statischen und einer dynamischen Komponente.
Die statische Komponente bezieht sich auf die Zusammenstellung der Softwarebestandteile selbst, also die tatsächlichen Komponenten mit ihren festen Metadaten, die sich während der Lebensdauer der Software nicht ändern sollten. Die dynamische Komponente hingegen umfasst beispielsweise Sicherheitswarnungen, Exploit-Informationen und Risikoevaluierungen, die sich angesichts neuer Entdeckungen von Schwachstellen kontinuierlich weiterentwickeln. Dieses klassifizierende Verständnis klingt zunächst logisch und nachvollziehbar: Die Komposition der Software sei einmalig und fix, während die Bedrohungslage dynamisch bleibt. Doch bei genauerer Betrachtung zeigt sich, dass die sogenannte „statische“ Komponente keineswegs so statisch ist, wie häufig angenommen wird. Zunächst spielen menschliche Fehler eine größere Rolle als erwartet.
Selbst kleine Rechtschreibfehler in Komponentennamen oder Versionen können gravierende Auswirkungen haben. Solche Fehler sind nicht nur lästig, sondern können beispielsweise eine „Dependency Confusion“ begünstigen, bei der Angreifer die Kontrolle über Software-Abhängigkeiten erlangen, indem sie gefälschte Komponenten mit ähnlichen Namen platzieren. Fehlerhafte oder fehlende Einträge im SBOM können außerdem dazu führen, dass Sicherheitslücken nicht erkannt oder falsch eingeschätzt werden, was die Grundlage für wirkungsvolle Sicherheitsmaßnahmen untergräbt. Neben Fehlern durch menschliches Versagen und Tool-Fehlkonfigurationen stellt auch die sich verändernde Realität der Komponenten einen dynamischen Faktor dar. Software-Komponenten durchlaufen im Zeitverlauf unterschiedliche Lebenszyklen.
Sie werden weiterentwickelt, verlieren den Support, oder es ändern sich Zuständigkeiten und Lieferanten. Diese Veränderungen sind wichtige Informationen für Unternehmen, denn veraltete oder nicht mehr unterstützte Software bringt erhöhte Risiken mit sich. Somit müssen SBOMs mehrfach aktualisiert werden, um den aktuellen Lebenszyklusstatus der enthaltenen Komponenten korrekt abzubilden. Eine weitere wichtige Dimension betrifft die Lizenzierung. Die rechtlichen Rahmenbedingungen für Softwarelizenzen sind komplex und unterliegen ebenfalls Änderungen und Interpretationsspielräumen.
Es kann vorkommen, dass zu einem Zeitpunkt der SBOM-Erstellung eine Lizenz falsch eingeschätzt wurde oder sich spätere Rechtsprechungen auf die Nutzung auswirken. Auch Lizenzgeber können ihre Bedingungen anpassen oder rückwirkend Änderungen vornehmen, was zu einer Verschiebung der Compliance-Voraussetzungen führt. Um die rechtliche Sicherheit zu behalten, müssen SBOMs die Lizenzinformationen regelmäßig überprüft und gegebenenfalls angepasst werden. Nicht zu vergessen sind Weiterentwicklungen im Bereich der SBOM-Standards selbst. Beispielsweise erfährt die CycloneDX-Spezifikation als einer der führenden Standards für SBOMs kontinuierliche Updates und Verbesserungen.
Neue Versionen können neue Felder, Datenstrukturen oder Genauigkeiten bei Hash-Algorithmen einführen, die bislang nicht abgedeckt waren. Dadurch wird es nicht nur möglich, mehr Informationen abzubilden, sondern auch bestehende SBOMs zu verfeinern und anzureichern, was wiederum Aktualisierungen erfordert. Dies führt zu einer Art kontinuierlicher Evolution, bei der SBOMs in ihrer Form und ihrem Informationsgehalt ständigen Veränderungen unterliegen. All diese Faktoren machen deutlich, dass ein SBOM nie statisch ist. Deshalb wird das Thema Versionierung bei SBOMs immer zentraler.
Die Herausforderung besteht darin, eine Balance zu finden zwischen Aktualität und Übersichtlichkeit. Wenn jedes Detail zu einer neuen Version führen würde, so käme es zu einer unüberschaubaren Vielzahl von SBOM-Varianten, die schwer zu verwalten und auszuwerten wären. Das sogenannte „Kombinatorische Explosionsproblem“ beschreibt diese Herausforderung treffend. Unternehmen und Entwickler sind somit gefragt, intelligente Lösungen zu entwickeln, die den Umgang mit SBOM-Versionen effizient gestalten. Ein Beispiel hierfür ist die Plattform ReARM von Reliza.
Diese verfolgt einen pragmatischen Ansatz, der sowohl die Original-SBOMs unverändert bewahrt als auch dynamische Anreicherungen ermöglicht. So wird das Originaldokument als Rohfassung erhalten, während die Nutzer optional auf angereicherte und erweiterte Versionen zugreifen können, die beispielsweise aktualisierte Risiko- und Lebenszyklusinformationen enthalten. Diese Aufbewahrung dient der Nachvollziehbarkeit, etwa für Audits oder als Beweis der Existenz zu einem bestimmten Zeitpunkt. Damit werden SBOMs zu lebendigen Dokumenten, die sich parallel zu den Veränderungen in Softwarekomponenten, Bedrohungslagen und Lizenzbedingungen weiterentwickeln können, ohne ihre ursprüngliche Integrität zu verlieren. Dieses Modell unterstützt Unternehmen dabei, Sicherheit und Compliance nachhaltig zu managen, während sie gleichzeitig den Überblick über den Zustand ihrer Softwarebasis behalten.
Die Akzeptanz dieser Dynamik in SBOMs spiegelt den allgemeinen Trend wider, dass Softwareentwicklung und -wartung immer komplexer werden. Die zunehmende Vernetzung von Anwendungen, das Aufkommen von Microservices und die vielfältigen Abhängigkeiten in modernen Software-Stacks erfordern präzise und laufend gepflegte Transparenz. SBOMs stellen eine wesentliche Säule im Rahmen des Software-Supply-Chain-Managements dar und helfen, sowohl Quellcode-Verwaltung, Sicherheitsmanagement als auch rechtliche Anforderungen zu harmonisieren. Zusammenfassend zeigt sich, dass das Konzept der statischen und dynamischen SBOM-Komponenten zwar hilfreich für das Grundverständnis ist, der Realität aber nicht vollumfänglich gerecht wird. Die statische Komponente unterliegt ebenfalls Veränderungen, die durch menschliche Faktoren, technische Weiterentwicklungen und rechtliche Rahmenbedingungen bedingt sind.
Der Umgang mit dieser Realität erfordert neue Ansätze bei der Versionierung und Pflege von SBOMs. Moderne Tools wie ReARM bieten hierfür vielversprechende Lösungsansätze, indem sie Original-SBOMs bewahren und gleichzeitig dynamische, kontextbezogene Aktualisierungen ermöglichen. Damit werden SBOMs zu einem flexiblen Instrument, das sich ständig an neue Anforderungen anpassen lässt und Unternehmen so besser dabei unterstützt, die Software-Transparenz und -Sicherheit in einer sich schnell wandelnden digitalen Welt sicherzustellen. Diese Erkenntnisse sind für Software-Entwickler, Sicherheitsverantwortliche und Compliance-Teams gleichermaßen relevant. Sie schaffen ein Verständnis dafür, dass der Umgang mit SBOMs kein statisches einmaliges Ereignis ist, sondern ein fortlaufender Prozess, der sorgfältige Planung und geeignete Werkzeuge erfordert.
Nur so kann der volle Nutzen von SBOMs realisiert werden, der weit über das bloße Auflisten von Komponenten hinausgeht und letztlich zu mehr Vertrauen und Sicherheit in modernen Software-Ökosystemen führt.
