Barry O’Donovan: Die CRA-Rolle hängt vom Produkt ab

Zusammenfassung

Die CRA richtet den Blick darauf, wie ein bestimmtes Produkt bereitgestellt und dauerhaft unterstützt wird. Barry O’Donovan sagt, eine Organisation könne beim kostenlosen Produkt Verwalter quelloffener Software (open-source software steward im CRA-Text) und bei der Bezahlversion Hersteller sein.
Das Etikett „gemeinnützig“ entscheidet die Einstufung nicht. Betreiber brauchen ein Inventar je Produkt, einen Kontakt für Schwachstellen und einen klaren Weg zum Patch.

Ein Projekt kann seinen offenen Quellcode kostenlos bereitstellen und eine erweiterte Ausgabe verkaufen. Die CRA kann die Produkte unterschiedlich einordnen. Das ist Barry O’Donovans praktische Lesart: Die Rolle folgt dem Produkt, nicht dem Organisationsnamen.

O’Donovan leitet bei INEX die Entwicklung von IXP Manager. In seinem Vortrag auf der RIPE 93 über Softwarelieferketten stellte er die Betreiberfrage: Wenn ein Austauschpunkt oder Netz auf Open-Source-Software angewiesen ist, welche Sicherheitsarbeit kann er vom Projekt dahinter erwarten?

Die aktuelle Orientierung der Europäischen Kommission trennt Hersteller und Verwalter quelloffener Software. Ein Hersteller, der ein Open-Source-Produkt auf dem Markt bereitstellt, trägt die Herstellerpflichten. Eine juristische Person, die das Produkt nicht auf den Markt bringt, aber ein bestimmtes, für kommerzielle Aktivitäten vorgesehenes Open-Source-Produkt dauerhaft und systematisch unterstützt und dessen Fortbestand maßgeblich sichert, kann als Verwalter quelloffener Software gelten. Dazu gehören eine Cybersicherheitsrichtlinie, der Umgang mit Schwachstellen und die Zusammenarbeit mit Marktüberwachungsbehörden.

O’Donovan nahm das typische Modell: Ein Projekt gibt die offene Ausgabe kostenlos ab und verkauft eine Variante mit Zusatzfunktionen. Nach seiner Darstellung kann die Organisation bei der offenen Ausgabe diese Rolle und bei der bezahlten die des Herstellers übernehmen. Auch die Kommission knüpft ihre Erklärung an konkrete Produkte und deren Bereitstellung. Das ist aussagekräftiger, als einer Stiftung, einem Unternehmen oder einem Entwicklungsteam ein einziges dauerhaftes CRA-Etikett zu geben.

Das Gesetz lässt einfache Abkürzungen nicht gelten. Unternehmensfinanzierung, externe Beiträge und regelmäßige Releases machen Software für sich genommen noch nicht kommerziell. Die Verordnung sieht außerdem vor, dass die Entwicklung freier Software durch eine gemeinnützige Organisation nicht als kommerziell gilt, wenn Einnahmen nach Kosten ihren gemeinnützigen Zwecken dienen. Preis, Produktverantwortung, dauerhafte Unterstützung und beabsichtigte kommerzielle Nutzung gehören gemeinsam in die Prüfung.

O’Donovan führte IXP Manager als Praxisbeispiel an. INEX ordne das Projekt als Verwalter quelloffener Software ein und habe sichere Entwicklungs- sowie Schwachstellenrichtlinien veröffentlicht, nachdem andere Austauschpunkte Unterlagen für ihre Lieferkettenprüfung angefragt hatten. Er wies auch darauf hin, dass INEX gemeinnützig ist und Gebühren für Exchange-Ports erhebt. Das ist die operative Auslegung von INEX, keine behördliche Einstufung von IXP Manager. Maßgeblich bleiben das Produkt und die tatsächliche Rolle der Organisation.

Betreiber, die NIS2 unterliegen, müssen ihre eigene Lieferkette weiter steuern. Artikel 21 behandelt Lieferantensicherheit sowie Beschaffung, Entwicklung und Wartung von Systemen, einschließlich Schwachstellenbehandlung und Offenlegung. O’Donovan empfahl ein Softwareinventar, Schwachstellenverfolgung und eine verbindliche Patch-Frist.

In der Fragerunde erwartete er klare Fälle und einen Graubereich, den Gerichte ausleuchten dürften. Für jede Abhängigkeit sollten Betreiber wissen, wer Releases kontrolliert, wer Meldungen annimmt, wer einen Fix bereitstellen kann und welche Ausgabe eingesetzt wird. Ändert sich das Geschäftsmodell, kann sich auch die rechtliche Rolle ändern. Ein Inventar, das nur den Namen der Organisation erfasst, übersieht diesen Wechsel.