Der Cyber Resilience Act und seine Auswirkungen auf Open-Source-Software

Der Cyber Resilience Act (CRA) der Europäischen Union ist eine Initiative zur Verbesserung der Cybersicherheit von Produkten mit digitalen Elementen. In diesem Beitrag betrachten wir speziell die Auswirkungen auf Open-Source-Software (FOSS) und die Rolle der "Open Source Software Stewards".

Inhalt

1. Besondere Behandlung von FOSS im CRA
2. Wer ist betroffen?
3. Die Rolle des "Open Source Software Stewards"
4. Verpflichtungen für Verwalter quelloffener Software
5. Risikokategorisierung von Produkten
6. Einordnung und Ausblick

Besondere Behandlung von FOSS im CRA

Der CRA erkennt die besondere Rolle und Bedeutung von Open-Source-Software an. Entscheidend ist zunächst, ob eine FOSS überhaupt in den Anwendungsbereich fällt: Maßgeblich ist, ob sie im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird. Wo der CRA greift, richtet sich die Art der Konformitätsbewertung nach der Produktkategorie und nicht nach dem Open-Source-Status. Für die meisten Produkte genügt die interne Konformitätskontrolle (Modul A); für kritische Produkte gelten dieselben strengeren Verfahren wie für proprietäre Produkte. Für wichtige Produkte dürfen Hersteller freier und quelloffener Software jedes Verfahren wählen, auch die interne Kontrolle (Modul A), wenn sie die technische Dokumentation beim Inverkehrbringen öffentlich zugänglich machen.

Wer ist betroffen?

Um zu verstehen, ob und wie ein Open-Source-Projekt vom CRA betroffen ist, betrachten wir das folgende Diagramm:

Erläuterung der wichtigsten Punkte:

1. Bereitstellen vs. Beitragen: Der CRA unterscheidet zwischen dem Bereitstellen von FOSS unter eigener Verantwortung und dem bloßen Beitragen, etwa einzelnen Code-Beiträgen ohne Kontrolle über die Veröffentlichung. Wer nur beiträgt, ohne die Verantwortung für das Produkt zu tragen, fällt nicht in den Anwendungsbereich. Pflichten löst erst die Bereitstellung auf dem Markt im Rahmen einer Geschäftstätigkeit aus.
2. Direkte Monetarisierung: FOSS-Anbieter, die direkt damit Geld verdienen, werden als "Hersteller" im Sinne des CRA betrachtet.
3. Unterstützung für kommerzielle Aktivitäten: Juristische Personen, die auf dauerhafter Basis die Entwicklung von FOSS-Produkten für kommerzielle Aktivitäten unterstützen, ohne sie direkt zu monetarisieren, fallen in die Kategorie Verwalter quelloffener Software.
4. Bereitstellung auf dem Markt zählt, nicht die Entwicklung: Für den Herstellerstatus kommt es nicht darauf an, unter welchen Umständen oder mit welcher Finanzierung eine FOSS entwickelt wurde. Maßgeblich ist allein, ob sie im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird. Erst diese Bereitstellung macht aus einem Anbieter einen Hersteller im Sinne des CRA.

Die Rolle des "Open Source Software Stewards"

Der CRA führt den Begriff des "Open Source Software Stewards" ein, auf Deutsch der "Verwalter quelloffener Software". Gemeint ist eine juristische Person, die kein Hersteller ist und die die Entwicklung von Open-Source-Software, die für kommerzielle Tätigkeiten bestimmt ist, systematisch und nachhaltig unterstützt und deren Brauchbarkeit sicherstellt. Kennzeichnend ist, dass die Software zwar veröffentlicht, aber nicht selbst auf dem Markt bereitgestellt wird. Für solche Verwalter gilt ein leichterer regulatorischer Ansatz. Beispiele sind:

• Stiftungen, die die Entwicklung kommerziell genutzter FOSS-Projekte dauerhaft unterstützen
• Gemeinnützige Organisationen, die solche FOSS-Projekte nachhaltig pflegen und ihre Brauchbarkeit sicherstellen

Verpflichtungen für Verwalter quelloffener Software

Die Verpflichtungen für Verwalter quelloffener Software sind weniger umfangreich als für "Hersteller", umfassen aber dennoch wichtige Punkte:

1. Cybersicherheitsstrategie: Verwalter müssen eine Cybersicherheitsstrategie einführen, die der spezifischen Natur ihrer Rolle Rechnung trägt und die freiwillige Meldung von Schwachstellen fördert (Art. 24 Abs. 1). Sie sollte die besonderen Herausforderungen und Risiken adressieren, die mit der Entwicklung und Bereitstellung von Open-Source-Software verbunden sind.
2. Zusammenarbeit mit Behörden: Verwalter müssen auf Verlangen mit den Marktüberwachungsbehörden zusammenarbeiten (Art. 24 Abs. 2). Dies kann Anfragen zu Sicherheitsaspekten der Software, Bereitstellung von Informationen oder Unterstützung bei Untersuchungen umfassen.
3. Meldung von Schwachstellen und Vorfällen: Verwalter müssen aktiv ausgenutzte Schwachstellen melden, soweit sie an der Entwicklung der betroffenen Produkte beteiligt sind. Schwerwiegende Sicherheitsvorfälle sind zu melden, soweit die vom Verwalter für die Entwicklung bereitgestellten Systeme betroffen sind. Gemeldet wird an das zuständige CSIRT und die ENISA über die einheitliche Meldeplattform. Das fördert die Transparenz und ermöglicht eine schnellere Reaktion auf Sicherheitsrisiken.

Risikokategorisierung von Produkten

Der CRA sieht eine Risikokategorisierung für Produkte mit digitalen Elementen vor:

• Standardkategorie: Hierunter fallen die meisten Produkte mit digitalen Elementen und damit auch viele FOSS-Projekte. Der Hersteller bewertet die Konformität selbst.
• Wichtige Produkte: Hier ist die vollständige Anwendung harmonisierter Normen oder die Einbindung einer benannten Stelle vorgesehen. Beispiele sind Betriebssysteme, Software zur Suche, Entfernung und Quarantäne von Schadsoftware (Virenschutz), Router, Modems und Switches sowie, in der höheren Klasse, Firewalls.
• Kritische Produkte: Für diese Kategorie kann die Kommission künftig ein europäisches Cybersicherheitszertifikat verlangen. Beispiele sind Chipkarten und ähnliche Geräte einschließlich Sicherheitselemente sowie Smart-Meter-Gateways.

Wichtig ist: Ob die interne Konformitätskontrolle (Modul A) genügt, hängt von der Produktkategorie ab und nicht vom Open-Source-Status. Für kritische Produkte gelten die strengeren Bewertungsverfahren auch dann, wenn es sich um FOSS handelt. Für wichtige Produkte gibt es eine Ausnahme: Hersteller freier und quelloffener Software dürfen hier jedes Verfahren wählen, auch die interne Kontrolle (Modul A), wenn sie die technische Dokumentation beim Inverkehrbringen öffentlich zugänglich machen.

Weitere Informationen zur Konformitätsbewertung gibt es in unserem ausführlichen Artikel zum Cyber Resilience Act.

Einordnung und Ausblick

Der CRA versucht, einen ausgewogenen Ansatz für Open-Source-Software zu finden. Während kommerzielle FOSS-Anbieter ähnlichen Verpflichtungen wie proprietäre Softwarehersteller unterliegen, gibt es für nicht-kommerzielle FOSS-Projekte und -Unterstützer einen leichteren regulatorischen Ansatz. Die Hauptpflichten des CRA gelten ab dem 11. Dezember 2027. Die Meldepflichten der Hersteller gelten seit dem 11. September 2026; Verwalter quelloffener Software trifft die Meldepflicht nach Artikel 24 Absatz 3 erst ab dem 11. Dezember 2027.

Die Einführung der Kategorie des Open Source Software Stewards bzw. des Verwalters quelloffener Software zeigt, dass der Gesetzgeber die besondere Rolle und Bedeutung von FOSS anerkennt und versucht, unnötige Belastungen zu vermeiden. Dennoch werden auch von FOSS-Projekten gewisse Maßnahmen zur Gewährleistung der Cybersicherheit erwartet.

FOSS-Entwickler und -Organisationen sollten sich mit den Anforderungen des CRA vertraut machen und prüfen, in welche Kategorie sie fallen. Insbesondere sollten sie die Entwicklung einer angemessenen Cybersicherheitsrichtlinie in Betracht ziehen und Prozesse für die Zusammenarbeit mit Behörden sowie für die Meldung von Sicherheitsvorfällen etablieren.