ENISA-Leitlinien zur SBOM: Orientierung für Hersteller zur CRA-Umsetzung

Eine Software Bill of Materials (SBOM), auch Software-Stückliste genannt, ist eine strukturierte Aufstellung der Softwarekomponenten, aus denen ein Produkt besteht. 

Vergleichbar mit einer klassischen Stückliste im Maschinenbau dokumentiert eine SBOM die Bestandteile eines Produkts. Während eine herkömmliche Stückliste beispielsweise mechanische und elektrische Bauteile erfasst, beschreibt die SBOM die enthaltenen Softwarekomponenten und deren Abhängigkeiten. 

Dazu können beispielsweise folgende Informationen gehören: 

• Name und Version einer Softwarekomponente 
• Hersteller oder Anbieter der Komponente 
• Abhängigkeiten von weiteren Softwarekomponenten
• Verwendete Open-Source-Bibliotheken
• Lizenzinformationen
• Eindeutige Komponentenkennungen

Mithilfe einer SBOM können Hersteller gezielt prüfen, ob und welche Produkte mit welcher Softwareversion von einer bekannt gewordenen Sicherheitslücke betroffen sein könnten. 

Ein Maschinenhersteller integriert beispielsweise verschiedene Softwarebibliotheken und Komponenten von Drittanbietern in die Steuerung einer Produktionsmaschine. Mithilfe der SBOM kann der Hersteller sowohl während der Entwicklung (Secure by Design) als auch bei bereits eingesetzten Systemen (Schwachstellenmanagement) überprüfen, ob die eingesetzten Bibliotheken bekannte Sicherheitslücken aufweisen, und betroffene Komponenten frühzeitig aktualisieren oder ersetzen.
 

Der Cyber Resilience Act (EU) 2024/2847 legt verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest. Gemäß Artikel 13 in Verbindung mit Anhang I Teil II Nummer 1 müssen Hersteller Schwachstellen und Komponenten ihrer Produkte identifizieren und dokumentieren. Dazu gehört die Erstellung einer Software Bill of Materials in einem gängigen, maschinenlesbaren Format. Hierfür nennt das Technical Advisory zwei Beispiele, die weiter unten aufgeführt sind.

Der CRA verlangt dabei zumindest die Erfassung der obersten Abhängigkeitsebene (Top-Level Dependencies). Eine vollständige Auflösung sämtlicher indirekter Softwareabhängigkeiten ist damit nicht generell als gesetzliche Mindestanforderung festgelegt. 

Die SBOM ist Teil der technischen Dokumentation des Produkts. Hersteller müssen diese Informationen grundsätzlich nicht öffentlich bereitstellen. Zuständige Marktüberwachungsbehörden können jedoch im Rahmen ihrer Befugnisse entsprechende Informationen anfordern. Die Anforderungen an die Behandlung von Schwachstellen gemäß Anhang I Teil II gelten grundsätzlich ab dem 11. Dezember 2027. Hersteller sollten sich jedoch bereits jetzt mit der Einführung geeigneter Prozesse beschäftigen.
 

Der CRA gilt nicht nur für reine Softwareprodukte, sondern grundsätzlich auch für Hardwareprodukte mit digitalen Elementen, sofern diese in den Anwendungsbereich der Verordnung fallen. Damit sind die Anforderungen an die Software Bill of Materials (SBOM) auch für Hersteller relevant, die Software in ihre Maschinen, Anlagen oder Geräte integrieren. 

Zu den betroffenen Produktgruppen können beispielsweise Maschinen und Produktionsanlagen mit vernetzten Steuerungen, industrielle Automatisierungssysteme, IoT-Geräte und vernetzte Sensoren sowie elektronische Steuerungen und Betriebsmittel gehören. Auch eigenständige Softwareprodukte und Anwendungen fallen grundsätzlich in den Anwendungsbereich des CRA. 

Insbesondere im Maschinen- und Anlagenbau werden häufig unterschiedliche Softwarekomponenten miteinander kombiniert. Neben selbst entwickelter Software kommen beispielsweise Betriebssysteme, Kommunikationsbibliotheken oder Open-Source-Komponenten von Drittanbietern zum Einsatz. 

Für Hersteller ist es daher wichtig, den Überblick über die eingesetzten Softwarebestandteile und deren Abhängigkeiten zu behalten. Eine SBOM schafft hierfür die notwendige Transparenz und unterstützt dabei, bekannte Sicherheitslücken zu identifizieren und mögliche Risiken gezielt zu bewerten.

Hersteller sollten deshalb geeignete Prozesse etablieren, um Softwarekomponenten systematisch zu erfassen, nachvollziehbar zu dokumentieren und die entsprechenden Informationen über den Produktlebenszyklus hinweg aktuell zu halten.
 

Die Orientierungshilfe „Technical Advisory for Software Bill of Materials“ richtet sich insbesondere an kleine und mittlere Unternehmen sowie Organisationen, die erstmals systematische SBOM-Prozesse einführen möchten. Im Mittelpunkt stehen dabei die folgenden Themen: 

1. Aufbau und Lebenszyklus einer SBOM: Die ENISA beschreibt, wie SBOM-Informationen während der Softwareentwicklung erzeugt, geprüft, gespeichert, genutzt und aktualisiert werden können. Eine weitgehend automatisierte Erstellung kann dazu beitragen, Fehler zu vermeiden und die Dokumentation bei Softwareänderungen aktuell zu halten. 

2. Sicherheitsrisiken beim Umgang mit SBOM-Daten: Auch die SBOM selbst muss geschützt werden. Werden beispielsweise Komponenteninformationen manipuliert oder unberechtigt verändert, können darauf aufbauende Sicherheitsbewertungen fehlerhaft sein. Das Dokument behandelt deshalb mögliche Bedrohungen für die Erstellung, Speicherung und Weitergabe von SBOM-Daten. 

3. Technische und organisatorische Schutzmaßnahmen: Die Veröffentlichung beschreibt Maßnahmen zur Absicherung des SBOM-Lebenszyklus. Dazu gehören beispielsweise Zugriffskontrollen, Integritätsprüfungen und die sichere Verwaltung der erstellten Dokumente. Die ENISA-Veröffentlichung stellt eine technische Orientierungshilfe dar. Sie schafft keine zusätzlichen gesetzlichen Pflichten über die Anforderungen des CRA hinaus.

Die ENISA-Veröffentlichung betrachtet damit nicht nur die Erstellung einer Software-Stückliste, sondern auch deren sichere Verwaltung und Nutzung. Hersteller erhalten eine technische Orientierung, wie sie SBOM-Prozesse strukturiert aufbauen und mögliche Sicherheitsrisiken beim Umgang mit den Daten berücksichtigen können.

Den vollständigen ENISA-Leitfaden können Sie über den folgenden Link aufrufen und herunterladen

ENISA Technical Advisory for Software Bill of Materials
 

Damit Software-Stücklisten automatisiert erstellt und verarbeitet werden können, haben sich standardisierte Austauschformate etabliert. Zu den bekanntesten Formaten gehören: 

• CycloneDX: Ein insbesondere auf Software-Lieferketten und Sicherheitsanwendungen ausgerichtetes SBOM-Format 
• SPDX (Software Package Data Exchange): Ein international verbreiteter Standard zur Beschreibung von Softwarekomponenten, Lizenzen und Abhängigkeiten. 

Beide Formate ermöglichen die strukturierte Verarbeitung von Softwarekomponenteninformationen. Weitere technische Hinweise enthält die Richtlinie BSI TR-03183 Teil 2 „Software Bill of Materials (SBOM)“ des deutschen Bundesamtes für Sicherheit in der Informationstechnik. Sie konkretisiert unter anderem Anforderungen an Datenfelder, Komponenteninformationen und die Struktur von Software-Stücklisten. 

Wichtig ist dabei die Unterscheidung zwischen gesetzlichen Anforderungen und technischen Spezifikationen: Die BSI-Richtlinie bietet eine wertvolle Orientierung für die Umsetzung, ist jedoch nicht automatisch eine verbindliche harmonisierte Norm zum CRA.
 

Für Hersteller empfiehlt es sich, SBOM-Prozesse frühzeitig in die bestehenden Entwicklungs- und Dokumentationsabläufe zu integrieren. Dabei sind insbesondere folgende Schritte sinnvoll: 

1. Softwarekomponenten erfassen: Zunächst sollte geklärt werden, welche Softwarebestandteile in den jeweiligen Produkten eingesetzt werden. Dazu gehören sowohl selbst entwickelte Komponenten als auch Software von Drittanbietern. 

2. Geeignetes SBOM-Format auswählen: Hersteller sollten prüfen, welches standardisierte Austauschformat sich für ihre Entwicklungsumgebung und ihre bestehenden Prozesse eignet.

3. Erstellung möglichst automatisieren: Bei der Softwareentwicklung können geeignete Werkzeuge eingesetzt werden, um Software-Stücklisten automatisiert zu erzeugen und zu aktualisieren.

4. SBOM in das Schwachstellenmanagement integrieren: Die dokumentierten Softwarekomponenten sollten mit Informationen über bekannte Sicherheitslücken abgeglichen werden können.

5. Dokumentation und Aktualisierung sicherstellen: Bei Änderungen an Softwarekomponenten müssen die zugehörigen Informationen nachvollziehbar gepflegt werden. Dazu sind geeignete Verantwortlichkeiten und Abläufe festzulegen. Die SBOM sollte dabei nicht als isoliertes Dokument betrachtet werden, sondern als Bestandteil eines umfassenden Prozesses zur Gewährleistung der Cybersicherheit von Produkten.