Antwort:

Der CRA sieht unterschiedliche Pflichten vor, die sich primär nur auf das in Verkehr gebrachte Produkt und nicht auf die darin enthaltenen Komponenten beziehen. Dies bedeutet im Hinblick auf FOSS-Komponenten:

a) Cybersicherheitsanforderungen gem. Anhang I

Nach Art. 13 (5) CRA müssen Hersteller nicht nur die Cybersicherheitsanforderungen im Hinblick auf das eigene Produkt gewährleisten, sondern auch "die gebotene Sorgfalt walten" lassen, "wenn sie von Dritten bezogene Komponenten in ihre Produkte mit digitalen Elementen integrieren, sodass solche Komponenten die Cybersicherheit des Produkts mit digitalen Elementen nicht beeinträchtigen." Dies gilt ausdrücklich auch für integrierte FOSS-Komponenten. Demnach muss nicht allgemein die Cybersicherheit der verwendeten FOSS-Komponenten geprüft werden, sondern konkret die Auswirkungen für das eigene Produkt. Mittelbar führt das jedoch zu einer Vorprüfung der Sicherheit der eingesetzten FOSS, wenn sich Sicherheitslücken der einzelnen Komponente auch auf das gesamte Produkt auswirken können.

Um die Sicherheitsprüfung für die Hersteller von Produkten zu erleichtern, die FOSS einsetzen, sieht Art. 25 CRA die Möglichkeit von 'Sicherheitsbescheinigungen' vor. Dafür bedarf es eines delegierten Rechtsakts der Kommission gem. Art. 61 CRA, der bislang noch nicht vorliegt (Stand: Juni 2026), der aber geplant ist.

b) Bewertung der Cybersicherheitsrisiken

Die Bewertung von Cybersicherheitsrisiken nach Art. 13 (2) CRA verlangt keine Bewertung für jede FOSS-Komponente, kann aber mittelbar dazu führen, dass Risiken aus einzelnen FOSS-Komponenten bewertet werden müssen, die sich auf das Gesamtprodukt auswirken können.

c) Erstellung einer technischen Dokumentation

Die technische Dokumentation gem. Art. 31 CRA soll "alle einschlägigen Daten oder Einzelheiten darüber" enthalten, "wie der Hersteller sicherstellt, dass das Produkt mit digitalen Elementen und die vom Hersteller festgelegten Verfahren den grundlegenden Cybersicherheitsanforderungen in Anhang I genügen". Gem. Art. 13 (7) CRA gehören dazu auch Schwachstellen, von denen der Hersteller Kenntnis erlangt. Dies gilt auch für Schwachstellen in enthaltenen FOSS-Komponenten und die Bewertung, wie sich diese auswirken. Vor diesem Hintergrund erscheint es notwendig, in die Dokumentation alle Third-Party-Komponenten aufzunehmen und bei Bedarf mit Informationen zu den einzelnen Komponenten zu ergänzen. Dafür spricht auch der Verweis in Anhang VII, 2b) CRA, der auf die SBOM Bezug nimmt.

d) Strategie für die koordinierte Offenlegung von Schwachstellen

Wenn einem Hersteller Schwachstellen des eigenen Produkts bekannt werden, müssen diese gem. Art. 13 (8) CRA entsprechend einem vorab vorgesehenen Prozess "bearbeitet und behoben" werden. Dies kann auch Schwachstellen aus FOSS-Komponenten betreffen. Dabei wird es darauf ankommen, ob das entsprechende Projekt selbst eine Behebung der Schwachstelle zur Verfügung stellt oder diese Aufgabe selbst vorgenommen werden muss.

e) Konformitätsbewertungsverfahren

Zum Konformitätsbewertungsverfahren gehört auch die technische Dokumentation mit der SBOM, so dass insoweit auch die verwendeten FOSS-Komponenten zur berücksichtigen sind. Die Bewertung hat aber nur im Hinblick auf das eigene Produkt zu erfolgen; eine Sicherheitsbescheinigung für die FOSS-Komponente gem. Art. 25 CRA kann dies vereinfachen.

f) SBOM

In der SBOM sind alle FOSS-Komponenten und deren jeweilige Version anzugeben.

g) Meldepflichten

Sobald der Hersteller eine Schwachstelle in einer in das Produkt mit digitalen Elementen integrierten Komponente, einschließlich einer FOSS-Komponente, feststellt, meldet er die Schwachstelle der Person oder Einrichtung, die diese Komponente herstellt oder wartet, und behandelt und behebt die Schwachstelle gemäß den in Anhang I Teil II festgelegten Anforderungen an die Behandlung von Schwachstellen.

Entsprechend besteht eine Pflicht auch zur Meldung von Schwachstellen in FOSS-Komponenten. Nach dem Wortlaut gilt dies auch für schon bekannte Schwachstellen. Es erscheint aber wenig sinnvoll, dass Schwachstellen wiederholt gemeldet werden müssen. Hier bleibt abzuwarten, wie die Kommission diese Regelung auslegt. Schwachstellen aus FOSS-Komponenten, die im eigenen Produkt aktiv ausgenutzt wurden sowie schwerwiegende Sicherheitsvorfälle, müssen über die einheitliche Meldeplattform sowohl CSIRT als auch der ENISA gemeldet werden (vgl. auch 5.4. der FAQ der Kommission).

CRA; Cybersicherheit; FOSS; Integration von FOSS; Konformitätsbewertung; Meldepflicht; Open Source-Software; Pflicht; SBOM; Schwachstelle; Technische Dokumentation

Letzte inhaltliche Aktualisierung dieser FAQ: Juni 2026

Nächste FAQ: "Kann die Integration einer Open Source-Komponente, welche in die Klassen der Anhänge III und IV des CRA als 'Wichtige Produkte mit digitalen Elementen' oder 'Kritische Produkte mit digitalen Elementen' kategorisiert wird, Einfluss auf die Klassifizierung des gesamten Endprodukts nehmen?"