Die Software-Stückliste gilt vielen als der große Brocken im Cyber Resilience Act. Man stellt sich einen aufwendigen Scan vor, ein teures Tool, eine endlose Liste. Schaut man aber genau in die Verordnung, verlangt sie an dieser Stelle weniger, als die Diskussion vermuten lässt. Die eigentliche Schwierigkeit liegt nicht im Erstellen der Liste, sondern davor: im sauberen Umgang mit den Komponenten, die Sie überhaupt erst in Ihr Produkt aufnehmen.
Eine SBOM (Software Bill of Materials, deutsch Software-Stückliste) ist nach dem CRA eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts enthalten sind. Die Verordnung verlangt vom Hersteller, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem durch Erstellung einer SBOM in einem maschinenlesbaren Format, aus der zumindest die erste Ebene Abhängigkeiten hervorgehen. Sie ist Teil der (internen) technischen Dokumentation, kein Dokument für die Öffentlichkeit.
Der CRA fordert die SBOM an einer einzigen, klar umrissenen Stelle. Anhang I Teil II Nummer 1 verlangt, dass Hersteller Schwachstellen und Komponenten ermitteln und dokumentieren, und nennt die SBOM als das Mittel dafür. Zwei Anforderungen sind dabei entscheidend, und beide sind enger gefasst, als oft angenommen wird.
Erstens das Format: ein gängiges maschinenlesbares Format. In der Praxis verbreitete Formate wie CycloneDX oder SPDX erfüllen das. Welche genauen Felder und Elemente eine CRA-konforme SBOM enthalten muss, ist allerdings noch nicht abschließend festgelegt. Die Kommission wird das Format und die Elemente der Software-Stückliste per Durchführungsrechtsakt bestimmen. Bis dahin gilt die offene Vorgabe des Anhangs.
Zweitens die Tiefe: Aus der SBOM müssen zumindest die obersten Abhängigkeiten hervorgehen. Eine lückenlose Auflösung jeder transitiven Abhängigkeit bis in die letzte Verschachtelung verlangt die Verordnung an dieser Stelle nicht. Das ist eine wichtige Entlastung: Wer die oberste Ebene seiner Komponenten sauber kennt, erfüllt die gesetzliche Mindesttiefe.
Die SBOM steht außerdem nicht für sich allein. Sie gehört in die technische Dokumentation, die der Hersteller ohnehin erstellen muss. Sie ist damit ein Baustein der Schwachstellenbehandlung, nicht ein isoliertes Zusatzdokument.
Müssen Sie die SBOM Ihren Kunden offenlegen?
Nein. Diese Frage sorgt für viel Unsicherheit, dabei ist die Antwort der Verordnung eindeutig. Hersteller sollen feststellen und dokumentieren, welche Komponenten enthalten sind. Eine Pflicht zur Veröffentlichung der Software-Stückliste besteht ausdrücklich nicht.
Wer die SBOM zu sehen bekommt, hängt davon ab, wer fragt:
| Wer | Bekommt die SBOM zu sehen? |
|---|---|
| Marktüberwachungsbehörde | auf begründetes Verlangen, soweit für die Konformitätsprüfung erforderlich |
| Kunde / Nutzer | nein, keine Herausgabepflicht |
| Öffentlichkeit | nein, keine Veröffentlichungspflicht |
Gegenüber der Marktüberwachungsbehörde gilt eine Vorlage auf Anforderung: Auf begründetes Verlangen legt der Hersteller die SBOM vor, sofern dies erforderlich ist, damit die Behörde die Einhaltung der Anforderungen überprüfen kann. Auch im Rahmen einer gemeinsamen Abhängigkeitsbewertung der Union können Marktüberwachungsbehörden die SBOM anfordern. Die Vertraulichkeit bleibt dabei gewahrt: Informationen über Abhängigkeiten werden nur anonymisiert und aggregiert weitergegeben.
Gegenüber dem Nutzer gibt es keine Herausgabepflicht. Die Informationspflichten verlangen lediglich, den Ort anzugeben, an dem die SBOM zugänglich ist, falls der Hersteller sie dem Nutzer überhaupt zur Verfügung stellt. Ob Sie die SBOM also an Kunden weitergeben, bleibt Ihre Entscheidung. Verpflichtet sind Sie dazu nicht.
Die SBOM ist damit zunächst ein internes Werkzeug für die technische Dokumentation und die eigene Schwachstellenbehandlung. Das verschiebt den Blick weg von der Frage „Wie zeige ich sie her?“ hin zur eigentlich relevanten Frage: Wie kommt eine belastbare Liste überhaupt zustande?
Warum das Erstellen nicht die eigentliche Hürde ist
Hier kommt unsere Kernthese, und sie ist bewusst eine Praxiseinschätzung, kein Normtext: Das Erstellen der SBOM ist nicht die eigentliche Hürde, wenn die Entwicklung sauber strukturiert ist. Wer beim Bauen seines Produkts ohnehin weiß, welche Bibliotheken, Module und zugekauften Bausteine er verwendet, hat die oberste Abhängigkeitsebene faktisch schon im Kopf und meist auch in seinen Build-Dateien. Die SBOM gießt dieses Wissen nur in ein maschinenlesbares Format.
Eng wird es genau dort, wo dieses Wissen über die eigenen Komponenten lückenhaft ist. Wer Bausteine integriert, ohne festzuhalten, woher sie stammen, in welcher Version sie vorliegen und wer sie pflegt, dem hilft auch das beste Tool nur begrenzt. Ein Scanner kann nachträglich vieles aufdecken, aber er ersetzt nicht die Entscheidung, die vor der Aufnahme einer Komponente getroffen werden muss.
Genau deshalb verschiebt sich aus unserer Sicht der Aufwand an eine andere Stelle im Entwicklungsprozess: nach vorne, an den Punkt, an dem Sie eine Komponente auswählen und bewerten. Dort entsteht die Substanz der späteren Liste.
Die Komponentenliste entsteht beim Sourcing, nicht am Ende
Unsere Praxisempfehlung lautet: Nehmen Sie jede Software-Komponente schon beim Sourcing in ein Inventar auf, statt am Ende der Entwicklung rückwirkend zu rekonstruieren, was alles verbaut wurde. Die SBOM ist dann kein eigenes Projekt mehr, sondern ein Nebenprodukt eines geordneten Komponentenmanagements.
Dieses Vorgehen deckt sich mit einer Pflicht, die der CRA klar formuliert. Wer von Dritten bezogene Komponenten in sein Produkt integriert, muss die gebotene Sorgfalt walten lassen, damit diese Komponenten die Cybersicherheit des Gesamtprodukts nicht beeinträchtigen. Das gilt ausdrücklich auch für freie und quelloffene Software. Was diese Sorgfalt konkret bedeutet, beschreibt der CRA wie folgt: die Konformität der Komponente prüfen (einschließlich CE-Kennzeichnung, soweit der CRA gilt), darauf achten, dass die Komponente regelmäßige Sicherheitsaktualisierungen erhält, einschlägige Schwachstellendatenbanken konsultieren oder zusätzliche Sicherheitsprüfungen durchführen.
Daraus ziehen wir eine Vorgehensempfehlung: Bewerten Sie eine Komponente, bevor Sie sie aufnehmen, nicht erst nachträglich, wenn ein Tool sie meldet. Eine Bibliothek ohne Update-Historie, eine Komponente mit offenen Einträgen in einer Schwachstellendatenbank oder ein Baustein ohne klaren Maintainer ist eine Entscheidung, die am besten vor der Integration fällt. Wer so arbeitet, sammelt nebenbei genau die Angaben, aus denen die SBOM später besteht: Name, Version, Herkunft, Pflegezustand. Für den strukturellen Rahmen eines solchen Vorgehens bietet die BSI TR-03185 zum sicheren Software-Lebenszyklus eine gute Orientierung. Den Sonderfall freier und quelloffener Software behandeln wir vertieft unter CRA und Open-Source-Software.
Wo stehen Tools im V-Modell? Rechts.
Werkzeuge zur Software-Composition-Analysis haben ihren Platz, aber er liegt nicht am Anfang. Aus unserer Sicht stehen Tools im V-Modell rechts: Sie validieren die Komponentenliste, sie erzeugen sie nicht. Die Liste entsteht auf dem linken, planenden Ast, wenn Sie Anforderungen festlegen, Komponenten beschaffen und vor der Integration bewerten. Auf dem rechten, prüfenden Ast gleicht ein Scanner dann das tatsächlich Gebaute gegen diese Liste ab und deckt Abweichungen auf.
Diese Reihenfolge ist mehr als eine Formalie. Wer das Tool zuerst laufen lässt und die Treffer für die Liste hält, übernimmt ungeprüft, was zufällig im Code gelandet ist. Wer dagegen erst bewertet und dann scannt, nutzt das Tool als Kontrolle einer bewussten Entscheidung.
Was Scanner nicht sehen: Firmware-Versionen und kommerzielle Dritt-Komponenten
Tools haben blinde Flecken, und die sollten Sie kennen, bevor Sie sich auf einen Scan verlassen. In der Praxis erkennen Scanner und SCA-Werkzeuge Open-Source-Pakete zuverlässig, weil deren Metadaten offen vorliegen und gut katalogisiert sind. Bei kommerziellen Dritt-Komponenten und konkreten Firmware-Versionen bleiben sie dagegen häufig blind. Diese Angaben stehen nicht im durchsuchbaren Code, sondern in den Unterlagen des Lieferanten. Sie müssen aus den Lieferantenangaben manuell ins Inventar.
| Was Tools zuverlässig erkennen | Was manuell ins Inventar muss |
|---|---|
| Open-Source-Pakete und Bibliotheken | kommerzielle Dritt-Komponenten ohne offene Metadaten |
| deklarierte Abhängigkeiten in Build-Dateien | konkrete Firmware-Versionen eingebetteter Bausteine |
| bekannte Versionen mit Katalogeintrag | Angaben, die nur aus Lieferantenunterlagen hervorgehen |
Hier schließt sich der Kreis zur Sorgfaltspflicht. Damit Sie wissen, was in einer zugekauften Komponente steckt, brauchen Sie die Angaben des Lieferanten, und zwar bevor das Tool läuft. Eine Selbstauskunft des Lieferanten ist aus unserer Sicht der praktischste Weg, diese Sorgfalt zu erfüllen und die Angaben zu erhalten, die ein Scanner bei kommerziellen Komponenten nicht liefert. Welche Rolle in der Lieferkette für die SBOM verantwortlich ist, hängt davon ab, ob Sie als Hersteller, Einführer oder Händler auftreten; das behandeln wir gesondert im Beitrag zu den Schwachstellen- und SBOM-Pflichten in der Lieferkette. Wie Sie Lieferantennachweise praktisch absichern, zeigt die VDMA-Dokumentenreihe zur Supply-Chain-Security.
Was Sie jetzt konkret tun sollten
Die folgenden Schritte sind eine Praxisempfehlung, abgeleitet aus den genannten Pflichten. Sie verlagern den Aufwand bewusst nach vorne, damit die SBOM am Ende fast von selbst entsteht.
- Führen Sie ein Komponenten-Inventar, und tragen Sie jede Komponente schon beim Sourcing ein, mit Name, Version, Herkunft und Maintainer.
- Bewerten Sie jede Komponente vor der Integration: Konformität, Update-Historie und Einträge in Schwachstellendatenbanken prüfen.
- Fordern Sie für kommerzielle Dritt-Komponenten und eingebettete Firmware die Angaben des Lieferanten an, idealerweise Selbstauskunft, und pflegen Sie sie manuell ins Inventar.
- Erzeugen Sie die SBOM in einem gängigen maschinenlesbaren Format, das zumindest die obersten Abhängigkeiten abbildet, und nehmen Sie sie in die technische Dokumentation auf.
- Setzen Sie Scanner als Kontrolle ein, nicht als Quelle: Lassen Sie das Tool das Gebaute gegen Ihr Inventar abgleichen.
- Halten Sie die SBOM für die Marktüberwachungsbehörde bereit; eine Herausgabe an Kunden bleibt Ihre Entscheidung.
Wer das Komponentenmanagement so aufstellt, hat die SBOM-Pflicht des CRA zum größten Teil erledigt, bevor er ein Tool anfasst. Wann die Anforderungen für Ihre Produkte greifen, ordnen die CRA-Übergangsfristen ein.
Kommentar hinzufügen