Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Artikel 13 Absatz 5 des Cyber Resilience Act (CRA) schreibt eine Sorgfaltspflicht in Bezug auf Komponenten von Drittanbietern vor, einschließlich Open-Source-Komponenten.
- Ein Verstoß gegen Artikel 13 kann mit Geldbußen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist.
- Der unverbindliche Erwägungsgrund 34 verknüpft die Sorgfaltspflicht mit dem Komponentenrisiko und nennt vier mögliche Maßnahmen; die Wahl und Dokumentation der Methode liegt jedoch bei Ihnen.
- Gemäß den Leitlinien der Europäischen Kommission übernehmen Sie bei der Integration einer Open-Source-Komponente nicht deren eigene CRA-Konformität. Die Konformität Ihres Produkts erstreckt sich weiterhin auf diese Komponente, einschließlich der Behebung ihrer Sicherheitslücken während Ihres Supportzeitraums, selbst wenn der Upstream-Entwickler keine Korrekturen mehr vornimmt.
- Die Maßnahmen gemäß Erwägungsgrund 34 prüfen nicht, ob ein Paket aus dem veröffentlichten Quellcode erstellt wurde oder ob es eingeschleusten Code enthält; daher entscheidet Ihre eigene Risikobewertung darüber, inwieweit beides überprüft werden soll.
Wenn Ihr Produkt Open-Source-Komponenten enthält, sind Sie gemäß dem Cyber Resilience Act (CRA) verpflichtet, ab dem 11. Dezember 2027 die erforderliche Sorgfalt in Bezug auf diese Komponenten walten zu lassen. Die unverbindlichen Leitlinien der Europäischen Kommission fügen hinzu, dass Betreuer, die ihre Open-Source-Komponenten nicht kommerziell anbieten, Ihnen gegenüber gemäß dem CRA keine Verpflichtungen haben. Artikel 13 Absatz 5 erweitert Ihre Sorgfaltspflicht sogar auf diese Komponenten, sodass auch eine Bibliothek, mit der ihr Betreuer kein Geld verdient, berücksichtigt wird.
Wie viel Sorgfalt ist ausreichend? Die CRA lässt diese Frage offen, und Erwägungsgrund 34 passt den Umfang an das Risiko der Komponente an und führt Beispielmaßnahmen auf, ohne dass eine davon zwingend vorgeschrieben ist. Bei keiner dieser Maßnahmen wird geprüft, ob das Paket, auf dem Ihr Produkt läuft, aus dem veröffentlichten Quellcode erstellt wurde oder Code enthält, der dort nicht hingehört. Die Entscheidung liegt bei Ihnen, und bei Nichteinhaltung können Bußgelder verhängt werden (Artikel 64 Absatz 2).
Was das Gesetz zur Cyber-Resilienz über Komponenten sagt, die Sie nicht selbst geschrieben haben
Das EU-Gesetz zur Cyber-Resilienz ( Verordnung (EU) 2024/2847) legt die Sorgfaltspflicht den Herstellern auf. Ein Produkt mit digitalen Elementen ist ein Software- oder Hardwareprodukt, einschließlich Software- oder Hardwarekomponenten, die separat in Verkehr gebracht werden (Artikel 3 Absatz 1). Artikel 3 Absatz 13 definiert einen Hersteller als eine natürliche oder juristische Person, die solche Produkte entwickelt oder herstellt oder deren Entwurf, Entwicklung oder Herstellung in Auftrag gibt und sie unter ihrem Namen oder ihrer Marke in Verkehr bringt. Die Definition gilt unabhängig davon, ob das Produkt verkauft, monetarisiert oder verschenkt wird.
Eine Komponente ist Software oder Hardware, die zur Integration in ein elektronisches Informationssystem bestimmt ist (Artikel 3 Absatz 6); daher fällt eine Open-Source-Bibliothek, auf der Ihr Produkt basiert, in der Regel darunter. Gemäß Artikel 2 Absatz 1 gilt die CRA für Produkte, die auf dem Markt bereitgestellt werden und deren Verwendungszweck oder vernünftigerweise vorhersehbare Nutzung eine Datenverbindung zu einem Gerät oder Netzwerk umfasst.
Artikel 3 Absatz 22 definiert „Bereitstellung auf dem Markt“ als die Lieferung zum Vertrieb oder zur Nutzung auf dem EU-Markt im Rahmen einer gewerblichen Tätigkeit, unabhängig davon, ob diese entgeltlich oder unentgeltlich erfolgt. Auch die unentgeltliche Bereitstellung kann gewerblicher Natur sein. Bei Open-Source-Software kommt es darauf an, ob der Herausgeber damit Geld verdient, beispielsweise durch die Erhebung von Gebühren, indem er den Zugang zu Veröffentlichungen oder Updates von einer Zahlung abhängig macht oder indem er sie nutzt, um andere Dienstleistungen zu verkaufen (Erwägungsgrund 18; Leitlinien der Kommission, Abschnitt 3.2). Eine Bibliothek, die ihr Betreuer außerhalb einer gewerblichen Tätigkeit bereitstellt, gilt nicht als Produkt, ist aber dennoch eine Komponente Ihres Produkts.
Gemäß Artikel 13 Absatz 5 sind Hersteller verpflichtet, bei der Integration von Komponenten, die von Dritten bezogen werden, die gebotene Sorgfalt walten zu lassen, damit diese Komponenten die Cybersicherheit des Produkts nicht gefährden. Dies gilt ausdrücklich auch für freie und Open-Source-Komponenten, die nicht im Rahmen einer gewerblichen Tätigkeit auf dem Markt bereitgestellt wurden. Artikel 13 gilt ab dem 11. Dezember 2027 (Artikel 71 Absatz 2).
Ein Verstoß gegen Artikel 13 kann mit Verwaltungsstrafen von bis zu 15.000.000 Euro oder – im Falle eines Unternehmens (EU-Bezeichnung für ein Wirtschaftsunternehmen) – von bis zu 2,5 % seines weltweiten Gesamtjahresumsatzes des vorangegangenen Geschäftsjahres geahndet werden, je nachdem, welcher Betrag höher ist (Artikel 64 Absatz 2).
Der Schadensersatz für Schäden durch fehlerhafte Produkte unterliegt einer gesonderten Regelung, der Richtlinie (EU) 2024/2853, der Produkthaftungsrichtlinie. In Erwägungsgrund 31 wird diese als Ergänzung zur CRA bezeichnet und es heißt, dass das Fehlen von Sicherheitsupdates, das zu Schäden führt, die Haftung des Herstellers nach dieser Richtlinie auslösen könnte.
Was die Due Diligence abdeckt und was nicht
Das Gesetz zur Cyber-Resilienz (Cyber Resilience Act, CRA) verpflichtet Hersteller zur Sorgfaltspflicht, und in der nicht bindenden Erwägungsgrund 34 wird der Text konkreter. Dort heißt es, dass das angemessene Maß von der Art und dem Ausmaß des mit einer Komponente verbundenen Cybersicherheitsrisikos abhängt und dass bei der Sorgfaltspflicht eine oder mehrere der vier aufgeführten Maßnahmen (Tabelle 1) berücksichtigt werden sollten. Die FAQ der Kommission zum CRA, ein von den Leitlinien getrenntes Frage-und-Antwort-Dokument, enthält weitere Beispiele.
Tabelle 1. Von den Quellen genannte Maßnahmen zur Sorgfaltspflicht bei einer Komponente
| Aktion | Quelle | Grundlage |
|---|---|---|
| Überprüfen Sie gegebenenfalls, ob der Hersteller des Bauteils die Konformität mit der CRA nachgewiesen hat, beispielsweise durch die CE-Kennzeichnung. | Erwägungsgrund 34 | Konzert (interpretativ) |
| Vergewissern Sie sich, dass die Komponente regelmäßig Sicherheitsupdates erhält, beispielsweise anhand ihres Update-Verlaufs. | Erwägungsgrund 34 | Konzert (interpretativ) |
| Stellen Sie sicher, dass die Komponente keine Schwachstellen aufweist, die in der europäischen Schwachstellendatenbank oder anderen öffentlichen Schwachstellendatenbanken erfasst sind. | Erwägungsgrund 34 | Konzert (interpretativ) |
| Führen Sie zusätzliche Sicherheitstests durch | Erwägungsgrund 34 | Konzert (interpretativ) |
| Führen Sie eine Software-Zusammensetzungsanalyse durch, identifizieren Sie besonders kritische Komponenten, überprüfen Sie die Software-Stückliste (SBOM) der Komponente, sofern verfügbar, prüfen Sie deren Supportzeitraum, vergewissern Sie sich, dass der Verwendungszweck mit den Angaben des Herstellers übereinstimmt, oder bewerten Sie die Sicherheitslage des Herstellers | FAQ der Kommission, Antwort 4.4.2 (Version 1.4, 4. September 2026) | Häufig gestellte Fragen zur Kommission (unverbindlich) |
Hinweis: In den FAQ der Kommission heißt es, dass ihre Antworten keine zusätzlichen Anforderungen begründen und dass ihre Stellungnahmen keinen verbindlichen Charakter haben.
In Erwägungsgrund 34 heißt es „eine oder mehrere“, sodass keine einzelne Maßnahme als zwingend vorgeschrieben gilt. Weder dieser Erwägungsgrund noch Artikel 13 Absatz 5 schreiben eine bestimmte Methode, eine bestimmte Tiefe oder ein bestimmtes Aufzeichnungsformat vor.
In Anhang VII ist aufgeführt, was die technische Dokumentation enthalten muss. Dort sind die Risikobewertung, die Beschreibung der Einbindung der Softwarekomponenten in das Gesamtsystem sowie die Prüfberichte aufgeführt, jedoch gibt es keinen eigenen Punkt für die Sorgfaltspflicht in Bezug auf die Komponenten. Das bedeutet jedoch nicht, dass die Sorgfaltspflicht nicht dokumentiert wird. Artikel 13 Absatz 7 verpflichtet die Hersteller weiterhin dazu, relevante Aspekte der Cybersicherheit des Produkts systematisch zu dokumentieren, und zwar entsprechend der Art des Produkts und den damit verbundenen Cybersicherheitsrisiken.
Da das Risikoniveau vorgegeben ist und die Methode offen bleibt, bestimmt Ihre eigene Beurteilung, wie viel Sorgfalt jeder Komponente gewidmet wird. Die Leitlinien der Kommission (Punkte 170 und 171) unterteilen die Pflicht in zwei Schritte: Ermitteln Sie anhand der Risikobewertung Ihres Produkts, welche Anforderungen das Produkt an jede Komponente stellt, und überprüfen Sie anschließend, ob die Komponente diese erfüllt. Eine Aufzeichnung dieser Überprüfung, die zum Zeitpunkt des Einbaus der Komponente erstellt wird, ist zuverlässiger als eine, die Jahre später nachträglich erstellt wird, da Artikel 13 Absatz 5 die Pflicht an den Einbau knüpft.
Was bleibt einem im Gedächtnis und was nicht
In den Leitlinien der Kommission vom 27. Juli 2026 heißt es, dass Hersteller, die Open-Source-Komponenten integrieren, nicht für die Einhaltung der CRA-Vorschriften durch diese einzelnen Komponenten verantwortlich sind, selbst wenn sie Quellcode zu deren Wartung beitragen (Punkt 86). Sie behalten ihre eigenen Verpflichtungen in Bezug auf das Produkt bei, einschließlich der Sorgfaltspflicht gemäß Artikel 13 Absatz 5 sowie der Meldung von Schwachstellen und der Weitergabe von Korrekturen gemäß Artikel 13 Absatz 6 (Punkt 88).
Vorherige Verwalter und Betreuer haben wesentlich geringere CRA-Pflichten als Hersteller. Artikel 3 Absatz 14 definiert einen Open-Source-Software-Verwalter als eine juristische Person, die kein Hersteller ist und deren Zweck darin besteht, die Entwicklung bestimmter freier und quelloffener Produkte, die für kommerzielle Aktivitäten bestimmt sind, systematisch und nachhaltig zu unterstützen und deren Fortbestand zu gewährleisten. Artikel 24 sieht für Betreuer eine weniger strenge Regelung vor: eine dokumentierte Cybersicherheitsrichtlinie, die Zusammenarbeit mit Marktüberwachungsbehörden und in begrenzten Fällen Teile der in Artikel 14 vorgesehenen Meldepflicht bezüglich ausgenutzter Schwachstellen und Vorfälle (Artikel 24 Absatz 3). In den Leitlinien wird hinzugefügt, dass Betreuer von Komponenten, die nicht auf dem Markt bereitgestellt wurden, gegenüber den Herstellern, die diese integrieren, keine Verpflichtungen haben (Punkt 87).
Ihre Pflichten beschränken sich nicht auf die Integration. Gemäß Artikel 13 Absatz 6 sind Sie verpflichtet, eine Schwachstelle, die Sie in einer Komponente feststellen, dem Hersteller oder Wartungsanbieter dieser Komponente zu melden, um sie zu beheben, und den entsprechenden Code oder die Dokumentation weiterzugeben, falls Sie eine Korrektur entwickelt haben. Artikel 13 Absatz 8 schreibt vor, dass Schwachstellen im Produkt, einschließlich seiner Komponenten, während des von Ihnen festgelegten Supportzeitraums wirksam behandelt werden müssen. Dieser Zeitraum muss mindestens fünf Jahre betragen, es sei denn, das Produkt wird voraussichtlich weniger als fünf Jahre lang genutzt. Gemäß der CRA sind weder Verwalter (Artikel 24) noch Betreuer von Komponenten, die nicht auf dem Markt bereitgestellt wurden (Punkt 87), zu einem Supportzeitraum verpflichtet; daher kann es vorkommen, dass für eine Komponentenversion keine Upstream-Korrekturen mehr bereitgestellt werden, während der Supportzeitraum Ihres Produkts noch mehrere Jahre läuft.
Die aufgeführten Aktionen fragen nicht danach, wie ein Paket erstellt wurde
Drei der vier Maßnahmen in Erwägungsgrund 34 beziehen sich auf die öffentlich zugänglichen Informationen zu einer Komponente. Dabei wird geprüft, ob der Hersteller die Konformität nachgewiesen hat, ob regelmäßig Sicherheitsupdates bereitgestellt werden und welche Angaben die Schwachstellendatenbanken dazu enthalten. Die vierte Maßnahme – zusätzliche Sicherheitstests – ist die einzige, bei der Sie die Komponente selbst testen müssen.
Die Dokumentation einer Komponente beschreibt, wie sich ein Projekt verhält, gibt jedoch keinen Aufschluss darüber, ob das Paket, das letztendlich auf Ihrem Produkt ausgeführt wird, aus dem vom Projekt veröffentlichten Quellcode erstellt wurde oder ob es Code enthält, der dort nicht hingehört. Die Herkunft des Builds und eingefügter Code tauchen weder in den Maßnahmen in Erwägungsgrund 34 noch in den Beispielen in den FAQ der Kommission auf. Dennoch haben beide direkten Einfluss darauf, ob eine Komponente die Cybersicherheit des Produkts gefährdet – genau das Ergebnis, das Artikel 13 Absatz 5 verhindern soll.
Artikel 13 Absatz 5 lässt die Vorgehensweise offen, sodass es Ihnen überlassen bleibt, wie Sie die Herkunft überprüfen und nach eingeschleustem Code suchen. Zwei Möglichkeiten sind, ein Paket anhand seines Quellcodes zu verifizieren und es auf bösartigen Code zu überprüfen, bevor es in Ihre Umgebung gelangt. Eine SBOM listet auf, was ein Produkt enthält, doch die Auflistung eines Pakets sagt nichts darüber aus, wie es erstellt wurde oder welchen Code es enthält. Ihre Risikobewertung sollte Aufschluss darüber geben, in welchem Umfang dies für die einzelnen Komponenten erforderlich ist.
Pakete prüfen, bevor sie in Ihre Umgebung gelangen
SecureChain von TuxCare überprüft den Quellcode der von ihm abgedeckten Open-Source-Pakete auf bekannte Malware, verdächtige Codemuster und andere Risiken in der Lieferkette und erstellt die Pakete anschließend aus diesem geprüften Quellcode in abgesicherten, isolierten Build-Umgebungen neu. Pakete, die die Überprüfung nicht bestehen, werden gestoppt, bevor sie Ihre Umgebung erreichen. Jedes Paket wird mit einer SBOM, einem VEX-Dokument und einer SLSA-Level-3-Herkunftsangabe geliefert – einer Aufzeichnung der Quelle und des Builds, aus denen es hervorgegangen ist.
Für Komponenten, die noch aktiv gepflegt werden, liefert SecureChain im Rahmen einer Service-Level-Vereinbarung Korrekturen in neu kompilierten Paketen, sobald neue Sicherheitslücken bekannt werden. Sobald die Pflege durch den Upstream-Entwickler endet, behebt der „Endless Lifecycle Support“ von TuxCare weiterhin Sicherheitslücken aller Schweregrade – von „kritisch“ bis „gering“ – in den von Ihnen verwendeten Versionen.
Sie können nicht überprüfen, was in den von Ihnen versendeten Paketen enthalten ist? Erfahren Sie, wie SecureChain diese überprüft, bevor sie in Ihre Builds gelangen.
FAQ
Wer ist vom Gesetz zur Cyber-Resilienz betroffen?
Das Gesetz zur Cyber-Resilienz (Cyber Resilience Act, CRA), die EU-Verordnung zur Cybersicherheit von Produkten, gilt für Produkte mit digitalen Elementen, die im Rahmen einer gewerblichen Tätigkeit auf dem EU-Markt bereitgestellt werden und deren Verwendungszweck oder vernünftigerweise vorhersehbare Nutzung eine Datenverbindung zu einem Gerät oder Netzwerk umfasst (Artikel 2 Absatz 1 und Artikel 3 Absatz 22). Die Pflichten obliegen hauptsächlich den Herstellern. Importeure, Vertreiber und Open-Source-Software-Verwalter haben gesonderte Pflichten (Artikel 19, 20 und 24).
Wann gelten die Bestimmungen des Cyber Resilience Act?
Das Gesetz über Cyber-Resilienz (CRA) trat am 10. Dezember 2024 in Kraft. Kapitel IV über die Notifizierung von Konformitätsbewertungsstellen gilt seit dem 11. Juni 2026, und Artikel 14 über die Berichterstattung durch Hersteller gilt seit dem 11. September 2026. Die übrigen Bestimmungen gelten ab dem 11. Dezember 2027 (Artikel 71 Absatz 2).
Ersetzt das CRA die Produkthaftungsvorschriften?
Nein. In Erwägungsgrund 31 des Gesetzes über Cyber-Resilienz (CRA) wird die Richtlinie (EU) 2024/2853, die Produkthaftungsrichtlinie, als ergänzend bezeichnet. Diese Richtlinie regelt den Schadensersatz für Schäden, die durch fehlerhafte Produkte verursacht werden, während das CRA die Pflichten der Hersteller festlegt, deren Einhaltung durch Bußgelder durchgesetzt wird (Artikel 64). Artikel 65 wendet die EU-Vorschriften über Verbandsklagen auf Verstöße an, die die kollektiven Interessen der Verbraucher beeinträchtigen oder beeinträchtigen könnten.
Dürfen Hersteller Open-Source-Software von Betreibern nutzen, an die die CRA keine Bindung hat?
Ja, sofern der Hersteller die gebotene Sorgfalt walten lässt, damit diese Komponenten die Cybersicherheit des Produkts nicht beeinträchtigen. Artikel 13 Absatz 5 des Cyber Resilience Act (CRA) bezieht sich ausdrücklich auf Open-Source-Komponenten, die nicht kommerziell auf dem Markt bereitgestellt wurden, und in Erwägungsgrund 34 heißt es, dass das Sicherheitsniveau vom Risiko der jeweiligen Komponente abhängt.
Müssen Hersteller Sicherheitslücken in Komponenten dem Betreuer melden?
Ja, sobald eine solche identifiziert wurde. Ab dem 11. Dezember 2027 verpflichtet Artikel 13 Absatz 6 des Cyber Resilience Act (CRA) einen Hersteller, eine Schwachstelle in einer integrierten Komponente – einschließlich einer Open-Source-Komponente – dem Hersteller oder Wartungsunternehmen dieser Komponente zu melden und Abhilfe zu schaffen. Entwickelt der Hersteller einen Fix, muss er den entsprechenden Code oder die Dokumentation zur Verfügung stellen. Dies ist unabhängig von der Meldepflicht gemäß Artikel 14 gegenüber den Behörden, die seit dem 11. September 2026 gilt.
