Was Unternehmen und Organisationen im Open-Source-Umfeld jetzt wissen müssen
Im CRA hat der europäische Gesetzgeber erstmals horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen auf dem EU-Binnenmarkt geschaffen. Neben umfassenden Pflichten für Hersteller führt der CRA eine in der europäischen Produktregulierung völlig neuartige Figur ein: den Open Source Software Steward. Dieser Beitrag erläutert anhand des Verordnungstextes und der im März 2026 veröffentlichten Kommissions-Guidance (Entwurf), was es mit dieser Rolle auf sich hat, wie sie sich vom Hersteller abgrenzt und welche Pflichten damit verbunden sind.
Warum eine Sonderkategorie für Open Source?
Freie und quelloffene Software (Free and Open Source Software = FOSS) bildet einen wesentlichen Baustein der digitalen Infrastruktur in Europa. Zahlreiche kommerzielle Produkte, von Betriebssystemen über Cloud-Dienste bis hin zu eingebetteten Systemen, basieren auf Open-Source-Komponenten. Der CRA erkennt diese Bedeutung ausdrücklich an und unterscheidet daher bewusst zwischen Akteuren, die FOSS kommerziell auf den Markt bringen (Hersteller), und solchen, die ihre Entwicklung und Lebensfähigkeit unterstützen, ohne die Software selbst kommerziell zu vertreiben.
Diese Differenzierung trägt dem Umstand Rechnung, dass eine Gleichbehandlung von Open-Source-Stiftungen und kommerziellen Softwareunternehmen die ehrenamtliche und gemeinnützige Arbeit an kritischer digitaler Infrastruktur durch unverhältnismäßige regulatorische Lasten gefährden könnte. Der CRA wählt daher einen abgestuften Regulierungsansatz.
Wer ist ein Open Source Steward?
Art. 3 Nr. 14 CRA definiert den Open Source Software Steward als eine juristische Person, ausdrücklich keine natürliche Person, die kumulativ folgende Voraussetzungen erfüllt: Sie ist kein Hersteller, ihr Zweck oder Ziel besteht darin, auf dauerhafter Basis systematisch die Entwicklung bestimmter Produkte mit digitalen Elementen zu unterstützen, die als FOSS gelten und für kommerzielle Tätigkeiten bestimmt sind, und sie stellt die Lebensfähigkeit dieser Produkte sicher.
Typische Erscheinungsformen sind Open-Source-Stiftungen wie die Eclipse Foundation, die Apache Software Foundation oder die Linux Foundation, aber auch andere Non-Profit-Organisationen, die FOSS-Infrastruktur bereitstellen. Die Kommissions-Guidance (Rn. 72) konkretisiert, dass die dauerhafte, systematische Unterstützung insbesondere das Hosting und Verwalten von Entwicklungsplattformen, das Hosten von Quellcode, die Governance von FOSS-Projekten sowie das Steuern der Produktentwicklung umfassen kann.
Die zentrale Abgrenzung zum Hersteller
Die Unterscheidung zwischen Hersteller und Steward ist die Kernfrage der regulatorischen Einordnung. Sie lässt sich auf eine einfache Formel bringen: Ein Hersteller bringt ein Produkt mit digitalen Elementen im Rahmen einer kommerziellen Tätigkeit auf den EU-Markt, sei es entgeltlich oder unentgeltlich, sofern eine Monetarisierung erfolgt. Ein Steward hingegen bringt die FOSS gerade nicht selbst auf den Markt, sondern unterstützt lediglich deren Entwicklung.
Die Kommissions-Guidance legt eine vierstufige Prüfungslogik nahe:
- Zunächst ist zu klären, ob es sich bei der FOSS überhaupt um ein Produkt mit digitalen Elementen handelt.
- Dann ist zu prüfen, ob die FOSS unter der Verantwortung der betreffenden Person steht, bloße Contributors, die einzelne Codebeiträge leisten, fallen nicht unter den CRA.
- Anschließend ist zu fragen, ob ein kommerzielles Inverkehrbringen vorliegt, etwa durch die Erhebung eines Preises, durch Monetarisierung über Datenverarbeitung oder durch kostenpflichtige Enterprise-Versionen.
Liegt keine kommerzielle Tätigkeit vor, die juristische Person unterstützt aber dauerhaft und systematisch eine für kommerzielle Zwecke bestimmte FOSS, handelt es sich um einen Steward.
Besonders praxisrelevant ist, dass dieselbe juristische Person gleichzeitig Steward für eine bestimmte FOSS und Hersteller für eine andere sein kann. Die Einordnung erfolgt stets produktbezogen, nicht personenbezogen. Ein Unternehmen, das eine Community-Version betreut, kann daher zugleich als Hersteller seiner monetarisierten Enterprise-Version gelten.
Pflichten des Stewards – der abgespeckte Regulierungsrahmen
Im Gegensatz zum Hersteller, der das volle Pflichtenprogramm des CRA erfüllen muss, einschließlich CE-Kennzeichnung, Konformitätsbewertung, technischer Dokumentation, SBOM und umfassender Meldepflichten, unterliegt der Steward einem deutlich leichteren, besser auf die Betreuung von FOSS zugeschnittenem Regulierungsansatz nach Art. 24 CRA.
Die Kernpflicht des Stewards besteht in der Erarbeitung einer dokumentierten Cybersicherheitsrichtlinie, die die sichere Entwicklung, ein angemessenes Schwachstellenmanagement und den Informationsaustausch fördert. Darüber hinaus muss der Steward auf Anfrage mit den zuständigen Behörden zur Minderung von Cybersicherheitsrisiken zusammenarbeiten und ihnen die Richtlinie vorlegen.
Die Reichweite der Meldepflichten hängt dabei von der Art der Unterstützung ab, die der Steward leistet. Die Kommissions-Guidance differenziert hier in aufschlussreicher Weise:
- Ein Steward, der lediglich nicht-technische Unterstützung leistet, etwa Branding, Governance oder das Sammeln von Spenden, ist an der Entwicklung nicht beteiligt und daher nicht zur Meldung aktiv ausgenutzter Schwachstellen verpflichtet.
- Stellt der Steward hingegen IT-Infrastruktur für die Entwicklung bereit, etwa Build-Systeme oder Repositories, muss er schwere Vorfälle melden, die diese Systeme betreffen.
- Leistet der Steward darüber hinaus Engineering-Unterstützung in Form von Entwicklern, Code-Review oder Release-Management, treffen ihn zusätzlich Meldepflichten für aktiv ausgenutzte Schwachstellen.
Von zentraler Bedeutung für die Praxis ist die ausdrückliche Befreiung des Stewards von Geldbußen: Art. 64 Abs. 10 CRA schließt Sanktionen gegenüber Open Source Stewards explizit aus. Ebenso entfallen die Pflichten zur CE-Kennzeichnung, zur Konformitätsbewertung, zur Erstellung technischer Dokumentation und einer SBOM.
Besondere Konstellationen in der Praxis
Einige Grenzfälle verdienen besondere Aufmerksamkeit.
Non-Profit-Organisationen, deren Einnahmen nach Kostendeckung sämtlich zur Erreichung gemeinnütziger Zwecke verwendet werden, gelten nach Erwägungsgrund 18 des CRA nicht als Hersteller, selbst wenn die von ihnen veröffentlichte FOSS monetarisiert wird. Erfüllen sie die Steward-Voraussetzungen, unterliegen sie den Steward-Pflichten des Art. 24 CRA.
Natürliche Personen können kein Steward sein, da Art. 3 Nr. 14 die Rolle ausdrücklich juristischen Personen vorbehält. Monetarisiert eine natürliche Person ihre FOSS nicht, fällt sie vollständig aus dem CRA-Anwendungsbereich. Monetarisiert sie die FOSS jedoch, wird sie zum Hersteller mit dem vollen Pflichtenprogramm.
Bemerkenswert ist auch die Regelung zur freiwilligen Sicherheitsbescheinigung nach Art. 25 CRA. Die Kommission kann Programme einführen, die es ermöglichen, die CRA-Konformität von FOSS freiwillig bescheinigen zu lassen. Dies erleichtert Herstellern die Erfüllung ihrer Sorgfaltspflicht bei der Integration von FOSS-Komponenten nach Art. 13 Abs. 5 CRA. Organisationen wie die Eclipse Foundation und die OpenSSF arbeiten bereits an entsprechenden Prozessen.
Der Open Source Software Steward ist Ausdruck einer differenzierten Regulierungsphilosophie, die den besonderen Charakter der Open-Source-Ökosysteme anerkennt. Für Organisationen im FOSS-Bereich empfiehlt sich eine frühzeitige Prüfung der eigenen regulatorischen Einordnung anhand der beschriebenen Kriterien (sieh Auch Prüfungsschema unten). Insbesondere sollte produktbezogen analysiert werden, ob die Organisation als Hersteller oder als Steward einzuordnen ist, da die Pflichtenunterschiede erheblich sind.
Stewards sollten bereits jetzt mit der Erarbeitung einer Cybersicherheitsrichtlinie beginnen und ihre internen Prozesse für das Schwachstellenmanagement und die Zusammenarbeit mit Behörden vorbereiten.