CRA und Open Source: Pflichten für Hersteller und Stewards

Der Cyber Resilience Act nimmt freie und quelloffene Software aus, solange sie nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird. Wer Open-Source-Komponenten aber in ein eigenes Produkt integriert, trägt als Hersteller die volle Verantwortung dafür – und muss bei ihrer Auswahl und Pflege Sorgfalt walten lassen (Art. 13 Abs. 5).

Für Organisationen, die Open-Source-Projekte dauerhaft unterstützen, schafft der CRA eine eigene, leichtere Rolle: den Open-Source-Steward. Dieser Beitrag ordnet die drei Perspektiven – Hersteller, Steward, Maintainer.

Wann ist Open Source ausgenommen?

Entscheidend ist, ob die Software im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird. Ein Hobbyprojekt auf GitHub, zu dem Freiwillige beitragen, ist nicht erfasst. Anders sieht es aus, wenn ein Unternehmen eine Open-Source-Software monetarisiert, etwa über einen Preis für die Software selbst oder über Leistungen, die mit ihrer Nutzung untrennbar verbunden sind. Die bloße Beteiligung von Unternehmensentwicklern an einem Projekt macht dieses nicht automatisch kommerziell.

Der Open-Source-Steward (Art. 24)

Ein Open-Source-Steward ist eine juristische Person, die kein Hersteller ist, aber die Entwicklung bestimmter Open-Source-Produkte, die für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig unterstützt – typischerweise Stiftungen. Stewards haben ein reduziertes Pflichtenprogramm:

• eine dokumentierte Cybersicherheitsrichtlinie, die sichere Entwicklung und den Umgang mit Schwachstellen fördert,
• Zusammenarbeit mit den Marktüberwachungsbehörden,
• Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle, soweit sie an der Entwicklung beteiligt sind.

Sorgfaltspflicht für integrierte Komponenten

Art. 13 Abs. 5 verpflichtet Hersteller, bei der Integration von Komponenten Dritter – einschließlich Open Source – Sorgfalt walten zu lassen, damit diese die Cybersicherheit des Produkts nicht beeinträchtigen. Das bedeutet praktisch:

• Auswahl: Ist das Projekt aktiv gepflegt? Gibt es eine Sicherheitsrichtlinie und schnelle Reaktion auf Meldungen?
• Inventar: Jede Komponente steht in der SBOM – siehe unseren Leitfaden SBOM erstellen.
• Überwachung: Neue Schwachstellen in Abhängigkeiten werden laufend erkannt und bewertet.
• Exit-Plan: Was tun, wenn ein Projekt aufgegeben wird? Forken, ersetzen oder selbst pflegen – für den gesamten Supportzeitraum.

Die Ausgangslage in Zahlen

Laut dem OSSRA-Bericht 2026 enthält eine Codebasis im Durchschnitt 581 Schwachstellen – 107 % mehr als im Vorjahr (280). Ohne automatisierte Überwachung ist die Sorgfaltspflicht bei diesen Mengen nicht zu erfüllen.

Schwachstellen upstream melden

Findet ein Hersteller eine Schwachstelle in einer integrierten Komponente, muss er sie der Person oder Stelle melden, die die Komponente pflegt, und die Behebung dokumentieren. Hat er selbst einen Fix entwickelt, teilt er den relevanten Code oder die Dokumentation mit dem Maintainer – in einem maschinenlesbaren Format, soweit angemessen (Art. 13 Abs. 6). Open Source profitiert so direkt von den Herstellerpflichten.

Lizenzrisiken

Der CRA regelt keine Lizenzfragen. Eine gute SBOM macht Lizenzkonflikte aber sichtbar – und bei 68 % betroffenen Codebasen lohnt sich der Blick. Wer SBOM und Lizenzprüfung in einer Pipeline verbindet, erledigt zwei Aufgaben mit einem Werkzeug.

Sorgfalt in der Praxis: ein Prüfschema

Sorgfalt lässt sich nicht an einem einzelnen Kriterium festmachen. Ein einfaches Schema für neue Abhängigkeiten hilft, Entscheidungen nachvollziehbar zu machen:

Beispiele

Softwarehaus mit veralteter Bibliothek

Ein Softwarehaus nutzt eine PDF-Bibliothek, deren Maintainer das Projekt eingestellt hat. Unter dem CRA reicht es nicht, auf einen Fix zu warten. Optionen sind der Umstieg auf eine gepflegte Alternative, ein eigener Fork mit Sicherheitspflege oder die Isolation der Komponente. Die Entscheidung und ihre Begründung gehören in die technische Dokumentation.

Agentur mit gemeinsamem Framework

Eine Agentur setzt in vielen Kundenprojekten dasselbe Open-Source-Framework ein. Eine Schwachstelle darin betrifft schlagartig viele Hersteller. Wer weiß, welches Projekt welche Version nutzt, kann alle betroffenen Kunden gezielt informieren – statt jeden Kunden einzeln zu prüfen.

Beitrag zurück an die Community

Hersteller profitieren davon, wenn die Projekte, auf die sie angewiesen sind, gut gepflegt werden. Neben der Pflicht, Schwachstellen upstream zu melden, können sie Fixes beitragen, Maintainer finanziell unterstützen oder Stiftungen fördern, die als Open-Source-Steward auftreten. Das senkt das eigene Risiko nachhaltig.

Wenn Sie selbst Open Source veröffentlichen

Viele Mittelständler und Agenturen veröffentlichen eigene Bibliotheken oder Plugins als Open Source. Entscheidend ist dann, ob dies im Rahmen einer Geschäftstätigkeit geschieht. Veröffentlichen Sie eine Bibliothek ohne Monetarisierung, spricht viel für die Ausnahme. Verkaufen Sie dagegen Support oder eine kommerzielle Version, die untrennbar mit der Open-Source-Komponente verbunden ist, sollten Sie die Einordnung sorgfältig prüfen und dokumentieren.

• Monetarisierung und Geschäftsmodell der Veröffentlichung beschreiben.
• Prüfen, ob das Projekt als Teil eines eigenen Produkts ausgeliefert wird.
• Einen Meldeweg für Schwachstellen einrichten – unabhängig von der rechtlichen Einordnung.

Supply-Chain-Scan mit Nuowei

Nuowei (Beta, Launch November 2026) scannt Ihre Abhängigkeiten, bewertet Projektgesundheit und Schwachstellen und dokumentiert Ihre Sorgfalt für die technische Dokumentation. Mehr zum Schwachstellenmanagement.