Cyber Resilience Act und Open Source: Steward-Pflichten vor dem Stichtag

Am 11. September 2026 wird der Cyber Resilience Act (CRA) für viele Teams konkret: Dann gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. In den nächsten Monaten reden die meisten über Konformitätsbewertung, CE-Kennzeichnung und SBOMs. Über Open Source redet kaum jemand. Kein Wunder, die Antwort liegt irgendwo zwischen „Open Source ist ausgenommen“ und „jede Bibliothek braucht jetzt eine CE-Kennzeichnung“. Am Ende kommt es darauf an, welche Rolle man hat – und wer für das Produkt verantwortlich ist.

Warum Open Source kein Randthema ist

Open Source ist aus der Softwareentwicklung nicht mehr wegzudenken. Kaum jemand entwickelt noch ausschließlich mit eigenem Code. Frameworks, Laufzeitumgebungen, Kryptografie-Bibliotheken, Container-Images und Paketmanager tragen fast jede moderne Anwendung mit. Wer den CRA verstehen will, muss also nicht nur auf das eigene Produkt schauen, sondern auch auf die Lieferkette dahinter.

Dem CRA ist die Lizenz erst einmal egal. Er setzt beim Produkt mit digitalen Elementen an. Sobald Software oder ein vernetztes Gerät auf dem EU-Markt bereitgestellt oder in Verkehr gebracht wird, muss jemand für Cybersicherheit, Updates und Konformität verantwortlich sein. Bei proprietärer Software ist das meist klar. Bei Open Source oft nicht – genau deshalb fühlen sich viele unsicher.

Der Basisartikel zum Cyber Resilience Act: Meldepflichten ab September 2026 beschreibt die allgemeinen Herstellerpflichten. Hier geht es um die Open-Source-Schnittstellen: Community-Maintainer, kommerzielle Integratoren und Organisationen, die als Open-Source-Steward auftreten.

Ausgangslage: Software ist ein Produkt mit digitalen Elementen

Die Grundlage ist die Verordnung (EU) 2024/2847 (Cyber Resilience Act). Sie vereinheitlicht die Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Dazu zählen ausdrücklich auch Softwareprodukte, mobile Apps, Betriebssysteme und Komponenten. Ob der Quelltext offen ist, spielt für den Produktbegriff erst einmal keine Rolle. Entscheidend ist, ob ein Produkt im Rahmen einer Geschäftstätigkeit auf den Markt kommt.

Wer ein solches Produkt in Verkehr bringt, ist Hersteller und muss unter anderem Schwachstellen während des gesamten Supportzeitraums behandeln, Sicherheitsupdates bereitstellen und ausreichend technisch dokumentieren. Ob ein Produkt als Standard, wichtig oder kritisch eingestuft wird, bestimmt die Art der Konformitätsbewertung. Die Europäische Kommission stellt dazu Übersichten und Umsetzungshinweise bereit.

Für Open-Source-Projekte lautet die Frage deshalb nicht „Betrifft uns der CRA überhaupt?“, sondern: Wer ist Hersteller des Produkts? Wird das Projekt als Produkt in Verkehr gebracht oder nur von einer Community gepflegt? Und wer trägt die Pflichten, wenn eine kommerzielle Anwendung die Bibliothek einbaut?

Die Open-Source-Ausnahme: außerhalb einer kommerziellen Tätigkeit

Der CRA enthält eine wichtige Ausnahme: Free and Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit bereitgestellt wird, fällt grundsätzlich nicht unter die Produktanforderungen. Geschützt ist die klassische Community-Arbeit: ein öffentliches Repository, eine freie Lizenz, freiwillige Beiträge und keine Vergütung für die Software als solche.

Schwierig wird es an den Rändern. Kommerzielle Tätigkeit heißt nicht nur, dass für das Programm selbst eine Lizenzgebühr verlangt wird. Auch ein bezahlter Support-Vertrag, eine gehostete Version, ein Premium-Feature, Dual-Licensing oder die Einbettung in ein kostenpflichtiges Produkt können die Einordnung verändern. Ein Sponsor-Hinweis im Repository allein macht aus Community-Pflege noch keine kommerzielle Tätigkeit, solange die Software kostenlos und quelloffen bleibt.

Am Ende entscheidet also nicht die Lizenz, sondern die Tätigkeit rund um die Software. Gerade bei Projekten, die von mehreren Personen oder Organisationen getragen werden, lohnt es sich, aufzuschreiben, was reine Community-Arbeit ist – und wo eine kommerzielle Dienstleistung beginnt.

Wer ist Open-Source-Steward?

Eine Schlüsselrolle des CRA ist der Open-Source-Steward. Gemeint ist eine juristische Person, die eine Open-Source-Software-Community dauerhaft unterstützt und ihre Belange gegenüber Herstellern, Behörden und Anwendern organisiert. Anders als Hersteller bringt der Steward kein Produkt auf den Markt. Seine Aufgabe ist die Governance der Community und die strukturierte Unterstützung von Entwicklungsarbeit, die kommerziell genutzten Projekten zugutekommt.

Der Steward kann etwa für ein Framework, eine Plattform oder eine Stiftung Verantwortung übernehmen. Wer diese Funktion ausübt, muss eine eigene Cybersicherheitspolitik etablieren, mit Aufsichtsbehörden zusammenarbeiten und Meldepflichten für schwere Sicherheitsvorfälle beachten. Das Pflichtenregime ist bewusst leichter als das der Hersteller, aber eben nicht pflichtenfrei. Für viele Stiftungen und Open-Source-Organisationen wird die Selbsteinordnung daher zur strategischen Frage.

OSS im Produkt: Die Integratorin bleibt verantwortlich

Für die Praxis ist die wichtigste Botschaft: Die Open-Source-Ausnahme schützt die Community, nicht das Produkt. Wer eine quelloffene Komponente in ein Produkt mit digitalen Elementen integriert, ist für die Cybersicherheit des Endprodukts verantwortlich. Die Integratorin behandelt das Produkt als Herstellerin: Risikobewertung, Sicherheitsupdates, Schwachstellenmanagement, technische Dokumentation und gegebenenfalls Konformitätsbewertung.

Das ist kein Freibrief, die Lieferkette zu ignorieren. Im Gegenteil: Die Verantwortung für das Produkt bedeutet, dass Open-Source-Bausteine in das Sicherheitskonzept des Produkts einbezogen werden müssen. Dazu gehört eine nachvollziehbare Bestandsaufnahme der eingesetzten Komponenten und die Fähigkeit, eine Schwachstelle im verwendeten OSS dem eigenen Produkt zuzuordnen und zu behandeln.

SBOM: Open-Source-Anteile sichtbar machen

Die Software Bill of Materials (SBOM) wird zum zentralen Werkzeug. Sie dokumentiert die Bestandteile eines Softwareprodukts und macht sichtbar, welche Open-Source-Komponenten in welcher Version verwendet werden. Daraus entsteht keine Pflicht zur Offenlegung des gesamten Internen, aber eine Pflicht zur Beherrschung der Lieferkette.

Für die Compliance-Bewertung hilft die SBOM an mehreren Stellen: beim Erkennen bekannter Schwachstellen, bei der Beantwortung von Kundenanfragen, bei der technischen Dokumentation und bei der Reaktion auf Sicherheitsvorfälle. Wer die SBOM nicht nur der Form nach erzeugt, sondern in den Entwicklungsprozess einbaut, reduziert zugleich das Risiko ungeprüfter Fremdkomponenten.

Meldepflichten ab dem 11. September 2026

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts melden. Für Open Source liegt die zentrale Frage darin, ob das betroffene Projekt als Teil eines Produkts auf dem Markt angeboten wird oder ob es sich um reine Community-Software handelt. Im Produktkontext trifft die Pflicht die Herstellerin des Endprodukts.

Für Open-Source-Stewards gelten besondere, an ihre Rolle angepasste Pflichten. Sie müssen insbesondere über eine eigene Cybersicherheitspolitik verfügen und mit den zuständigen Behörden zusammenarbeiten. Die genaue Ausgestaltung sollte frühzeitig geprüft werden, weil eine nachträgliche Einordnung im Ernstfall zu langsam ist.

Checkliste: In sieben Schritten zur CRA-Einordnung

Die folgenden Schritte helfen, die eigene Rolle und die Open-Source-Bausteine des Portfolios strukturiert zu erfassen.

1. Produktportfolio aufnehmen: Welche Produkte mit digitalen Elementen werden auf den EU-Markt gebracht?
2. Open-Source-Komponenten identifizieren: Welche Bibliotheken, Frameworks, Laufzeitumgebungen und Images sind enthalten?
3. Rolle prüfen: Handeln Sie als Community-Maintainer, Produktherstellerin oder Open-Source-Steward?
4. Kommerzielle Tätigkeit abgrenzen: Welche Angebote führen dazu, dass Software nicht mehr außerhalb einer kommerziellen Tätigkeit bereitgestellt wird?
5. SBOM-Prozess etablieren: Sichtbarkeit über Komponenten und Versionen schaffen, Schwachstellenabgleich einbinden.
6. Sicherheits- und Meldeprozesse vorbereiten: Wer bewertet Vorfälle, wer meldet ab September 2026, wie wird eskaliert?
7. Dokumentation aufbauen: Risikobewertung, Supportzeitraum und Konformitätsmaßnahmen für das Produkt belegen.

Einordnung in die deutsche und europäische Compliance-Landschaft

Der CRA ist nicht isoliert zu betrachten. Er ergänzt die NIS2-Umsetzung in Bezug auf Produkte und verbindet sich mit der Produkthaftung sowie der KI-Verordnung. Die SBOM-Diskussion, die sich aus dem CRA ergibt, betrifft zugleich das Lieferkettenmanagement, die Informationssicherheit und die Vertragsgestaltung mit Kunden und Zulieferern.

Für deutsche Unternehmen heißt das: Die Open-Source-Einordnung sollte Teil des bestehenden Compliance-Managements werden, nicht ein isoliertes IT-Projekt. Wer Open Source nutzt, braucht klare Verantwortlichkeiten und einen dokumentierten Prozess. Nur so lässt sich im Ernstfall belegen, dass das Unternehmen seine Produktverantwortung ernst nimmt.

Fazit

Open Source ist kein Freibrief und kein Automatismus, sondern eine Frage der Marktrolle. Community-Arbeit außerhalb einer kommerziellen Tätigkeit profitiert von der CRA-Ausnahme. Sobald quelloffene Software in ein Produkt integriert oder zur Grundlage kommerzieller Angebote wird, entstehen Hersteller- oder Steward-Pflichten. Wer jetzt Produktportfolio, Rollen und SBOM-Prozesse klärt, vermeidet mit Blick auf September 2026 böse Überraschungen.