Der Weg zur erfolgreichen Umsetzung: Integration einer Software Bill of Materials in die Backend-Entwicklung

Die moderne Softwareentwicklung ist durch hohe Komplexität, kurze Veröffentlichungszyklen und den intensiven Einsatz externer Softwarebibliotheken gekennzeichnet. In der Backend-Entwicklung spielen Frameworks, Open-Source-Komponenten und containerbasierte Technologien wie Docker oder Kubernetes eine zentrale Rolle.

Diese Vielfalt an verfügbaren Softwaretechnologien trägt zwar stark zur Effizienz und Skalierbarkeit von Softwarelösungen bei, jedoch entstehen durch den Einsatz auch neue Herausforderungen. So erschwert beispielsweise die steigende Zahl externer Komponenten die Gewährleistung von Aktualität und Sicherheit sowie die Einhaltung von Lizenzbedingungen und die Risikobewertung.

Die Europäische Union hat nun die Sicherheitsanforderungen für Softwareunternehmen verschärft. Mit dem am 30. Dezember 2024 in Kraft getretenen Cyber Resilience Act (CRA) werden ab Dezember 2027 Software Bills of Materials (SBOMs) für alle betroffenen Unternehmen verpflichtend.[1]

Die Verantwortlichen für die Entwicklung stehen somit vor der komplexen Aufgabe, die Kontrolle über die eingesetzten Softwarekomponenten trotz steigender Komplexität zu behalten. In vielen Unternehmen fehlen etablierte Prozesse und Werkzeuge, um dieser Notwendigkeit und der damit verbundenen Verantwortung gerecht zu werden.

Das Risiko ist konkret: Softwareelemente oder Dienste mit veralteten Abhängigkeiten, sicherheitsrelevanten Schwachstellen oder fehlerhaften Lizenzen können in Softwareprojekte einfließen. Dies kann sich verschärfen, wenn die Software in kritischen Bereichen zum Einsatz kommt und die Dokumentation lückenhaft ist. Besonders ausgeprägt ist diese Problematik im Umfeld API-basierter Backend-Anwendungen, bei denen der Einsatz externer Komponenten und automatisierter Build-Prozesse sehr intensiv ist.

Moderne Backend-Anwendungen setzen massiv auf externe Softwarebibliotheken und Open- Source-Komponenten. Diese Abhängigkeit schafft neue Angriffsvektoren. Bei Supply-Chain-Angriffen missbrauchen Angreifer legitime Software-Updates vertrauenswürdiger Anbieter, um Kunden zu kompromittieren (siehe Abbildung 2).

SBOM als Transparentwerkzeug

Die Software-Lieferkette umfasst den gesamten Prozess von der Planung über die Entwicklung und Tests bis hin zur Auslieferung und Wartung einer Software. Da Unternehmen durch den Einsatz externer Komponenten ein gewisses Stück Kontrolle über ihre Software verlieren, birgt jeder Schritt potenzielle IT-Sicherheitsrisiken. Um diese Risiken beherrschbar zu machen, bietet die Software Bill of Materials ein zentrales Werkzeug.

Eine SBOM ist eine strukturierte Auflistung aller Softwarekomponenten, die konkret in einer Softwarelösung enthalten sind. Sie erfasst Informationen wie Herkunft, Version und weitere relevante Metadaten. In einer Software gibt es zwei Arten von Abhängigkeiten: jene, die explizit anhand einer Syntax eingebunden werden und welche, die transitiv eingebunden werden. Diese werden in der Regel durch die explizit definierten Komponenten inkludiert.

Durch die Inklusion beider Arten entsteht eine transparente Übersicht über die Lage der eingebundenen Abhängigkeiten. Abbildung 3 verdeutlicht den systematischen Aufbau einer SBOM. Neben den Abhängigkeiten und Open-Source-Komponenten werden auch organisatorische Informationen wie „Author“ und „Supplier-Name“ dokumentiert [3]. Die Angabe der Versionsdefinition ermöglicht die präzise Identifikation, während Lizenzinformationen rechtliche Klarheit bringen. Eine solche umfassende Dokumentation ist besonders wichtig, wenn Sicherheitslücken auftreten und schnell geklärt werden muss, welche Komponenten betroffen sind.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) unterteilt SBOMs in verschiedene Kategorien.[2] Jede dieser Kategorien ist eine vollwertige Bill of Materials (BOM) mit einer anderen Detailtiefe. Dies kann für bestimmte Zwecke wichtig sein, da zu unterschiedlichen Zeitpunkten ein unterschiedlicher Grad an Informationen benötigt werden. Für die maschinenlesbare Darstellung haben sich Standards wie CycloneDX und SPDX etabliert, die jeweils feste Strukturen für die Informationsdarstellung definieren (siehe Abbildung 3).

Praktische Umsetzung in mittelständischen Unternehmen

Doch wie lässt sich das in der Praxis umsetzen? Dazu entwickelten die Autoren ein Konzept am Beispiel eines mittelständischen Softwaredienstleisters mit etwa 200 Mitarbeitern, der sich auf digitale Lösungen für kleine und mittelständische Betriebe spezialisiert hat. Das Unternehmen führt kontinuierlich verschiedene Softwareprojekte durch – von webbasierten Verwaltungssystemen bis hin zu mobilen Anwendungen für die Auftragsverwaltung.

Aufgrund der heterogenen Kundenbasis mit unterschiedlichen Branchen und Anforderungen entstehen regelmäßig neue Entwicklungsprojekte mit diversen technischen und fachlichen Spezifikationen. Die Projekte umfassen sowohl Frontend- als auch Backend-Entwicklung und erfordern eine strukturierte Projektabwicklung sowie die sichere Integration verschiedener Softwarekomponenten.

Herausforderungen im Abhängigkeitsmanagement

Das Abhängigkeitsmanagement des dargestellten Unternehmens macht die typischen Probleme mittelständischer Betriebe deutlich. Einige Teams haben bereits dynamische Prozesse etabliert, während andere noch immer einen reaktiven Ansatz praktizieren. Hier beginnt die Aktualisierung erst, wenn eine Sicherheitslücke öffentlich wird oder eine neue Version einer kritischen Komponente erscheint, und sie erfolgt ausschließlich manuell.

Das Problem der fehlenden Automatisierung

In der Praxis läuft die Aktualisierung von Software-Abhängigkeiten typischerweise so ab:

Ein Entwickler erhält eine Meldung über eine Sicherheitslücke und führt eine manuelle Analyse durch. Dabei bewertet er die Änderungsrelevanz, prüft mögliche Kompatibilitätskonflikte und schätzt den Implementierungsaufwand ab. Erst dann fällt die Entscheidung, ob eine Aktualisierung durchgeführt wird. Dieser Prozess mag bei kritischen Sicherheitslücken mit hoher Priorität ablaufen, doch hier liegt das fundamentale Problem: Viele Schwachstellen bleiben völlig unbemerkt. Sie erhalten keine öffentliche Aufmerksamkeit, werden nicht automatisch erkannt und bleiben somit eine unkalkulierbare Bedrohung für die Systemsicherheit.

Die unstrukturierte Dokumentation von Entscheidungen verschärft das Problem zusätzlich. Wenn das Team entscheidet, eine Abhängigkeit nicht zu aktualisieren, hinterlässt es lediglich eine kurze Notiz in einem Kommunikationskanal. Detaillierte Begründungen, Risikobewertungen oder systematische Aufbereitungen für zukünftige Referenzen bleiben hingegen aus.

Die Folge ist deutlich erkennbar: Unternehmen verlieren den Überblick über ihre tatsächlich verwendeten Abhängigkeiten und deren Zustand. Mit zunehmender Anzahl externer Softwarekomponenten wird das System nicht nur komplexer, sondern auch undurchsichtiger.

Die neuen Vorgaben der Europäischen Union durch den CRA stellen diese Praxis grundsätzlich infrage. Die Verordnung fordert eine kontinuierliche Aktualisierung von Software – ein Anspruch, den manuelle Prozesse strukturell nicht erfüllen können. Besonders problematisch ist dabei, dass Sicherheitslücken dynamisch sind. Software wird niemals vollständig frei von Schwachstellen sein und das Risiko steigt exponentiell mit der Anzahl verwendeter Abhängigkeiten externer Software.

Die Folgen dieses reaktiven Vorgehens sind messbar: Längere Entwicklungszyklen, höhere Wartungskosten und vor allem ein erheblich gestiegenes IT-Sicherheitsrisiko prägen den Alltag. Was als ressourcenschonende, punktuelle Aktualisierung beginnt, entwickelt sich schnell zu einem kostspieligen Migrationsaufwand, wenn veraltete Abhängigkeiten schließlich doch aktualisiert werden müssen.

Lösungsansatz: Automatisierte SBOM-Integration

Die Lösung besteht in der Automatisierung des Abhängigkeitsmanagements durch die Integration einer SBOM. Aufgrund der hohen Anzahl unterschiedlicher Open-Source-Komponenten in einer Software ist eine manuelle Überprüfung nicht möglich. In diesem Zusammenhang bieten Software-Composition-Analysis-Tools eine effiziente Lösung. Sie prüfen alle Komponenten einschließlich transitiv eingebundener Abhängigkeiten automatisch und unabhängig auf IT-Sicherheitsprobleme und melden diese bei Bedarf an die verantwortlichen Entwickler.

Ein zukunftsfähiges Abhängigkeitsmanagement setzt auf kontinuierliche Überwachung und proaktive Verwaltung. Statt reaktiv auf Sicherheitslücken zu reagieren, werden Abhängigkeiten automatisch überwacht und aktualisiert. Dieser proaktive Prozess erlaubt es, potenzielle Risiken frühzeitig und kontinuierlich zu erkennen. So können Gegenmaßnahmen schneller ergriffen werden, um die Software sicherer zu machen. Darüber hinaus stellt dieser Ansatz einen entscheidenden Baustein zur Erfüllung regulatorischer Anforderungen dar.

SBOM-Integration: Konzeption und Implementierung

Die Integration einer Software Bill of Materials in bestehende Entwicklungsprozesse erfordert eine strukturierte Herangehensweise, die technische und organisatorische Aspekte gleichermaßen berücksichtigt. Während die Notwendigkeit von SBOMs durch regulatorische Anforderungen wie den CRA immer deutlicher wird, zeigt sich in der Praxis oft eine Kluft zwischen Theorie und Umsetzung.

Rahmenbedingungen

Für die Umsetzung eines Projekts, das eine SBOM-Definition darstellt, sind verschiedene Voraussetzungen zu erfüllen, die für eine spätere Integration maßgeblich sind. Zunächst müssen alle Abhängigkeiten, welche inkludiert werden sollen, vollständig bekannt sein.

Darüber hinaus ist sicherzustellen, dass diese Software-Bibliotheken für eine festgelegte Java-Version verfügbar sind, da Inkompatibilitäten andernfalls zu Problemen bei der Nutzung führen können. Ebenso ist ein konsistentes Schema für die Versionierung erforderlich, um die Nachvollziehbarkeit und Wartbarkeit zu gewährleisten. Zusätzlich muss die erzeugte BOM in einem unternehmensinternen Artefakt-Repository veröffentlicht werden, sodass sie zentral zur Verfügung steht. Schließlich sollte die Projektstruktur den Konventionen eines üblichen Entwicklungsprojektes folgen, um eine reibungslose Einbindung zu ermöglichen.

Zentrale SBOM-Definition

Der erste Schritt ist die Erstellung einer Software Bill of Materials in einem separaten Repository auf der genutzten Codeverwaltungsplattform. Da es sich um eine BOM handelt, die in der Entwicklung zum Einsatz kommen soll, muss eine Source-SBOM erstellt werden. Diese wird über eine Build-Konfiguration generiert und beinhaltet alle verwendeten Abhängigkeiten.

Dadurch gibt es eine zentrale Referenz, auf die alle Projekte zugreifen können, ohne die Version manuell definieren und inkludieren zu müssen. So können Inkonsistenzen zwischen den Projekten vermieden werden. Darüber hinaus ist es möglich, andere Versionen zu nutzen, wenn dies erforderlich ist.

Die Grundlage einer effektiven SBOM-Implementierung bildet die zentrale Verwaltung aller Software-Abhängigkeiten. Anstatt Software-Bibliotheken dezentral in einzelnen Modulen zu definieren, wird ein zentraler Versionskatalog etabliert. Die Konfiguration erfolgt über spezielle Projektdateien, die sowohl den Versionskatalog als auch die Plattformkonfiguration und Veröffentlichungsschritte definieren. Alle definierten Abhängigkeiten können dann über einheitliche Referenzen in die eigentliche SBOM eingebunden werden. Diese zentrale Struktur gewährleistet Konsistenz und erleichtert die Wartung erheblich.

Automatisierte Aktualisierung und Dependency-Updates

Ein kritischer Punkt stellt die Automatisierung von Abhängigkeits-Updates dar. Die kontinuierliche Aktualisierung von Software-Abhängigkeiten ist eine zentrale Herausforderung moderner Entwicklung.

Tools wie Renovate [4] können diesen Prozess automatisieren, müssen jedoch entsprechend konfiguriert werden. Die Kernaufgabe besteht darin, die Abhängigkeiten kontinuierlich zu analysieren und auf Aktualisierungen zu prüfen.

Sobald eine neue Version erkannt wird, erstellt das Tool automatisch einen Pull Request auf der Code-Verwaltungsplattform. Entwickler können diese Änderungen prüfen und freigeben, ohne manuell nach Updates zu suchen. Dies beschleunigt die Reaktion auf sicherheitsrelevante Schwachstellen erheblich. Nach der Einrichtung können Sicherheitspatches automatisch integriert werden, während größere Updates den bewährten Review-Prozess durchlaufen.

Diese Automatisierung ist für SBOM-Implementierungen besonders wertvoll, da sie sicherstellt, dass dokumentierte Abhängigkeiten nicht nur vollständig, sondern auch aktuell bleiben. Dies
ist eine Grundvoraussetzung für regulatorische Compliance. Eine minimale Konfiguration demonstriert, wie unkompliziert sich dieser Prozess implementieren lässt (siehe Abbildung 4).

Die dargestellte Konfiguration aktiviert automatisch bewährte Regeln für Sicherheitsupdates, während das Labeling eine klare Nachverfolgbarkeit für Compliance-Zwecke gewährleistet. Durch die automatische Aktualisierung bleiben sowohl die tatsächlichen Abhängigkeiten als auch deren Dokumentation im SBOMs synchron. Je nach Tool lassen sich weitere Schritte konfigurieren, um beispielsweise die Freigabe von Updates zu automatisieren.

Zentrale Bereitstellung der BOM

Um eine breite Konsistenz zu erreichen, ist eine zentrale Bereitstellung von SBOM unerlässlich. Unternehmen veröffentlichen ihre SBOM in der Regel über zentrale Repository-Systeme, die bereits für die Verteilung anderer Software-Artefakte genutzt werden. Dies lässt sich über ein firmeninternes Repository lösen, das über eine Plattform wie Azure oder Alternativen bereitgestellt ist.

Dabei wird die SBOM wie ein reguläres Software-Paket behandelt und durchläuft dieselben Veröffentlichungsprozesse. Diese Integration in bestehende Infrastrukturen minimiert den zusätzlichen Aufwand und gewährleistet eine konsistente Handhabung. So können alle Teams auf dieselbe Grundlage zugreifen und erhalten eine solide und aktuelle Versionsdefinitionsbasis.

Die zentrale Verfügbarkeit ermöglicht es verschiedenen Stakeholdern, von Entwicklungsteams über Security-Verantwortliche bis hin zu Compliance-Teams auf die aktuellen SBOM-Informationen zuzugreifen. Diese Zentralisierung vereinfacht nicht nur die Qualitätssicherung, sondern ermöglicht auch eine skalierbare Umsetzung in größeren Organisationen. Dies schafft die notwendige Transparenz für fundierte Entscheidungen bezüglich Sicherheit, Lizenzkonformität und Abhängigkeitsmanagement.

Fazit

Die Integration einer Software Bill of Materials in bestehende Entwicklungsprozesse ist machbar und bringt erheblichen Mehrwert: mehr Transparenz, höhere IT-Sicherheit, effizienteres Abhängigkeitsmanagement und bessere Compliance. Besonders der Einsatz automatisierter Tools reduziert den manuellen Aufwand und sorgt für zeitnahe Updates. So entstehen Freiräume für qualitätsfördernde Aufgaben wie Code-Reviews, Tests oder Architekturverbesserungen – ein klarer Beitrag zur Softwarequalität.

Ein weiterer Erfolgsfaktor ist die projektübergreifende Wiederverwendung. Sie gelingt nur mit einheitlichen Standards; andernfalls steigt der Anpassungsaufwand. Aus betriebswirtschaftlicher Sicht amortisieren sich die Implementierungskosten durch eingesparte Wartungszeit und eine gestärkte Compliance. Insgesamt ist die SBOM-Integration weit mehr als ein Compliance-Thema: Sie ist eine Investition in eine nachhaltige, transparente und wartbare Software-Architektur.

Literatur

[1] Europäische Union: Cyber Resilience Act (CRA), https://it-sicherheit.de/ratgeber/it-sicherheitsgesetze/cra/
[2] Bundesamt für Sicherheit in der Informationstechnik (BSI): Technische Richtlinie BSI-TR-03183-2, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03183/BSI-TR-03183-2.pdf?__blob=publicationFile&v=6
[3] Scribe Security: What is a Software Bill of Materials (SBOM), https://scribesecurity.com/sbom/#definition-of-software-bill-of-materials
[4] Mend (Renovate): Renovate Documentation, https://docs.renovatebot.com/