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 melden, soweit der Steward an der Entwicklung beteiligt ist. Schwerwiegende Sicherheitsvorfälle melden, wenn sie seine bereitgestellten Entwicklungssysteme beeinträchtigen (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.

Übernehmen können wir sie nur dort, wo ein Projekt das auch will. Wir bieten sie an und warten die Entscheidung des Projekts ab. Unser Ziel ist, diese Rolle für möglichst viele der Projekte zu übernehmen, die unsere Kunden in ihren Produkten einsetzen.

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). Zwischen vertraulicher Meldung und öffentlicher Bekanntgabe liegen damit Wochen bis Monate. Die Lücke ist in dieser Zeit ausnutzbar - nur eben nicht öffentlich bekannt. Und weil der Code offen liegt, kann sie jederzeit auch jemand anderes finden. Wer früh davon weiß, gewinnt genau diese Zeit zum Handeln.

Wo ein Projekt OTTRIA als Steward in diese Prozesse einbindet, erhalten wir Sicherheitsmeldungen bei Eingang — nicht erst bei der Veröffentlichung. Das bedeutet: Wir arbeiten am Fix, solange die Lücke noch nicht öffentlich ist.

Bei Projekten, für die OTTRIA Bug-Bounty-Programme sponsert, kommt ein weiterer Kanal hinzu: Wir gestalten diese Programme so, dass Sicherheitsforscher ihre Funde auch direkt an uns melden. Wir finanzieren also die Entdeckung von Schwachstellen und gehören zu den ersten Empfängern der Ergebnisse. Das ist ein doppelter Vorteil: Die Projekte werden sicherer, und unsere Kunden erfahren frühestmöglich von neuen 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 Meldungen aus drei Quellen:

• Responsible Disclosure — als eingebundener Steward bei Eingang der Meldung
• Bug-Bounty-Programme — nach den vereinbarten Programmregeln
• Hersteller — nach Art. 13 Abs. 6 CRA, soweit OTTRIA die betroffene Komponente betreut

Der CRA verpflichtet Hersteller in Art. 14 Abs. 8, betroffene Nutzer über aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sowie über erforderliche Schutzmaßnahmen zu informieren. OTTRIA nutzt die vertraulichen Vorabmeldungen, um betroffene Kunden frühzeitig zu warnen und Schutzmaßnahmen vorzubereiten — soweit die vereinbarten Vertraulichkeitsregeln es erlauben, bereits vor der öffentlichen Bekanntgabe.

Dieser Vorsprung bedeutet in der Praxis: Fixes werden vorbereitet, getestet und bereitgestellt, bevor die Lücke öffentlich wird. Sie handeln, während andere noch auf die CVE-Veröffentlichung warten.

Wichtig: Dieser Zeitvorsprung ist kein pauschales Versprechen für jede Komponente Ihrer Lieferkette. Er entsteht dort, wo OTTRIA aktiv als Steward im Responsible-Disclosure-Prozess eines Projekts eingebunden ist — je nach Projekt und Melder sind das 28 bis 90 Tage. Welche Ihrer Komponenten darunterfallen, sagen wir Ihnen direkt nach der ersten SBOM-Auswertung.

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 — im Rahmen der vereinbarten Offenlegungsregeln, oft Wochen vor der öffentlichen 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: Hersteller-Meldepflichten für Schwachstellen und Sicherheitsvorfälle (Art. 14 CRA)
• Ab 11. Dezember 2027: Vollständige Geltung, einschließlich Steward-Pflichten

Für Projekte und Unternehmen bedeutet das: Die Zeit zum Handeln ist jetzt. Die Hersteller-Meldepflichten gelten bereits, 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.