Software-Lieferketten sind zunehmend komplex geworden. Ein Produkt kann Betriebssystempakete, kommerzielle Bibliotheken, Open-Source-Komponenten, Frameworks, Firmware und Abhängigkeiten umfassen, die von zahlreichen unterschiedlichen Lieferanten stammen.
Ein genaues Verständnis darüber, welche Softwarekomponenten in einem Produkt enthalten sind, ist daher ein wesentlicher Bestandteil des Cybersicherheits-Risikomanagements. Diese Transparenz ist wichtig, um einen effektiven, präzisen und, soweit möglich, automatisierten Prozess zur Behandlung von Schwachstellen zu etablieren. Die Kenntnis der enthaltenen Komponenten und ihrer Versionen ermöglicht es Herstellern, bei Bekanntwerden neuer Schwachstellen potenziell betroffene Produkte zu identifizieren, deren Relevanz und Auswirkungen zu bewerten und während des gesamten Produktlebenszyklus geeignete Maßnahmen zur Behebung zu ergreifen.
Mit der Einführung der Verordnung (EU) 2024/2847 – dem EU Cyber Resilience Act – sind Software-Stücklisten (SBOMs) auch zu einem ausdrücklichen regulatorischen Aspekt für Hersteller von Produkten mit digitalen Elementen geworden.
Eine SBOM (Software Bill of Materials, Software-Stückliste) lässt sich als strukturiertes Verzeichnis der in einem Produkt enthaltenen Softwarekomponenten verstehen. Eine ausgereifte SBOM stellt nicht nur eine Liste von Softwarenamen bereit, sondern kann beispielsweise folgende Informationen enthalten:
Das Ziel ist nicht die Dokumentation um ihrer selbst willen. Eine SBOM verschafft Herstellern Transparenz über ihre Software-Lieferkette und kann ihre Fähigkeit erheblich verbessern, eine wichtige Frage der Cybersicherheit zu beantworten: “Ist diese Schwachstelle für eine in meinem Produkt enthaltene Komponente oder für mein Endprodukt relevant?”
Diese Fähigkeit ist besonders wichtig, wenn auf neu entdeckte Schwachstellen in weitverbreiteten Komponenten von Drittanbietern reagiert werden muss.
Maschinenlesbare Formate ermöglichen es, diese Informationen automatisch durch Entwicklungswerkzeuge sowie Tools für das Schwachstellenmanagement und die Produktsicherheit verarbeiten zu lassen. Zwei der am häufigsten verwendeten SBOM-Formate sind CycloneDX und SPDX.
Ja. Der Cyber Resilience Act enthält in Anhang I Teil II Nummer 1 eine ausdrückliche Anforderung in Bezug auf SBOMs. Sie ist Bestandteil der Anforderungen an den Umgang mit Schwachstellen, die für Hersteller gelten:
Hersteller von Produkten mit digitalen Elementen müssen:
(1) Schwachstellen und Komponenten identifizieren und dokumentieren, die in Produkten mit digitalen Elementen enthalten sind, unter anderem durch die Erstellung einer Software-Stückliste in einem allgemein gebräuchlichen und maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene der Produkte abdeckt.
Wie daraus hervorgeht, schreibt der CRA kein bestimmtes SBOM-Format vor. Die Verordnung selbst legt auch keine abschließende Liste verpflichtender SBOM-Felder fest. Artikel 13 Absatz 24 ermöglicht es der Europäischen Kommission jedoch, das Format und die Bestandteile der SBOM durch Durchführungsrechtsakte festzulegen, wobei europäische oder internationale Normen und bewährte Verfahren berücksichtigt werden können.
Hersteller sollten die CRA-Anforderung daher als regulatorische Mindestanforderung und nicht als vollständige technische Spezifikation für die Umsetzung einer SBOM betrachten.
Eine SBOM sollte nicht als isoliertes Compliance-Dokument betrachtet werden. Im Rahmen des CRA ist sie Bestandteil der umfassenderen Verpflichtungen der Hersteller zum Umgang mit Schwachstellen.
Anhang I Teil II verpflichtet Hersteller unter anderem dazu, Schwachstellen und Softwarekomponenten zu identifizieren und zu dokumentieren, Schwachstellen unverzüglich zu beheben, Sicherheitsupdates bereitzustellen sowie relevante Informationen über behobene Schwachstellen offenzulegen oder Mechanismen für die sichere Verteilung von Updates bereitzustellen. Eine SBOM ist besonders nützlich, wenn sie in diesen Prozess integriert wird.
Wird beispielsweise eine neue CVE (Common Vulnerabilities and Exposures) veröffentlicht, die eine Bibliothek eines Drittanbieters betrifft, sollte der Hersteller feststellen können, ob die betroffene Komponente in der relevanten Version in einer oder mehreren Produktversionen enthalten ist.
Der eigentliche Wert einer SBOM liegt daher nicht allein in der Erstellung der Datei, sondern in der Aufrechterhaltung von Prozessen, die sicherstellen, dass die Informationen während des gesamten Produktlebenszyklus korrekt, nachvollziehbar und praktisch nutzbar sind.
Wenn im Rahmen des CRA eine Konformitätsbewertung durch Dritte erforderlich ist, dürfte die Frage nicht allein lauten, ob die SBOM-Datei vorhanden ist. Entscheidendere Bewertungsfragen betreffen vielmehr die Frage, ob der Hersteller einen wirksamen und wiederholbaren Prozess etabliert hat.
Organisationen sollten sich folgende Fragen stellen, um sicherzustellen, dass ihre SBOM-Prozesse wirksam und konform sind:
Letztlich sollte die SBOM als ein Nachweisbaustein innerhalb eines umfassenderen Cybersicherheits-Lebenszyklus betrachtet werden.
Aus Sicht der Konformitätsbewertung sind mehrere Fragen besonders relevant.
Die Softwarezusammensetzung verändert sich im Laufe der Zeit. Eine SBOM sollte daher eindeutig dem betreffenden Produkt und der jeweiligen Softwareversion zugeordnet sein. Ein allgemeines Komponentenverzeichnis, das sich keiner konkreten Produktversion zuordnen lässt, hat als Konformitätsnachweis möglicherweise nur einen begrenzten Nutzen.
Die gemäß CRA erforderlichen technischen Unterlagen müssen selbst die Softwareversionen ausweisen, die für die Konformität mit den grundlegenden Cybersicherheitsanforderungen relevant sind.
Eine Tabellenkalkulation oder eine manuell gepflegte PDF-Datei kann intern nützlich sein. Der CRA verweist jedoch ausdrücklich auf ein allgemein gebräuchliches und maschinenlesbares Format.
Die Verwendung etablierter Formate wie SPDX oder CycloneDX kann die automatisierte Verarbeitung, den Abgleich mit Schwachstellen und den Austausch von Komponenteninformationen innerhalb von Lieferketten erleichtern.
Ein Komponentenname allein ist möglicherweise nicht ausreichend. Beispielsweise können zwei Pakete mit ähnlichen Namen aus unterschiedlichen Ökosystemen oder von verschiedenen Lieferanten stammen.
Komponenteneinträge sollten nach Möglichkeit Identifikatoren enthalten, anhand derer sich das konkrete Softwareartefakt eindeutig bestimmen lässt. Beispiele hierfür sind Versionsangaben, Paket-URLs, Lieferanteninformationen und kryptografische Hashwerte.
Der CRA verlangt ausdrücklich die Abdeckung mindestens der Abhängigkeiten der obersten Ebene.
Moderne Software hängt häufig von Komponenten ab, die ihrerseits weitere Abhängigkeiten haben. Schwachstellen können deshalb auch auf mehreren Ebenen unterhalb der Software auftreten, die der Hersteller direkt integriert hat.
Es sollte nicht automatisch davon ausgegangen werden, dass das vorgeschriebene Mindestmaß und der Informationsumfang, der für ein wirksames Produktsicherheitsmanagement erforderlich ist, identisch sind.
Hersteller sollten nachvollziehen können, wie die Informationen erzeugt wurden. Abhängig von der Entwicklungsumgebung können SBOM-Informationen aus der Analyse von Quellcodeabhängigkeiten, Paketmanagern, Build-Systemen, Container-Images, Software-Composition-Analysis-Tools und weiteren Quellen gewonnen werden.
Eine automatisierte Erstellung kann die Wiederholbarkeit verbessern, insbesondere wenn sie in CI/CD-Prozesse integriert ist. Die automatisierte Generierung allein garantiert jedoch weder Vollständigkeit noch Korrektheit.
Hersteller bleiben dafür verantwortlich, die mit den in ihre Produkte integrierten Komponenten verbundenen Cybersicherheitsrisiken zu verstehen. Von Lieferanten bereitgestellte SBOM-Informationen können daher ein wichtiger Bestandteil des Absicherungsprozesses für die Software-Lieferkette sein.
Hersteller müssen gegebenenfalls vertragliche oder technische Mechanismen schaffen, um von Softwarelieferanten ausreichende Informationen zu den Komponenten zu erhalten.
Eine SBOM, die zu Beginn der Produktentwicklung erstellt und danach nie aktualisiert wird, verliert schnell an Wert.
Die Komponenteninformationen sollten mit den veröffentlichten Produktversionen und den während des Supportzeitraums vorgenommenen Änderungen übereinstimmen.
Der CRA verlangt, dass die technischen Unterlagen bei Bedarf kontinuierlich aktualisiert werden, mindestens jedoch während des Supportzeitraums.
Die Vollständigkeit sollte nicht allein anhand der Anzahl ausgefüllter Felder beurteilt werden. Entscheidend ist vielmehr, ob die SBOM den Hersteller in die Lage versetzt, betroffene Produkte zu identifizieren, wenn neue Schwachstellen bekannt werden.
Organisationen sollten deshalb erwägen, SBOM-Informationen mit Schwachstelleninformationen wie CVE-Daten, Schwachstellendatenbanken und gegebenenfalls VEX-Informationen (Vulnerability Exploitability eXchange) zu verknüpfen.
Nicht unbedingt. Der CRA begründet keine allgemeine Verpflichtung, die SBOM öffentlich zu veröffentlichen. Die SBOM ist Bestandteil der technischen Unterlagen. Anhang VII sieht vor, dass diese auf begründete Anfrage einer Marktüberwachungsbehörde zur Verfügung gestellt werden, sofern dies zur Überprüfung der Konformität erforderlich ist.
Diese Unterscheidung ist wichtig, denn die Erstellung, die Pflege und die Veröffentlichung einer SBOM sind drei unterschiedliche Aspekte.
Eine automatisch generierte SBOM, die unvollständig oder veraltet ist oder nicht in das Schwachstellenmanagement eingebunden wird, bietet nur einen geringen Cybersicherheitsnutzen. Eine nützliche SBOM sollte es einem Hersteller ermöglichen, Fragen wie die folgenden zu beantworten:
Wenn diese Fragen zuverlässig beantwortet werden können, ist die SBOM mehr als nur ein Dokumentationsnachweis zur Erfüllung regulatorischer Anforderungen. Sie wird zu einem operativen Bestandteil der Software-Lieferkettensicherheit.
Die folgenden Quellen bieten Organisationen, die ihre SBOM-Prozesse vorbereiten, hilfreiche Einstiegspunkte:
Applus+ uses first-party and third-party cookies for analytical purposes and to show you personalized advertising based on a profile drawn up based on your browsing habits (eg. visited websites). You can accept all cookies by pressing the "Accept" button or configure or reject their use. Consult our Cookies Policy for more information.
They allow the operation of the website, loading media content and its security. See the cookies we store in our Cookies Policy.
They allow us to know how you interact with the website, the number of visits in the different sections and to create statistics to improve our business practices. See the cookies we store in our Cookies Policy.
Based on your behavior on the website (where you click, how long you browse, etc.) we establish parameters and a profile for you to display ads that correspond to your interests. See the cookies we store in our Cookies Policy.