Cyber Resilience Act stellt Hersteller digitaler Produkte vor Herausforderungen: Neue Spielregeln für Open Source

Schon seit die Europäische Kommission den Cyber Resilience Act 2022 in Gang gebracht hat, sorgt er für erhitzte Gemüter zwischen Politik, Wirtschaft und Verbänden. Unternehmen haben nun bis Dezember 2027 eine Übergangsfrist, um sich auf die neuen regulatorischen Anforderungen einzustellen. Ab September 2026 greift sogar schon die Berichtspflicht, etwa bei Vorfällen oder Schwachstellen – es bleibt also nicht viel Zeit. In vielen Punkten herrscht allerdings noch Klärungsbedarf.

Das bekomme ich als Vertreter von Stackable in der Expertengruppe der Europäischen Kommission an vorderster Front mit. Der Cyber Resilience Act der Europäischen Union markiert einen Wendepunkt in der europäischen Digitalgesetzgebung. Ziel ist es, verbindliche Cybersicherheitsstandards für Produkte mit digitalen Elementen zu schaffen – von Software über IoT-Geräte bis hin zu industriellen Steuerungssystemen.

Dabei stehen nicht nur klassische Softwarehersteller im Fokus, sondern auch Open-Source-Projekte, Plattformen, Integratoren und Anwenderunternehmen. Die zentrale Herausforderung: Wie lässt sich ein Gesetz, das von klaren Herstellungs- und Vertriebsstrukturen ausgeht, auf ein Ökosystem anwenden, das von Freiwilligen, Dezentralität und kollaborativer Entwicklung geprägt ist?

Der CRA unterteilt Produkte in drei Kategorien: default, important und critical. Alle Produkte müssen grundlegende Anforderungen erfüllen – etwa Schwachstellenmanagement, Sicherheitsupdates, technische Dokumentation und Risikoanalysen.

Lösungen der höheren Risikoklassen, important und critical, benötigen zudem eine externe Zertifizierung. Was in der Theorie nach einer sinnvollen Abstufung klingt, wirft in der Praxis eine Reihe von Problemen auf – besonders, weil viele Produkte nicht klar einer Kategorie zugeordnet werden können und es noch an rechtlich eindeutigen Kriterien mangelt, wie ein solches Produkt überhaupt klassifiziert wird.

Verantwortlichkeit als Kernproblem für Open Source

Ein zentrales Problem für Open-Source-Projekte ist die Frage der Verantwortlichkeit. Wer als Maintainer eine Bibliothek pflegt, wird möglicherweise als Hersteller eingestuft, wenn dies in einem kommerziellen Kontext geschieht und Geld damit verdient wird – mit allen rechtlichen Pflichten. Diese Verantwortung lässt sich kaum erfüllen, wenn das Projekt auf Freiwilligenarbeit basiert.

Wer ist bei einer Schwachstelle verantwortlich? Der ursprüngliche Autor, der aktuelle Maintainer, der Paketbetreiber – oder am Ende derjenige, der das Gesamtpaket integriert? In der Praxis könnte dies dazu führen, dass Entwicklerinnen und Entwickler ihre Projekte nicht mehr veröffentlichen oder pflegen – aus Angst vor regulatorischen Konsequenzen

Ein weiteres Spannungsfeld ergibt sich aus der CRA-Forderung nach fortlaufendem Support und Updates über den gesamten Produktlebenszyklus. Doch viele Open-Source-Komponenten sind Ein-Personen-Projekte oder werden von kleinen Teams gepflegt. Die Erwartung, langfristig Sicherheitsupdates zu garantieren, steht im Widerspruch zur realen Kapazität vieler Maintainer.

Unklar Grenzen bei Monetarisierung

Viel hängt also davon ab, ob mit einem Projekt Geld verdient wird oder nicht. Aber genau hier gibt es noch zahlreiche offene Fragen. Bin ich Hersteller, wenn ich um Spenden werbe? Oder muss Geld fließen? Gelten meine Lebensunterhaltskosten schon zum „Verdienen“ oder nicht? Was, wenn ich Support anbiete für ein Projekt, bei dem ich nicht Maintainer bin? Wie sieht es aus, wenn sich das aber später ändert und man mich zu einem Maintainer macht? Was ist überhaupt ein Maintainer? Ist reiner Quellcode ein Produkt oder wird es das erst durch die Verbreitung von Binaries? Und wie behandeln wir dann interpretierte Sprachen?

Viele dieser Fragen sind bislang offen. Zwar soll die angekündigte EU-Guidance künftig für mehr Orientierung sorgen, doch bis dahin bleibt ein gewisses Maß an Unsicherheit bestehen.

Software Bill of Materials als neue Anforderung

Eine der zentralen Anforderungen des CRA ist die Einführung einer Software Bill of Materials (SBOM). Sie soll offenlegen, aus welchen Komponenten ein Produkt besteht. Das ist sinnvoll, und im Open-Source-Bereich zudem leichter umzusetzen als bei proprietärer Software, weil sich alle Informationen einsehen lassen. Dennoch besteht auch hier Unsicherheit durch viele offene Detailfragen.

Wird ein SBOM-Format vorgeschrieben? Gibt es bestimmte verpflichtende Elemente? Bis zu welcher Tiefe muss ich eine SBOM liefern und an wen? Letztlich gibt es leider auch keine eindeutigen Standards zur Identifikation von Software.

Unternehmen, die Open Source nutzen – ob als Teil eigener Produkte oder als Infrastruktur – sind ebenfalls in der Pflicht. Sie müssen künftig dokumentieren, welche Komponenten benutzt werden, wie Sicherheitsupdates integriert werden und wie auf Schwachstellen reagiert wird.

Die Zeiten, in denen Open Source einfach so verwendet wurde, ohne Governance-Strukturen, sind vorbei. Der CRA macht die Open-Source-Nutzung zu einer Compliance-Frage – mit direktem Einfluss auf Risiko, Haftung und unternehmerische Verantwortung.

Besonders kleine und mittlere Unternehmen stehen damit unter Druck. Sie verfügen oft nicht über eigene Security-Teams. Die EU-Kommission ist gefordert, für diesen Bereich realistische Umsetzungshilfen zu schaffen, etwa durch standardisierte Templates, geförderte Beratung oder zentrale Zertifizierungsstellen. Zudem müssen die Plattformen einbezogen werden:

GitHub, GitLab, Maven Central oder PyPI haben eine Schlüsselrolle in der Open-Source-Verbreitung. Sie könnten helfen, SBOMs zu standardisieren, Sicherheitswarnungen zu verbreiten und Verwaltungsinformationen (Stewardship-Informationen) sichtbar zu machen – ohne selbst zu Herstellern zu werden.

Handlungsempfehlungen für Unternehmen

Damit der CRA sein Ziel nicht verfehlt, braucht es eine differenzierte Umsetzung. Unternehmen, die Open Source nutzen, müssen ihre interne Governance professionalisieren – mit SBOM-Tools, Patch-Strategien und klaren  Verantwortlichkeiten.

Gleichzeitig sollte die EU gezielt Strukturen fördern, die Open-Source-Projekte bei der Umsetzung des CRA unterstützen – etwa durch Rechtshilfen, Audit-Tools oder Koordinationsstellen. Die Community ist bereit, Verantwortung zu übernehmen – sie braucht dafür aber verlässliche Rahmenbedingungen und Unterstützung.

Unternehmen, die Open Source einsetzen, sollten jetzt aktiv werden. Zunächst gilt es, Transparenz zu schaffen: Welche Open-Source-Komponenten sind im Einsatz? Wer ist intern verantwortlich für deren Integration, Pflege und Aktualisierung? Eine dokumentierte Übersicht, idealerweise unterstützt durch automatisierte Werkzeuge zur SBOM-Erstellung, ist ein erster wichtiger Schritt.

Darüber hinaus sollten Prozesse definiert werden, wie auf entdeckte Schwachstellen reagiert wird, etwa mit klaren Zuständigkeiten, Zeitvorgaben und Kommunikationswegen. Für sicherheitskritische Systeme empfiehlt sich ein regelmäßiger Abgleich mit bekannten Sicherheitsdatenbanken wie der CVE-Datenbank oder EUVD sowie gegebenenfalls ein Notfallplan für Patches und Updates.

Auch die Zusammenarbeit mit den Open-Source-Communities sollte aktiv gepflegt werden. Unternehmen, die auf freie Software setzen, sollten sich nicht nur als Nutzer, sondern als Partner begreifen – etwa durch Bug-Reports, Code-Reviews oder gezielte finanzielle Unterstützung. Denn nur ein stabiles, resilientes Open-Source-Ökosystem kann langfristig den regulatorischen Anforderungen standhalten.

Schließlich lohnt es sich, das eigene Compliance-Management auf den Prüfstand zu stellen. Viele Anforderungen des CRA lassen sich mit bestehenden Strukturen aus der IT-Sicherheitszertifizierung oder dem Datenschutzmanagement verknüpfen – vorausgesetzt, sie werden bewusst integriert und nicht als paralleles System aufgebaut. So wird aus der regulatorischen Pflicht ein unternehmerischer Vorteil.

Der Cyber Resilience Act wird die Sicherheitsstrategie der Europäischen Union entscheidend stärken. Unser oberstes Ziel in der Expertengruppe der Europäischen Kommission ist es aktuell, einen für alle Seiten zufriedenstellenden Mittelweg zwischen Effizienz und Bürokratie zu finden. Das Gerüst steht, und in den kommenden Monaten werden wir uns intensiv mit allen offenen Fragen beschäftigen. Das Ziel ist klar: ein Europa, das sicher, wettbewerbsfähig und auf die Zukunft vorbereitet ist.