Cyber Resilience Act und Open Source: Steward-Rolle und Anwendungsbereich

Rund um den Cyber Resilience Act (Verordnung (EU) 2024/2847) hat die Frage nach Open Source viel Unruhe ausgelöst. Die Sorge war real: Würden ehrenamtliche Entwicklerinnen und Entwickler künftig für ein Projekt haften, das andere kommerziell einsetzen? Der finale Verordnungstext beantwortet diese Frage differenziert. Er unterscheidet sauber zwischen Beitragenden, die freie und Open-Source-Software (FOSS) außerhalb einer kommerziellen Tätigkeit bereitstellen, einer neuen Rolle des Open-Source-Stewards (amtlich: Verwalter quelloffener Software) und Herstellern, die Open-Source-Komponenten in ihre Produkte integrieren. Dieser Beitrag ordnet die drei Ebenen ein und benennt offen, wo noch echte Unklarheit besteht.

Der Auslöser: Bereitstellung im Rahmen einer kommerziellen Tätigkeit

Der zentrale Gedanke: Der CRA greift erst, wenn ein Produkt mit digitalen Elementen im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird (Art. 3 Nr. 22; im Folgenden auch „kommerzielle Tätigkeit“). Ob Software quelloffen ist, spielt dafür keine Rolle; es kommt auf den wirtschaftlichen Kontext der Bereitstellung an. Nicht-kommerzielle FOSS liegt damit außerhalb des Anwendungsbereichs.

Für einzelne Beitragende bedeutet das konkret: Wer zu einem freien Projekt beiträgt, ohne dabei einer kommerziellen Tätigkeit nachzugehen, unterliegt nicht den Herstellerpflichten des CRA. Ein Ehrenamtlicher, der eine Bibliothek pflegt, eine Studentin, die ein Tool auf einer Plattform veröffentlicht, oder eine Community, die kein Geschäftsmodell verfolgt - sie werden durch die reine Veröffentlichung von Code nicht zu Herstellern im Sinne der Verordnung. Code, der außerhalb einer Geschäftstätigkeit veröffentlicht wird, ist keine Bereitstellung auf dem Markt (Erwägungsgrund 18).

Wichtig zur Abgrenzung: Eine Geschäftstätigkeit kann auch ohne Kaufpreis vorliegen. Spenden ohne Gewinnabsicht machen ein Projekt nicht kommerziell. Für eine Geschäftstätigkeit sprechen nach den Erwägungsgründen dagegen etwa Entgelte für technische Unterstützung, die über die Deckung der tatsächlichen Kosten hinausgehen, Spenden, die die Kosten für Konzeption, Entwicklung und Bereitstellung übersteigen, oder eine Gewinnerzielungsabsicht (Erwägungsgrund 15). Finanzielle Unterstützung durch Hersteller oder regelmäßige Versionsveröffentlichungen reichen für sich genommen nicht aus (Erwägungsgrund 18). Genau an diesen Rändern liegt die verbleibende Unschärfe; Art. 26 Abs. 2 Buchst. a sieht dazu Leitlinien der Kommission vor.

Diese Konstruktion soll das freie Software-Ökosystem schützen: Sie soll verhindern, dass die Verordnung Beitragende abschreckt oder Projekte in die Aufgabe treibt, nur weil Dritte den Code später kommerziell weiterverwenden. Die Herstellerverantwortung entsteht erst mit der Bereitstellung im Rahmen einer Geschäftstätigkeit und liegt bei demjenigen, der das Produkt am Markt bereitstellt; den ursprünglichen Autor der Bibliothek trifft sie nicht, solange er selbst nicht kommerziell handelt.

Der Open-Source-Steward (Art. 24): ein bewusst leichtes Regime

Der CRA führt in Artikel 24 (Definition in Art. 3 Nr. 14) eine eigene Rolle ein: den Open-Source-Steward. Gemeint ist eine juristische Person, die ausdrücklich kein Hersteller ist, die Entwicklung bestimmter Produkte mit digitalen Elementen, die als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig unterstützt und deren Brauchbarkeit sicherstellt. Typische Kandidaten sind Stiftungen und gemeinnützige Organisationen, die kritische Open-Source-Ökosysteme finanzieren, hosten oder verwalten.

Für Stewards gilt bewusst ein leichtes Pflichtenregime. Es umfasst im Kern drei Punkte:

• Dokumentierte Cybersicherheits-Policy (Art. 24 Abs. 1): Der Steward stellt eine nachprüfbar dokumentierte Cybersicherheitsleitlinie auf, die die Entwicklung sicherer Software und die Handhabung von Schwachstellen im geförderten Ökosystem fördert.
• Zusammenarbeit mit Behörden (Art. 24 Abs. 2): Der Steward kooperiert mit den Marktüberwachungsbehörden, um Risiken zu mindern, und übermittelt auf begründetes Verlangen die Unterlagen zu dieser Policy.
• Begrenzte Meldepflichten (Art. 24 Abs. 3): Die Meldung aktiv ausgenutzter Schwachstellen (Art. 14 Abs. 1) gilt für Stewards, soweit sie an der Entwicklung der Produkte beteiligt sind; Art. 14 Abs. 3 und 8 gelten, soweit schwerwiegende Sicherheitsvorfälle die Netz- und Informationssysteme betreffen, die der Steward für die Entwicklung bereitstellt.

Ebenso wichtig ist, was nicht gilt: Stewards bringen kein CE-Kennzeichen an, führen keine Konformitätsbewertung durch und erstellen keine technische Dokumentation im vollen Herstellerumfang. Bei den Bußgeldern nimmt Art. 64 Abs. 10 Buchst. b Open-Source-Stewards bei jedem Verstoß gegen die Verordnung von den Geldbußen der Absätze 3 bis 9 aus. Für die Meldepflichten aus Art. 14, die nach Art. 24 Abs. 3 auch für Stewards gelten (Abs. 1, soweit sie an der Entwicklung der Produkte beteiligt sind), ist das nach dem Wortlaut nicht eindeutig: Verstöße gegen Art. 14 sind in Abs. 2 geregelt, auf den Abs. 10 nicht verweist. Erwägungsgrund 120 geht davon aus, dass gegen Stewards keine Geldbußen verhängt werden. Im Einzelfall klären das die Rechtsabteilung oder eine Kanzlei. Das Regime setzt auf Kooperation mit den Behörden und berücksichtigt, dass Stewards das Ökosystem unterstützen, ohne selbst ein fertiges Produkt in Verkehr zu bringen.

Was sich für Unternehmen ändert, die Open Source nutzen

Eine praktisch wichtige Konstellation betrifft weder Ehrenamtliche noch Stiftungen, sondern Unternehmen, die Open-Source-Software in eigene, kommerziell vertriebene Produkte integrieren. Für sie ändert der CRA die Ausgangslage klar: Sie bleiben Hersteller im Sinne der Verordnung und damit für ihr gesamtes Produkt verantwortlich - einschließlich der eingebetteten Open-Source-Komponenten. Die Herkunft eines Bausteins entbindet nicht von der Pflicht, die grundlegenden Anforderungen aus Anhang I zu erfüllen.

Konkret heißt das: Die Verantwortung für Schwachstellenbehandlung, Sicherheitsupdates, koordinierte Offenlegung (CVD) und Meldungen nach Artikel 14 liegt beim integrierenden Hersteller - auch dann, wenn eine Schwachstelle in einer fremden Open-Source-Bibliothek steckt. Man kann die Sorgfalt nicht an das Upstream-Projekt „delegieren“.

Genau hier wird die Software Bill of Materials (SBOM) zum zentralen Werkzeug. Anhang I Teil II verlangt, dass Hersteller die im Produkt enthaltenen Komponenten identifizieren und dokumentieren - mindestens die Top-Level-Abhängigkeiten - in einem gängigen, maschinenlesbaren Format. Eine gepflegte SBOM verschafft Überblick darüber, welche Open-Source-Komponenten in welcher Version verbaut sind, und macht so überhaupt erst nachvollziehbar, ob eine neu bekannt gewordene Schwachstelle das eigene Produkt betrifft. Wer heute schon eine aktuelle Komponentenübersicht führt, kann später schneller reagieren. Details dazu finden Sie in unserem Beitrag zu den SBOM-Anforderungen des CRA.

Ein pragmatischer Ansatz für Hersteller mit hohem FOSS-Anteil: Upstream-Sicherheitshinweise systematisch beobachten, eine Kontaktstelle für Schwachstellenmeldungen einrichten, Sicherheits- von Funktionsupdates trennen und Prozesse etablieren, die auch dann greifen, wenn das Upstream-Projekt keinen Fix liefert. Sie dürfen fremde Bibliotheken nutzen; der CRA verlangt, dass Sie wissen, was in Ihrem Produkt steckt, und im Ernstfall handeln können.

Eine Besonderheit gilt für Hersteller quelloffener Produkte: Fällt ein Produkt, das als freie und quelloffene Software gilt, in eine Kategorie aus Anhang III (wichtige Produkte), kann der Hersteller jedes Verfahren nach Art. 32 Abs. 1 wählen, auch die interne Kontrolle nach Modul A, sofern er die technische Dokumentation beim Inverkehrbringen öffentlich zugänglich macht (Art. 32 Abs. 5).

Verbleibende Unklarheit - und was Sie jetzt tun sollten

Ehrlich bleibt festzuhalten: Die Grenzen sind an mehreren Stellen noch nicht scharf gezogen. Wann genau eine Bereitstellung „im Rahmen einer Geschäftstätigkeit“ erfolgt, wann eine Organisation als Steward einzustufen ist und wie weit die begrenzten Steward-Pflichten reichen - das sind Wertungsfragen, zu denen Art. 26 Abs. 2 Buchst. a Leitlinien der Kommission vorsieht. Prüfen Sie deren aktuellen Stand; bis zur Klärung empfiehlt sich eine konservative Selbsteinschätzung entlang der bekannten Kriterien.

Unabhängig von diesen Feinheiten lautet die praktische Konsequenz: Wenn Sie ein Produkt mit digitalen Elementen im Rahmen einer Geschäftstätigkeit unter Ihrem Namen in Verkehr bringen, sind Sie Hersteller - und die Nutzung von Open Source ändert daran nichts; sie verlagert die Aufgabe auf ein gutes Komponenten- und Schwachstellenmanagement. Ob Ihr konkretes Vorhaben überhaupt in den Anwendungsbereich fällt, klären Sie am besten mit unserem Betroffenheits-Check. Einen umfassenden Überblick über die Verordnung gibt unsere CRA-Themenseite.