CRA und Open Source: Maintainer, Verwalter und Hersteller

Open Source war der am meisten umstrittene Teil des Cyber Resilience Act. Frühe Entwürfe ließen Maintainer befürchten, dass schon das Veröffentlichen von Code auf GitHub sie als Hersteller haftbar machen könnte. Der endgültige Text zieht eine klare Linie: Der CRA folgt der Geschäftstätigkeit, nicht dem Code. Er gibt Menschen und Organisationen rund um Open Source drei Positionen, jede mit anderen Pflichten.

1. Open Source außerhalb einer Geschäftstätigkeit: nicht erfasst

Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird, ist nicht erfasst. Die Erwägungsgründe erklären, was das praktisch bedeutet:

Eine Einzelperson oder Gruppe, die Code veröffentlicht, Beiträge annimmt und unentgeltlich Fehler behebt, ist kein Hersteller.
Wer zu einem Projekt beiträgt, für das er nicht verantwortlich ist, wird dadurch nie zu dessen Hersteller.
Spenden, die keinen Gewinn anstreben, machen ein Projekt nicht zu einer Geschäftstätigkeit.
Gemeinnützige Organisationen, die Open Source entwickeln, gelten nicht als kommerziell, sofern etwaige Einnahmen in gemeinnützige Ziele reinvestiert werden.

Was ein Open-Source-Produkt kommerziell machen kann: dafür einen Preis verlangen, für technischen Support mehr als die tatsächlichen Kosten verlangen, es über eine Softwareplattform oder andere Dienste monetarisieren oder die Verarbeitung personenbezogener Daten aus anderen Gründen als Sicherheit, Kompatibilität oder Interoperabilität zur Nutzungsbedingung machen.

2. Verwalter quelloffener Software: eine leichte Regelung

Der CRA schafft eine neue Rolle, den Verwalter quelloffener Software (Open-Source-Software-Steward): eine juristische Person, die kein Hersteller ist und deren Zweck es ist, die Entwicklung bestimmter, für Geschäftstätigkeiten bestimmter Open-Source-Produkte systematisch und nachhaltig zu unterstützen und ihre Tragfähigkeit zu sichern. Stiftungen, die weit verbreitete Projekte beherbergen und unterstützen, sind das typische Beispiel.

Verwalter haben eine eigene, leichte Regelung (Artikel 24). Sie müssen:

eine Cybersicherheitsstrategie einführen und dokumentieren, die die sichere Entwicklung und den wirksamen Umgang mit Schwachstellen fördert und die Entwickler zur freiwilligen Meldung von Schwachstellen ermutigt;
auf Verlangen mit den Marktüberwachungsbehörden zusammenarbeiten;
aktiv ausgenutzte Schwachstellen in Produkten melden, an deren Entwicklung sie beteiligt sind, und schwerwiegende Sicherheitsvorfälle nur, soweit sie die Netz- und Informationssysteme betreffen, die sie für diese Entwicklung bereitstellen. Diese Meldepflichten der Verwalter gelten ab dem 11. Dezember 2027.

Sie führen keine Konformitätsbewertungen durch, bringen keine CE-Kennzeichnung an und erstellen keine technische Dokumentation. Und gegen sie können keine Geldbußen nach den Sanktionsvorschriften des CRA verhängt werden (Artikel 64 Absatz 10).

Die Verordnung sieht außerdem freiwillige Sicherheitsbescheinigungsprogramme für Open-Source-Software vor, damit sich Hersteller darauf stützen können (Artikel 25).

3. Hersteller, die Open Source nutzen: voll verantwortlich

Wenn ein Unternehmen ein Produkt in Verkehr bringt, ist es Hersteller des ganzen Produkts, einschließlich der Open-Source-Komponenten. Das hat drei Folgen:

Sorgfaltspflicht bei Komponenten. Beim Einbau von Drittkomponenten, auch Open Source, müssen Hersteller sicherstellen, dass diese die Cybersicherheit des Produkts nicht beeinträchtigen (Artikel 13 Absatz 5).
Nach oben melden. Ein Hersteller, der eine Schwachstelle in einer Open-Source-Komponente findet, muss sie der Person oder Organisation melden, die die Komponente pflegt, und darauf reagieren; entwickelt er eine Korrektur, muss er den Code oder die Dokumentation mit dem Maintainer teilen, wo angemessen in einem maschinenlesbaren Format (Artikel 13 Absatz 6).
Umgang mit Schwachstellen für das Produkt. Die SBOM, die tägliche Überwachung auf neue und ausgenutzte Schwachstellen, die Korrekturen und Hinweise sind Aufgabe des Herstellers für jede Komponente, die er ausliefert, auch für Bibliotheken, die er nicht geschrieben hat.

Ein Unternehmen, das sein eigenes Open-Source-Projekt veröffentlicht und verkauft oder wie oben beschrieben damit Geld verdient, ist Hersteller dieses Produkts, mit allen Pflichten. Freie und quelloffene Produkte in den wichtigen Kategorien haben einen Vorteil: Sie können den Weg der Selbstbewertung nutzen, wenn ihre technische Dokumentation öffentlich ist (Artikel 32 Absatz 5).

Ein schneller Selbsttest

Sie sind	Ihre Position
Ehrenamtliche Maintainerin oder Beitragender	Nicht erfasst
Eine Stiftung, die kommerziell genutzte Projekte beherbergt	Wahrscheinlich ein Verwalter
Ein Unternehmen, das ein Produkt mit Open-Source-Anteilen verkauft	Hersteller des ganzen Produkts
Ein Unternehmen, das Support für ein selbst gepflegtes Open-Source-Projekt verkauft, wodurch das Produkt monetarisiert wird	Möglicherweise Hersteller: Prüfen Sie die Leitlinien der Kommission
Ein Unternehmen, das intern genutzte Open Source veröffentlicht, ohne sie zu verkaufen	Für diesen Code in der Regel nicht erfasst

Grenzfälle gibt es wirklich. Die Leitlinien der Kommission zur Anwendung des CRA (Juli 2026) und ihre FAQ geben Beispiele; lesen Sie sie und fragen Sie eine Anwältin oder einen Anwalt, wenn Ihr Modell auf der Grenze liegt.

Was Maintainer trotzdem tun können

Auch wenn sie nicht erfasst sind, werden Maintainer beliebter Projekte den CRA über die Unternehmen spüren, die ihren Code nutzen. Hilfreiche Dinge, die wenig kosten:

eine Sicherheitsrichtlinie und eine Kontaktstelle veröffentlichen (SECURITY.md, security.txt);
für Releases eine SBOM erzeugen;
Hinweise in einem Standardformat veröffentlichen, wenn etwas behoben wurde;
angeben, welche Versionen unterstützt werden.

Wie Provetry hilft

Für Hersteller listet Provetry jede Open-Source-Komponente jeder Version auf, überwacht sie auf neue und ausgenutzte Schwachstellen und hält Ihre Entscheidungen fest. Jedes Produkt hält Ihre Rolle fest (Hersteller, Einführer, Händler oder Verwalter quelloffener Software), damit Ihre Dokumentation sagt, welche Pflichten Sie tragen.

Dieser Leitfaden ist eine allgemeine Information, keine Rechtsberatung.

Quellen

Verordnung (EU) 2024/2847, die Cyberresilienz-Verordnung, Erwägungsgründe 15 und 17 bis 21, Artikel 3, 13, 24, 25, 32 und 64
Europäische Kommission: Cyberresilienzgesetz, Leitlinien und FAQ
Eclipse Foundation: Open Regulatory Compliance Working Group