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

Kaum ein Thema hat rund um den Cyber Resilience Act (Verordnung (EU) 2024/2847) so viel Unruhe ausgelöst wie die Frage nach Open Source. 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 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 ist die kommerzielle Tätigkeit, nicht der Quellcode

Der zentrale Gedanke: Der CRA greift erst, wenn ein Produkt mit digitalen Elementen im Rahmen einer kommerziellen Tätigkeit auf dem Markt bereitgestellt wird. Nicht der Umstand, dass Software quelloffen ist, entscheidet über die Betroffenheit, sondern der wirtschaftliche Kontext der Bereitstellung. 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. Die bloße Entwicklung oder das Bereitstellen von Quellcode ist keine Marktbereitstellung im Rechtssinne.

Wichtig zur Abgrenzung: „kommerzielle Tätigkeit" ist nicht identisch mit „gegen Bezahlung". Auch das Annehmen von Spenden oder das gelegentliche Bereitstellen kostenpflichtigen Supports macht ein Projekt nicht automatisch zu einem kommerziellen Produkt – hier arbeitet der Verordnungsgeber mit einer Wertung des Gesamtbilds. Genau an diesen Rändern liegt die verbleibende Unschärfe, zu der die Kommission Leitlinien angekündigt hat.

Diese Konstruktion schützt gezielt das freie Software-Ökosystem: Sie verhindert, dass die Verordnung Beitragende abschreckt oder Projekte in die Aufgabe treibt, nur weil Dritte den Code später kommerziell weiterverwenden. Die Verantwortung wandert erst mit dem wirtschaftlichen Inverkehrbringen – und dann zu demjenigen, der das Produkt tatsächlich am Markt bereitstellt, nicht zurück zum ursprünglichen Autor der Bibliothek.

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 – ausdrücklich kein Hersteller und keine natürliche Person –, die die Entwicklung von quelloffenen Produkten mit digitalen Elementen, die für kommerzielle Tätigkeiten bestimmt sind, systematisch und dauerhaft unterstützt. 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 stellt auf begründetes Verlangen die notwendigen Informationen bereit.
• Begrenzte Meldepflichten (Art. 24 Abs. 3): Nur ein eingegrenzter Ausschnitt der Meldepflichten aus Artikel 14 gilt – etwa dann, wenn der Steward Kenntnis von aktiv ausgenutzten Schwachstellen in dem von ihm unterstützten Code erlangt.

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. Und: Open-Source-Stewards unterliegen keinen Bußgeldern. Das Regime setzt auf Kooperation, nicht auf Sanktion – eine Anerkennung dafür, dass Stewards das Ökosystem tragen, ohne selbst ein fertiges Produkt in Verkehr zu bringen.

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

Die praktisch relevanteste 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 belastbare Komponentenübersicht führt, verkürzt später die Reaktionszeit erheblich. 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. Der CRA verlangt nicht, dass Sie jede Bibliothek selbst schreiben – aber dass Sie wissen, was in Ihrem Produkt steckt, und im Ernstfall handlungsfähig sind.

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 kommerziellen Tätigkeit" erfolgt, wann eine Organisation als Steward einzustufen ist und wie weit die begrenzten Steward-Pflichten reichen – das sind Wertungsfragen, zu denen die Europäische Kommission ergänzende Leitlinien angekündigt hat. Bis diese vorliegen, empfiehlt sich eine konservative Selbsteinschätzung entlang der bekannten Kriterien.

Für die meisten Unternehmen lautet die praktische Konsequenz ohnehin unabhängig von diesen Feinheiten: Wenn Sie ein kommerzielles Produkt mit digitalen Elementen bereitstellen, sind Sie Hersteller – und die Nutzung von Open Source ändert daran nichts, sondern 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.