Integration einer Software Bill of Materials in die Backend-Entwicklung - Prof. Dr. Norbert Pohlmann
Integration einer Software Bill of Materials in die Backend-Entwicklung | |
![]() | Prof. Norbert Pohlmann (Institut für Internet-Sicherheit), S. Wonning Der Cyber Resilience Act der Eu macht Software Bills of Materials ab 2027 verpflichtend. Unsere Autoren zeigen, wie mittelständische Unternehmen diese Transparenzanforderung in der Backend-Entwicklung umsetzen können. 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 beispielweise die steigende Zahl externer Komponenten die Gewährleistung 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. Die Verantwortlichen für die Entwicklung stehen somit vor der komplexen Aufgabe, die Kontrole ü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 intersiv ist. Moderne Backend-Anwendungen setzten 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. SBOM als Transparenzwerkzeug 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 Matedaten. 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änigkeiten. Abbildung 3 verdeutlicht den systematischen Aufbau einer SBOM. Neben den Abhängingkeiten und Open-Source-Komponenten werden auch organisatorische Informationen wie “Autor” und “Supplier-Name” dokumentiert. 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. … kostenlos downloaden
|
![]() | |




