In unserem Usecase standen uns Juan und Mikael von der Eclipse Foundation Rede und Antwort. Die Stiftung ist im Kontext des Cyber Resilience Acts (CRA) ein wichtiger Player. Sie agiert als Open Source Software Steward. Sie ist eine internationale, gemeinnützige Organisation, die normalerweise Open-Source-Projekte koordiniert und fördert. Sie entstand 2004 aus dem ursprünglich von IBM gestarteten Eclipse-Projekt, um eine herstellerneutrale und unabhängige Governance der Eclipse-Plattform sicherzustellen. Denn Eclipse ist eigentlich Software zur Softwareentwicklung, eine IDE – Integrated Development Environment. IBM hat sie entwickelt und als Open Source freigegeben. Diese dient dem Schreiben, Debuggen und Kompilieren von Quellcode. Die Rolle der Stiftung besteht heute darin, die technische, rechtliche und organisatorische Basis für die Entwicklung von Open-Source-Software bereitzustellen. Die Foundation verwaltet unter anderem geistige Eigentumsrechte (IP), Infrastruktur, Entwicklungsprozesse und Community-Governance. Die Stiftung ist aktiv in Initiativen der Bereiche Cloud, IoT, Automotive und Software Defined Vehicles. Sie zählt weltweit über 300 Mitgliedsunternehmen und -organisationen, darunter große Technologieanbieter, Industrieunternehmen und Forschungseinrichtungen.
EASY.CRA (EC): Was hat die Eclipse Foundation dazu bewogen, die Rolle eines Open-Source-Stewards zu übernehmen?
Eclipse Foundation (EF): Die Eclipse Foundation nimmt bereits seit Langem Aufgaben wahr, die heute unter den Begriff des Open-Source-Stewards fallen. Weit vor dem Cyber Resilience Act (CRA) haben wir damit begonnen. Die Übernahme dieser Rolle war daher ein logischer nächster Schritt. Darüber hinaus haben wir die weitreichenden Auswirkungen des CRA auf das gesamte Ökosystem erkannt und gemeinsam mit anderen Stiftungen und Unternehmen die Community „Open Regulatory Compliance Working Group“ gegründet. Die Initiative soll der gesamten Open-Source-Landschaft beim Übergang in eine durch den CRA regulierte Branche helfen.
EC: Wie lief der Prozess ab? Erfolgte dieser über das zuständige europäische CSIRT (in Deutschland das BSI) als benennende Stelle? Oder gibt es hierfür ein separates Verfahren?
EF: Gemäß der offiziellen CRA-Leitlinie basiert die Rolle eines Stewards darauf, einer Open-Source-Initiative dauerhaft operative Unterstützung bereitzustellen. Dazu gehören insbesondere eine zwangsnotwendige Infrastruktur und die Durchsetzung robuster Cybersicherheitsrichtlinien. Obwohl eine enge Zusammenarbeit mit dem CSIRT wichtig ist, um gesetzliche Anforderungen an die Meldung von Schwachstellen zu erfüllen, erfolgt die Anerkennung als Steward unabhängig von einer formalen Verbindung zu dieser Stelle.
EC: Wie bereiten sich Organisationen darauf vor? Ist das Verfahren hinsichtlich Personalaufwand aufwendig? Wie könnte ein typisches Team aussehen (IT-Spezialisten, Juristen usw.)?
EF: Die Eclipse Foundation beschäftigt sich von Beginn des Cyber Resilience Acts an intensiv mit diesem Thema. Da frühe Gesetzesentwürfe erhebliche Risiken für die Nachhaltigkeit von Open-Source-Aktivitäten mit sich brachten, haben wir unsere Führungsebene sowie unsere Sicherheits- und Rechtsabteilungen mobilisiert, um die Diskussion zu prägen und das Gesetz aktiv mitzugestalten.
Mit dem Übergang in die operative Umsetzung spielen zunehmend die technischen Teams eine zentrale Rolle. Sie sorgen dafür, dass Schwachstellenmeldungen, die Durchsetzung von Sicherheitsrichtlinien und die sorgfältige Pflege von Software Bill of Materials (SBOMs) systematisch in unsere Governance-Strukturen integriert werden.
EC: Welche parallelen Strukturen müssen aufgebaut werden?
EF: Statt lediglich parallele Strukturen zu schaffen, besteht die Priorität darin, verschiedene Compliance-Aktivitäten und gesetzliche Verpflichtungen nahtlos in bestehende Betriebsabläufe zu integrieren. Eine universelle Lösung gibt es nicht. Allerdings müssen sorgfältige Due-Diligence-Prozesse, die kontinuierliche Pflege von SBOMs und ein robustes Schwachstellenmanagement über den gesamten Wartungs- und Lebenszyklus von Projekten und Produkten hinweg systematisch verankert werden.
EC: Welche Vorteile kann die Community erwarten? Wird die Entwicklung kleinerer Projekte rechtlich sicherer?
EF: Der Cyber Resilience Act führt einen risikobasierten Rahmen ein, um die Sicherheit von Projekten zu verbessern, die für die kommerzielle Nutzung vorgesehen sind. Darüber hinaus können kleinere Initiativen durch die Nutzung etablierter Methoden und Governance-Modelle von Stewards bestehende Prozesse übernehmen, ihre Entwicklung effizienter gestalten und den Aufwand für die Einhaltung regulatorischer Anforderungen verringern.
EC: Verlagert der Steward Verantwortlichkeiten auf die Entwickler (oder umgekehrt)? Ist das eher Teamarbeit? Ich nehme an, alle Beteiligten müssen sich dieser neuen Herausforderung in irgendeiner Weise stellen, oder?
EF: Im Rahmen des Cyber Resilience Act bleiben Entwickler von Open-Source-Software von einer direkten Haftung ausgenommen. Die Verordnung sieht lediglich ein „Light-Touch“-Regime gesetzlicher Verpflichtungen für Open-Source-Stewards vor.
Obwohl eine enge Zusammenarbeit zwischen Stewards und Mitwirkenden (Contributors) unerlässlich ist, wird die rechtliche Verantwortung nicht auf die Entwicklergemeinschaft übertragen. Stattdessen sollte der Fokus darauf liegen, wie kommerzielle Hersteller die Due-Diligence-Prozesse der Stewards und die technische Arbeit der Entwickler nutzen können, um ihre eigenen Compliance-Anforderungen zu erfüllen und gleichzeitig zur Nachhaltigkeit dieser wichtigen Ökosysteme beizutragen.
EC: Wenn ich als intensiver Nutzer freier Software direkt vom Anbieter installiere, habe ich dann denselben „Schutz“ wie bei einer Installation über die offizielle Distribution? Macht das einen Unterschied? Zur Erklärung: Ich bin kein Programmierer, sondern eher jemand mit großem Interesse an Open Source und alternativen Computerkonzepten.
EF: Der Cyber Resilience Act richtet sich in erster Linie an kommerzielle Anbieter, die digitale Produkte in Verkehr bringen, und nicht an einzelne Nutzer, die Software eigenständig installieren. Der „Schutz“ im Sinne des CRA besteht daher in der Haftung des Herstellers. Das bedeutet, dass Anbieter, die Ihnen ein digitales Produkt verkaufen, rechtlich für dessen Sicherheit verantwortlich sind.
Ob Sie Software über eine offizielle Distribution oder direkt vom Anbieter installieren, ist für die Verordnung grundsätzlich unerheblich. Der CRA schafft keinen regulatorischen Rahmen für die Sicherheit nichtkommerzieller Installationen durch Endnutzer.
Wenn Sie selbst als Integrator auftreten, etwa indem Sie Software selbst kompilieren oder direkt installieren, bewegen Sie sich außerhalb des Bereichs der kommerziellen Hersteller-Compliance. Die Absicht des Gesetzes besteht nicht darin, Ihre persönliche Installationsmethode zu regulieren, sondern kommerzielle Akteure dazu zu verpflichten, Verantwortung für die in ihren Produkten verwendeten Softwarekomponenten zu übernehmen. Sie verlieren also keinen „Schutz“, wenn Sie eigene Bezugsquellen wählen. Vielmehr befinden Sie sich in einer Situation, in der die kommerzielle Haftungskette schlicht nicht existiert.
EC: Wenn ich meine Software selbst aus dem Quellcode baue, genieße ich dann noch diesen Schutz? Was ist mit eigenen Änderungen? Ist jedes Compiler-Flag, das ich setze, im Sinne des CRA „geschützt“?
EF: Der Cyber Resilience Act legt Sicherheitsanforderungen speziell für diejenigen fest, die digitale Produkte kommerziell auf den Markt bringen. Wenn Sie Software für den Eigengebrauch aus dem Quellcode kompilieren, handeln Sie nicht als Hersteller. Daher finden die gesetzlichen Anforderungen bezüglich Schwachstellenmeldungen oder Compliance-Dokumentation auf Sie keine Anwendung. Diese Verpflichtungen richten sich ausdrücklich an kommerzielle Akteure, die für die Sicherheit ihrer vermarkteten Produkte rechtlich verantwortlich sein sollen.
Werden Ihre Änderungen jedoch Bestandteil eines Produkts, das kommerziell vertrieben werden soll, gewinnen die Prinzipien „Security by Design“ und „Security by Default“ zentrale Bedeutung. Dabei ist insbesondere sicherzustellen, dass keine bereits bekannten und aktiv ausgenutzten Schwachstellen enthalten sind. Für die technische Integrität der modifizierten Version tragen Sie dann die volle Verantwortung. Das ist vergleichbar mit der Haftung für eine vorherige Version.
Ein wesentlicher Bestandteil dieses Rahmens ist die sorgfältige Durchführung von Due-Diligence-Prüfungen. Diese helfen zu bestimmen, in welchem Umfang Open-Source-Komponenten vor dem Inverkehrbringen angepasst werden müssen. Lokale Anpassungen mögen kurzfristig bequem erscheinen, gefährden jedoch häufig die langfristige Nachhaltigkeit, da sie zusätzlichen Wartungsaufwand verursachen, den die Gemeinschaft oft nicht mittragen kann. Deshalb ist es wichtig, durch Beiträge zum Upstream-Projekt wieder in das Ökosystem zu investieren.
Innerhalb der Arbeitsgruppe „Open Regulatory Compliance“ arbeiten wir systematisch an Methoden, um die Integration solcher Projekte zu vereinfachen und gleichzeitig die Rolle kommerzieller Hersteller im Rahmen dieser Zusammenarbeit klarer zu definieren.