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.
Art. 3 Nr. 14 des Cyber Resilience Act definiert den Verwalter quelloffener Software als eine juristische Person, die:
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.
Der CRA legt dem Steward eine Reihe von Pflichten auf, die deutlich geringer sind als die eines Herstellers, aber dennoch substanziell:
Der CRA sieht vor, dass die Europäische Kommission per delegiertem Rechtsakt freiwillige Sicherheitsbescheinigungsprogramme einführen kann. Diese Programme sollen:
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.
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.
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 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:
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.
Wenn OTTRIA die Steward-Rolle für Ihr Projekt übernimmt, erhalten Sie:
Wenn Sie Open-Source-Komponenten einsetzen, die unter OTTRIA-Stewardship stehen, profitieren Sie von:
Der CRA trat am 10. Dezember 2024 in Kraft. Die Pflichten werden stufenweise wirksam:
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.