Nach teils erheblicher Kritik aus der Open Source Community an dem Kommissionsentwurf zum Cyber Resilience Act, wurde die Verordnung erheblich überarbeitet und der besonderen Rolle von Open Source Software in der modernen Softwareentwicklung weitergehend Rechnung getragen.
Einerseits werden Open Source Komponenten in nahezu allen Softwareprojekten eingesetzt, andererseits besteht dort ein wesentliches Risiko für Sicherheitslücken, insbesondere bei Open Source Projekten, die keine aktive Entwicklercommunity besitzen oder von einzelnen Maintainern betreut werden. Der Open Source Security and Risk Analysis Report 2024 von Synopsys zeigt dies anschaulich.
Die konsolidierte Version des CRA, der das Europäische Parlament am 12. März 2024 zugestimmt hat, ist deutlich stärker bezogen auf die Besonderheiten des Open Source Entwicklungsmodells und regelt an verschiedenen Stellen explizit die Verwendung von Open Source Software:
Erwägungsgrund 17 der CRA streicht zunächst die Bedeutung und Förderungswürdigkeit von Open Source Software heraus:
„Software und Daten, die offen geteilt werden und die Nutzer frei abrufen, nutzen, verändern und weiter verteilen können, auch in veränderter Form, können zu Forschung und Innovation auf dem Markt beitragen. Zur Förderung der Entwicklung und des Einsatzes von freier und quelloffener Software, insbesondere durch Kleinstunternehmen sowie kleine und mittlere Unternehmen, einschließlich Start-up-Unternehmen, Einzelpersonen, gemeinnützige Organisationen und akademische Forschungseinrichtungen, sollte bei der Anwendung dieser Verordnung auf Produkte mit digitalen Elementen, die als freie und quelloffene Software eingestuft und zum Vertrieb oder zur Nutzung im Rahmen einer Geschäftstätigkeit bereitgestellt werden, die Arten der verschiedenen Entwicklungsmodelle für Software berücksichtigt werden, die im Rahmen von Lizenzen für freie und quelloffene Software vertrieben und entwickelt wird.“
Art. 3 Nr. 48 CRA enthält eine Definition von „free and open-source software“, die weitgehend der Definition der Open Source Initiative und der Free Software Definition der FSF entspricht, aber stärker das öffentliche Entwicklungsmodell betont:
„Unter freier und quelloffener Software ist eine Software zu verstehen, deren Quellcode offen geteilt wird und in deren Lizenz alle erforderlichen Rechte vorgesehen sind, um sie frei zugänglich, nutzbar, veränderbar und weiterverteilbar zu machen.“
Erwägungsgrund 18 CRA ergänzt diese Definition wie folgt:
„Freie und quelloffene Software wird offen entwickelt, gepflegt und verteilt, auch über Online-Plattformen.“
Diese Betonung des Entwicklungsmodells hat ihren Grund darin, dass allgemein zugängliche Open Source Repositorien von dem Anwendungsbereich der Verordnung ausgenommen werden und die Pflichten daraus erst zu erfüllen sind, wenn Open Source als Bestandteil eines „Produkts mit digitalen Elementen“ kommerziell genutzt wird (siehe Erwägungsgrund 18 CRA).
Demnach sind auch von Unternehmen betriebene Entwicklungsprojekte von der Verordnung freigestellt, aber Anbieter von kommerziell vertriebenen Produkten müssen die Pflichten aus der Verordnung erfüllen und zwar unabhängig davon, ob die eingesetzte Software als Open Source Software lizenziert ist oder nicht.
Besonders wurde hinsichtlich des Kommissionsentwurfs diskutiert, inwiefern Organisationen wie zum Beispiel die Eclipse Foundation, der KDE e.V. und die Apache Foundation vom CRA betroffen sind. Diese werden zum Teil von Unternehmen finanziert, haben aber selbst keine Gewinnerzielungsabsicht. In dem englischen Text ist hier von „non-for-profit organisations“ die Rede, im deutschen Text von „gemeinnützigen Organisationen“, was wohl nicht auf eine Gemeinnützigkeit im steuerrechtlichen Sinne verengt werden darf. Erwägungsgrund 18 verdeutlicht, dass solche Organisationen vom Anwendungsbereich ausgenommen werden sollen:
„Schließlich sollte für die Zwecke dieser Verordnung die Entwicklung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft werden, durch gemeinnützige Organisationen nicht als kommerzielle Tätigkeit betrachtet werden, sofern die Organisation so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden. Diese Verordnung gilt nicht für natürliche oder juristische Personen, die mit Quellcode zu Produkten mit digitalen Elementen beitragen, die als freie und quelloffene Software eingestuft sind und nicht ihrer Verantwortung unterliegen.“
Allerdings sind von diesen „non-for-profit organisations“, die „open-source stewards“ (Verwalter quelloffener Software) abzugrenzen, die nach Art. 24 CRA eigene Pflichten haben. Ein „open-source steward“ wird gem. Art. 3 Nr. 14 CRA als juristische Person definiert, “bei der es sich nicht um einen Hersteller handelt, die den Zweck oder das Ziel hat, die Entwicklung spezifischer Produkte mit digitalen Elementen, die als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig zu unterstützen, und die die Vermarktbarkeit dieser Produkte sicherstellt.“ Sonderlich klar erscheint diese Abgrenzung nicht. Allerdings hat sich die Eclipse Foundation mit einigen anderen „Foundations“ aus der Open Source Welt zusammengeschlossen, um gemeinsame Sicherheitsstandards zu entwickeln. Hier hat man die Rolle als „open-source steward“ offenbar angenommen.
Art. 9 des CRA sieht vor, dass die „Open Source Community“ als Stakeholder bei der Durchführung der Verordnung von der Kommission zu konsultieren ist. Dies ist nicht nur eine erhebliche Aufwertung der Open Source Entwickler, sondern sichert auch Einfluss bei den Umsetzungsakten. Allerdings dürfte es schwer sein, eine so heterogene Gruppe wie die „Open Source Community“ konkret einzubinden. Voraussichtlich werden hier die „gemeinnützigen Organisationen“ und die in Art. 24 genannten „Verwalter quelloffener Software“ („open-source software stewards“) eine wichtige Rolle spielen.
Die Überschrift zu Kapitel II (Art. 13 ff.) CRA, das die Verhaltenspflichten regelt, wurde um einen Hinweis auf Open Source ergänzt: „PFLICHTEN DER WIRTSCHAFTSAKTEURE UND BESTIMMUNGEN IN BEZUG AUF FREIE UND QUELLOFFENE SOFTWARE“
Marktüberwachungsbehörden aus den Mitgliedstaaten sollen eine „Gruppe zur administrativen Zusammenarbeit (ADCO) für die Cyber-Resilienz von Produkten mit digitalen Elementen“ bilden. Die ADCO ist wiederum gem. Art. 13 Abs. 25 befugt, von den Herstellern bestimmter Kategorien von Produkten mit digitalen Elementen sog. SBOMs („Software-Stücklisten“) mit der verwendeten Open Source Software zu verlangen. Die Kenntnis von der verwendeten Open Source Software ist damit nicht nur ein wesentlicher Bestandteil der FOSS License Compliance, sondern wird künftig auch im Rahmen des CRA notwendig sein. Die Blackbox-Nutzung von Open Source Software soll damit der Vergangenheit angehören.
Schließlich wurden zwei neue Artikel in die konsolidierte Fassung des CRA eingefügt. Art. 24 CRA regelt die Pflichten von „open-source stewards“, die eine „Cybersicherheitsstrategie“ entwickeln müssen:
„Verwalter quelloffener Software entwickeln und dokumentieren auf überprüfbare Weise eine Cybersicherheitsstrategie, um die Entwicklung eines sicheren Produkts mit digitalen Elementen sowie einen wirksamen Umgang mit Schwachstellen durch die Entwickler dieses Produkts zu fördern. Diese Strategie fördert auch die freiwillige Meldung von Schwachstellen gemäß Artikel 15 durch die Entwickler dieses Produkts und trägt den Besonderheiten des Verwalters quelloffener Software und den rechtlichen und organisatorischen Vorkehrungen, denen er unterliegt, Rechnung. Diese Strategie umfasst insbesondere Aspekte im Zusammenhang mit der Dokumentation, Behebung und Beseitigung von Schwachstellen und fördert den Austausch von Informationen über aufgedeckte Schwachstellen innerhalb der Open-Source-Gemeinschaft.“
Die Kontrolle obliegt gem. Art. 52 Nr. 3 CRA den Marktüberwachungsbehörden; allerdings sind diese gem. Art. 64 Nr. 10(b) CRA von der Möglichkeit, Geldbußen zu verhängen, ausgenommen,
Nach Art. 25 kann die Kommission durch delegierte Rechtsakte Sicherheitsbescheinigungen für Open Source Software erlassen. Wie diese freiwilligen Programme zur Sicherheitskonformität aussehen werden, bleibt abzuwarten. Es ist aber davon auszugehen, dass hier die die open-source stewards mit der Kommission zusammenarbeiten werden.
Der CRA ist damit ein Meilenstein bei der regulatorischen Berücksichtigung von Open Source Software und reflektiert die enorme Bedeutung von Open Source Software in der modernen Softwareentwicklung.
Bild: mit KI generiert über Dall-E