Was ist ein Open Source Steward?

Eine neue Rolle im europäischen Recht #

Mit dem Cyber Resilience Act (CRA) hat die Europäische Union eine Rolle geschaffen, die es bisher nicht gab: den Verwalter quelloffener Software — im englischen Originaltext "Open Source Software Steward".

Diese Rolle erkennt an, dass Open-Source-Software anders funktioniert als kommerzielle Produkte. Sie wird nicht von Herstellern "in Verkehr gebracht", sondern von Communities entwickelt und von jedem frei genutzt. Der Steward schließt die Lücke zwischen dieser Realität und den Anforderungen der neuen Cybersicherheitsgesetzgebung.

Die gesetzliche Definition #

Art. 3 Nr. 14 des Cyber Resilience Act definiert den Verwalter quelloffener Software als eine juristische Person, die:

• kein Hersteller ist
• den Zweck 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
• die Brauchbarkeit dieser Produkte sicherstellt

Die Definition ist bewusst eng gefasst. Einzelpersonen können kein Steward sein — nur juristische Personen. Und die Unterstützung muss systematisch und nachhaltig sein, nicht nur gelegentlich.

Pflichten des Stewards nach Art. 24 CRA #

Der CRA legt dem Steward eine Reihe von Pflichten auf, die deutlich geringer sind als die eines Herstellers, aber dennoch substanziell:

• Cybersicherheitsstrategie entwickeln und dokumentieren — auf überprüfbare Weise, mit Fokus auf sichere Entwicklung und wirksamen Umgang mit Schwachstellen (Art. 24 Abs. 1)
• Schwachstellenmanagement — Dokumentation, Behebung und Beseitigung von Schwachstellen fördern (Art. 24 Abs. 1)
• Informationsaustausch — den Austausch über Schwachstellen innerhalb der Open-Source-Gemeinschaft unterstützen (Art. 24 Abs. 1)
• Freiwillige Meldung von Schwachstellen fördern, gemäß Art. 15 CRA (Art. 24 Abs. 1)
• Zusammenarbeit mit Behörden — auf Verlangen der Marktaufsichtsbehörden die Strategie-Unterlagen übermitteln (Art. 24 Abs. 2)
• Meldepflichten — aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, soweit der Steward an der Entwicklung beteiligt ist (Art. 24 Abs. 3)

Sicherheitsbescheinigung nach Art. 25 CRA #

Der CRA sieht vor, dass die Europäische Kommission per delegiertem Rechtsakt freiwillige Sicherheitsbescheinigungsprogramme einführen kann. Diese Programme sollen:

• Herstellern die Sorgfaltspflicht bei der Integration von Open-Source-Komponenten erleichtern (Art. 13 Abs. 5 CRA)
• die Besonderheiten der Open-Source-Entwicklungsmodelle berücksichtigen
• von Entwicklern, Nutzern, Herstellern oder öffentlichen Verwaltungen initiiert werden können

Für Projekte unter Steward-Betreuung könnte eine solche Bescheinigung ein konkreter Vorteil sein: Hersteller, die bescheinigte Komponenten einsetzen, erfüllen leichter ihre Sorgfaltspflicht.

Steward vs. Hersteller — die Unterschiede #

Die Unterscheidung ist zentral, denn sie bestimmt den Umfang der Pflichten und die möglichen Konsequenzen:

Rechtsform: Ein Hersteller kann eine natürliche oder juristische Person sein. Ein Steward kann nur eine juristische Person sein.

Rolle: Der Hersteller entwickelt, stellt her oder vermarktet ein Produkt. Der Steward unterstützt die Entwicklung systematisch, ohne selbst Hersteller zu sein.

CE-Kennzeichnung: Der Hersteller muss die CE-Kennzeichnung anbringen. Der Steward darf das ausdrücklich nicht (Erwägungsgrund 19).

Pflichten: Der Hersteller unterliegt den vollen Herstellerpflichten nach Art. 13 und 14 CRA. Der Steward hat nur die reduzierten Pflichten nach Art. 24 CRA.

Marktaufsicht: Beim Hersteller erfolgt eine vollständige Konformitätsprüfung. Beim Steward beschränkt sich die Prüfung auf die Einhaltung der Art. 24-Pflichten (Art. 52 Abs. 3 CRA).

Durchsetzung: Hersteller können mit bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes sanktioniert werden. Beim Steward setzt der Gesetzgeber auf Korrekturmaßnahmen statt auf Bußgelder (Art. 52 Abs. 3, Art. 64 Abs. 10b CRA) — ein anderer Durchsetzungsweg, aber keine geringere Erwartung.

Die Pflichten sind real #

Marktaufsichtsbehörden können den Steward auffordern, geeignete Korrekturmaßnahmen zu ergreifen (Art. 52 Abs. 3 CRA). Die Pflichten nach Art. 24 CRA — Cybersicherheitsstrategie, Schwachstellenmanagement, Meldepflichten, Behördenzusammenarbeit — erfordern professionelle Prozesse und dauerhafte Kapazität.

Hinzu kommt der indirekte Druck: DORA-regulierte Finanzunternehmen müssen Open-Source-Analysen durchführen (Art. 25 Abs. 1 DORA). NIS2-Betreiber müssen die Sicherheitsprozesse aller Zulieferer bewerten (Art. 21 Abs. 2 lit. d NIS2). Die neue Produkthaftung macht Software zum Produkt (Art. 4 RL 2024/2853). Dieser regulatorische Druck der Nachfrageseite trifft den Steward direkt — als Ansprechpartner für Unternehmen, Auditoren und Behörden.

Für OTTRIA bedeutet das: Wir nehmen die Steward-Rolle nicht an, weil sie bequem ist, sondern weil sie die richtige Struktur für unsere Arbeit bietet — und weil die Projekte einen professionellen Partner brauchen, der diesen Druck auffängt.

Der Zeitvorsprung durch Responsible Disclosure #

Der Vorsprung entsteht aus dem Responsible-Disclosure-Prozess der Open-Source-Welt: Wenn ein Sicherheitsforscher eine Schwachstelle in einem Projekt entdeckt, meldet er sie vertraulich an die Maintainer. Diese haben dann eine vereinbarte Frist, die Lücke zu beheben, bevor sie öffentlich bekannt gemacht wird. Die konkreten Fristen unterscheiden sich je nach Projekt und Melder — häufig sind 28 Tage (z.B. DGC AG), 30 Tage (CERT NRW) oder 90 Tage (Google Project Zero). In jedem Fall liegen zwischen vertraulicher Meldung und öffentlicher Bekanntgabe Wochen bis Monate.

Als Steward ist OTTRIA direkt in diese Projekt-Prozesse eingebunden. Wir erhalten Sicherheitsmeldungen bei Eingang — nicht erst bei der öffentlichen Veröffentlichung. Das bedeutet: Während die Welt noch nichts weiß, arbeiten wir bereits am Fix.

Bei Projekten, für die OTTRIA Bug-Bounty-Programme sponsert, kommt ein weiterer Kanal hinzu: Sicherheitsforscher melden ihre Funde direkt an uns als Sponsor. Wir finanzieren aktiv die Entdeckung von Schwachstellen und sind der erste Empfänger der Ergebnisse. Das ist ein doppelter Vorteil: Die Projekte werden sicherer, und unsere Kunden profitieren vom frühestmöglichen Wissen über neue Lücken.

Zusätzlich verpflichtet der CRA in Art. 13 Abs. 6 Hersteller, die eine Schwachstelle in einer Open-Source-Komponente entdecken, die verantwortliche Person oder Einrichtung zu informieren und gegebenenfalls den Sicherheits-Patch zu teilen.

OTTRIA erhält als Steward also Meldungen aus drei Quellen:

• Responsible Disclosure — als eingebundener Steward bei Eingang der Meldung
• Bug-Bounty-Programme — als Sponsor direkt vom Sicherheitsforscher
• Hersteller — nach Art. 13 Abs. 6 CRA verpflichtet, uns zu informieren

Der CRA fordert darüber hinaus in Art. 14 Abs. 8, dass Nutzer über Schwachstellen informiert werden. OTTRIA kann und muss seine Kunden daher vor der öffentlichen Bekanntgabe warnen — und tut das aktiv.

Dieser Vorsprung bedeutet in der Praxis: Fixes werden vorbereitet, getestet und bereitgestellt, bevor Angreifer von der Lücke erfahren. Ihre Systeme sind geschützt, während andere noch auf die CVE-Veröffentlichung warten.

Wichtig: Dieser Zeitvorsprung — je nach Projekt und Melder zwischen 28 und 90 Tagen — gilt nur für Projekte, bei denen OTTRIA aktiv als Steward beteiligt ist. Er ist kein pauschales Versprechen, sondern eine direkte Konsequenz der Steward-Einbindung in den Responsible-Disclosure-Prozess.

Was das für Open-Source-Projekte bedeutet #

Wenn OTTRIA die Steward-Rolle für Ihr Projekt übernimmt, erhalten Sie:

• Eine dokumentierte Cybersicherheitsstrategie, die den CRA-Anforderungen entspricht
• Professionelles Schwachstellenmanagement — von der Erkennung über die Behebung bis zur koordinierten Offenlegung
• Einen Ansprechpartner für europäische Marktaufsichtsbehörden
• Entlastung von regulatorischen Pflichten, die mit der Community-Entwicklung schwer vereinbar sind
• Konkrete operative Unterstützung: Code-Reviews, Security-Audits, Test-Infrastruktur

Was das für Unternehmen bedeutet #

Wenn Sie Open-Source-Komponenten einsetzen, die unter OTTRIA-Stewardship stehen, profitieren Sie von:

• Frühwarnung bei Schwachstellen — Wochen bis Monate vor öffentlicher Bekanntmachung
• Vorbereiteten Fixes zum Zeitpunkt der Veröffentlichung
• Dokumentation für Ihre Sorgfaltspflicht nach Art. 13 Abs. 5 CRA
• Einem konkreten Partner in der Lieferkette, mit dem Ihre Auditoren sprechen können
• Nachweis der Angemessenheit Ihrer Supply-Chain-Security-Maßnahmen

Übergangsfristen #

Der CRA trat am 10. Dezember 2024 in Kraft. Die Pflichten werden stufenweise wirksam:

• Ab 11. September 2026: Meldepflichten für Schwachstellen und Sicherheitsvorfälle (Art. 14 CRA)
• Ab 11. Dezember 2027: Vollständige Geltung aller Bestimmungen

Für Projekte und Unternehmen bedeutet das: Die Zeit zum Handeln ist jetzt. Die Meldepflichten greifen in wenigen Monaten, und die vollständige Geltung folgt Ende 2027.

Sie möchten wissen, ob die Steward-Rolle für Ihr Projekt relevant ist? Oder ob Ihre eingesetzten Open-Source-Komponenten unter Steward-Betreuung stehen? Sprechen Sie mit uns.