SBOMs als primärer Compliance-Mechanismus

Der zunehmende Fokus der Europäischen Union auf Software Bills of Materials (SBOMs), zuletzt sichtbar im ENISA-Bericht SBOM Landscape Analysis – Towards an Implementation Guide, stellt einen wichtigen und begrüßenswerten Schritt hin zu mehr Transparenz und Resilienz in Software-Lieferketten dar. SBOMs entwickeln sich rasch zu einem zentralen Baustein der Cybersicherheits-Governance im Rahmen des Cyber Resilience Act (CRA) und verwandter Regelwerke.

Aus Sicht von Bitsea ist diese Entwicklung sowohl notwendig als auch überfällig. SBOMs schaffen eine gemeinsame, faktenbasierte Grundlage, um zu verstehen, aus welchen Bestandteilen Softwareprodukte bestehen, wie Abhängigkeiten strukturiert sind und wo Sicherheits- oder Compliance-Risiken entstehen können. Richtig umgesetzt ermöglichen SBOMs schnellere Bewertungen der Auswirkungen von Schwachstellen, eine effektivere Incident Response sowie eine klarere Kommunikation über technische, rechtliche und organisatorische Grenzen hinweg. Darüber hinaus bieten sie Aufsichtsbehörden und Kunden eine konkrete Möglichkeit zu beurteilen, ob ein Unternehmen tatsächlich Kontrolle über seine Softwarelandschaft ausübt.

Gleichzeitig hat Bitsea ENISA Rückmeldungen gegeben, in denen praxisrelevante Aspekte hervorgehoben werden, die entscheidend für eine wirksame SBOM-Umsetzung sind.

Vom der konzeptionellen SBOM zur praktisch nutzbaren Lösung

Eine zentrale Beobachtung ist, dass SBOMs häufig auf sehr abstrakter Ebene beschrieben werden und sich primär auf vollständige Softwarekomponenten oder Pakete konzentrieren. In der Praxis moderner Softwareentwicklung kommt teilweise Code-Wiederverwendung häufig vor, etwa durch einzelne Dateien, Verzeichnisse oder Codefragmente aus größeren Projekten.

Diese Form der Wiederverwendung hat unmittelbare Auswirkungen auf Lizenzierung, Urheberrecht und Sicherheitsrisiken. Eine praktisch nutzbare SBOM sollte daher partielle Komponenten und feinkörnige Wiederverwendung abbilden, statt immer vollständige, versionierte Pakete vorauszusetzen.

Eng damit verbunden ist die weit verbreitete informelle Wiederverwendung von Codeschnipseln, beispielsweise aus öffentlichen Foren oder Wissensplattformen. Solche Schnipsel können urheberrechtlich geschützt sein, Lizenzpflichten nach sich ziehen oder bekannte Schwachstellen enthalten. Auch wenn diese Art der Wiederverwendung selten aus bewusster Missachtung der Compliance entsteht, stellt sie ein reales und wiederkehrendes Risiko dar. Bitsea hat daher darauf hingewiesen, dass SBOM-Leitlinien diese Realität explizit anerkennen und Organisationen dazu anregen sollten, sie in ihre Softwareinventare und Compliance-Prozesse einzubeziehen.

Über den Quellcode hinaus: Berücksichtigung von Nicht-Code-Artefakten

Ein weiterer wichtiger Aspekt ist, dass Softwareprodukte in der Regel nicht nur aus Quellcode bestehen. Dokumentation, Konfigurationsdateien, Bilder, Schriftarten, Medieninhalte und andere Nicht-Code-Artefakte werden häufig als Teil von Softwaredistributionen ausgeliefert. Diese Elemente unterliegen oft eigenen Lizenz- und Schutzrechtsregelungen und können sowohl rechtliche als auch operative Risiken mit sich bringen.

Bitsea empfiehlt daher, die SBOM-Diskussion über den Fokus auf Quellcode hinaus zu erweitern und diese zusätzlichen Artefakttypen ausdrücklich als Teil der Software Bill of Materials anzuerkennen. Ein typisches Beispiel für ein solches Nicht-Code-Artefakt ist die Einbindung einer Open-Source-Schriftart in eine Anwendung, ein Firmware-Image oder ein Dokumentationspaket. Viele verbreitete Schriftarten stehen unter der SIL Open Font License (OFL), die Einbettung, Modifikation und Weiterverbreitung erlaubt, jedoch bestimmte Bedingungen stellt, etwa die Beibehaltung von Copyright-Hinweisen und Einschränkungen bei der Verwendung reservierter Schriftartnamen.

KI-generierter Code

Der ENISA-Bericht sieht KI-generierten Code als Herausforderung an, doch aus Sicht von Bitsea sollte dieses Thema stärker betont werden. In der Praxis ist KI-gestützte Softwareentwicklung bereits ein wesentlicher Faktor in vielen Codebasen. KI-generierte Ergebnisse können bestehenden Open-Source-Komponenten sehr ähnlich sein, teilweise ohne klare Attribution oder eindeutig identifizierbaren Lizenzkontext. Daraus ergeben sich neue Fragestellungen hinsichtlich Herkunft, Compliance und Risikoverteilung. Mindestens sollten SBOM-Leitlinien auf diese Risiken aufmerksam machen und Maßnahmen zur Identifikation und zum Umgang mit KI-unterstütztem oder KI-generiertem Code in SBOM-basierten Prozessen empfehlen.

SBOMs und Lizenz-Compliance: Fundament, kein Ersatz

SBOMs sind als grundlegende Datenstrukturen zu verstehen, nicht als Ersatz für bestehende Compliance-Pflichten. Zwar kann eine SBOM präzise abbilden, welche Komponenten und Lizenzen enthalten sind, die meisten Open-Source-Lizenzen verlangen jedoch weiterhin menschenlesbare Hinweise, Namensnennungen und – sofern zutreffend – den Zugang zum Quellcode (Complete Corresponding Source, CCS). In der Praxis entfalten SBOMs ihren größten Nutzen, wenn sie als maßgebliches Inventarliste dienen, aus dem konforme Hinweise und Offenlegungen automatisiert oder teilautomatisiert erzeugt werden.

Über Sicherheit hinaus: SBOMs müssen auch Lizenzpflichten berücksichtigen

Der ENISA-Bericht erkennt zu Recht an, dass der Zweck einer SBOM auch die Lizenz-Compliance umfasst. Der CRA betont jedoch die Rolle von SBOMs vor allem im Kontext von Schwachstellenverfolgung, Risikominderung und Sicherheitsupdates und zeigt damit nur eine Dimension ihres Nutzens. In der Praxis erfasst eine vollständige und korrekte SBOM auch die rechtlichen Metadaten jeder einzelnen Komponente – insbesondere die Lizenz(en), unter denen sie genutzt wird.

Diese weiter gefasste Interpretation entspricht nicht nur der gängigen Industrie-Praxis (wie sie durch Standards wie SPDX, CycloneDX und OpenChain ISO/IEC 5230 definiert ist), sondern ist auch unerlässlich, um weitere rechtliche und vertragliche Verpflichtungen zu erfüllen, darunter:

• Lizenz-Attribution und Einhaltung von Hinweispflichten
• Copyleft-Lizenzpflichten, einschließlich Auslösern zur Quellcode-Offenlegung
• Kommerzielle und IP-Due-Diligence-Prüfungen in Lieferanten-, Kunden- und M&A-KontextenIn

Kurz gesagt: Lizenz-Compliance und Schwachstellenmanagement sind zwei Seiten derselben SBOM-Medaille.

Aus Compliance- und Betriebssicht bedeutet dies, dass Organisationen, die SBOMs zur Erfüllung der CRA-Anforderungen erstellen, Lizenzdaten nicht als optional oder nachrangig betrachten sollten. Im Gegenteil: Eine unzureichende Erfassung von Lizenzpflichten in der SBOM kann erhebliche rechtliche Risiken nach sich ziehen – insbesondere in komplexen Lieferketten oder regulierten Branchen.

Der ENISA-Bericht weist zudem darauf hin, dass in bestimmten regulierten Kontexten, etwa bei exportkontrollierten, klassifizierten oder sicherheitskritischen Systemen, eine vollständige Offenlegung der SBOM rechtlich oder operativ nicht möglich sein kann. Dies mindert jedoch nicht den Wert von SBOMs als internes Compliance- und Risikomanagement-Instrument, sondern unterstreicht vielmehr die Notwendigkeit kontrollierter, zielgruppenspezifischer SBOM-Praktiken, die Transparenz mit regulatorischen Einschränkungen in Einklang bringen.

Ausblick

Keine dieser Überlegungen stellt den Wert von SBOMs infrage. Im Gegenteil: Sie verdeutlichen, warum SBOMs als lebendige Dokumente verstanden werden müssen, die sich parallel zu Echtzeit-Entwicklungspraktiken weiterentwickeln. ENISAs Initiative zur Bereitstellung von Umsetzungsleitlinien ist ein entscheidender Schritt zur Harmonisierung in Europa – insbesondere für Organisationen mit begrenzten Ressourcen.

Bitsea begrüßt diese Initiative und hat entsprechendes Feedback eingebracht. SBOMs sind kein Selbstzweck, sondern eine wesentliche Voraussetzung für eine wirksame Governance von Software-Lieferketten im Rahmen des CRA und darüber hinaus. Wenn Organisationen SBOMs mit ausreichender Detailliertheit gestalten und in umfassende Sicherheits- und Compliance-Workflows integrieren, verwandeln sie Software von einem intransparenten Betriebsrisiko in ein transparentes, beherrschbares und strategisch gesteuertes Asset.

Bei Bitsea konzentriert sich unsere Arbeit genau auf diese Schnittstelle: die Analyse von SBOMs und Abhängigkeitsdaten, die Prüfung von Open-Source- und Build-Artefakten sowie die Unterstützung von Organisationen bei der operativen Umsetzung regulatorischer Anforderungen in nachhaltige Engineering- und Compliance-Prozesse.