Cyber Resilience Act: EU-Kommission schafft mehr Klarheit f\u00fcr Open Source<\/p>\n
Vor dem Greifen erster Meldepflichten des Cyber Resilience Act (CRA)<\/a> gibt die EU-Kommission Herstellern, Entwicklern und Firmen eine Orientierungshilfe an die Hand. Der am Montag ver\u00f6ffentlichte Leitfaden erl\u00e4utert auf gut 80 Seiten, wie die Cybersicherheitsverordnung auszulegen ist. Das reicht von der Abgrenzung betroffener Produkte \u00fcber wesentliche Software-Updates bis zu Regeln f\u00fcr Open Source. Der CRA selbst ist bereits seit Dezember 2024 in Kraft und schreibt EU-weit einheitliche Mindestanforderungen an die Cybersicherheit digitaler Produkte \u00fcber deren gesamten Lebenszyklus vor.<\/p>\n Weiterlesen nach der Anzeige<\/p>\n Nach Angaben der Kommission beantwortet die Handreichung zentrale Fragen aus der Industrie. Sie soll Betroffenen helfen, die Vorgaben rechtssicher umzusetzen. Der Leitfaden erl\u00e4utert etwa<\/a>, welche Produkte \u00fcberhaupt unter den CRA fallen, wie entscheidende \u00dcberarbeitungen von Programmen einzuordnen und nach welchen Ma\u00dfst\u00e4ben Support-Zeitr\u00e4ume zu bestimmen sind.<\/p>\n Dazu kommen Hinweise, wie Risikoanalysen sowie Meldepflichten praktisch erf\u00fcllt werden k\u00f6nnen. Besonderes Augenmerk legt die EU-Kommission auf Startups sowie kleine und mittlere Unternehmen. Zahlreiche Praxisbeispiele und Anwendungsszenarien sollen Unklarheiten beseitigen und unn\u00f6tigen Verwaltungsaufwand vermeiden.<\/p>\n Open Source soll nicht ausgebremst werden<\/p>\n Gro\u00dfen Raum widmet die Kommission freier und quelloffener Software. W\u00e4hrend der Verhandlungen \u00fcber den CRA warnten Entwickler und Open-Source-Stiftungen<\/a>, dass ehrenamtliche Projekte durch neue Haftungs- und Dokumentationspflichten abgeschreckt werden k\u00f6nnten.<\/p>\n Die Kommission versucht, diese Bef\u00fcrchtungen auszur\u00e4umen. Frei verf\u00fcgbare Open-Source-Software f\u00e4llt demnach grunds\u00e4tzlich nicht unter den CRA, solange sie nicht im Rahmen einer kommerziellen T\u00e4tigkeit auf den Markt gebracht wird. Sie erl\u00e4utert nun, wann eine solche vorliegt. Wer Open-Source-Software verkauft, kostenpflichtige Enterprise-Versionen anbietet oder \u00fcber ein Programm andere Dienste monetarisiert, gilt als Hersteller im CRA-Sinne.<\/p>\n \u00c4hnlich sieht es aus, wenn Nutzer personenbezogene Daten zu anderen Zwecken als f\u00fcr Sicherheit oder Interoperabilit\u00e4t bereitstellen m\u00fcssen oder Spenden faktisch Voraussetzung f\u00fcr den Zugang zur Software oder zu essenziellen Updates sind. Umgekehrt sollen freiwillige Zuwendungen, \u00f6ffentliche F\u00f6rder- oder Sponsorengelder allein noch keine kommerzielle T\u00e4tigkeit begr\u00fcnden. Auch kostenpflichtige Beratungs-, Schulungs- oder Supportangebote f\u00fchren nicht automatisch dazu, dass ein Open-Source-Projekt unter den CRA f\u00e4llt \u2013 sofern die Software selbst frei verf\u00fcgbar bleibt.<\/p>\n Was genau sind Open-Source-Stewards?<\/p>\n Weiterlesen nach der Anzeige<\/p>\n F\u00fcr viele Entwickler d\u00fcrfte eine weitere Klarstellung wichtig sein. Die Kommission unterscheidet ausdr\u00fccklich zwischen Projektzust\u00e4ndigen und Zulieferern. Wer lediglich Fehler behebt oder neue Funktionen einreicht, tr\u00e4gt demnach grunds\u00e4tzlich keine Verantwortung nach dem CRA. Anders ist es bei Personen oder Organisationen, die ein Projekt ver\u00f6ffentlichen und die Kontrolle \u00fcber Releases, Fahrpl\u00e4ne und die Steuerung aus\u00fcben. Allein Schreibrechte im Quellcode-Repository reichen daf\u00fcr nicht aus.<\/p>\n Auch die Rolle der \u201eStewards\u201c<\/a> wird klarer. Dazu k\u00f6nnen etwa Stiftungen oder andere Organisationen geh\u00f6ren, die Open-Source-Projekte dauerhaft organisatorisch oder technisch unterst\u00fctzen, ohne sie selbst zu vermarkten. Deren Pflichten h\u00e4ngen davon ab, wie intensiv sie eingebunden sind: Wer lediglich Community-Arbeit \u00fcbernimmt, hat deutlich geringere Verpflichtungen als Organisationen, die Infrastruktur betreiben oder aktiv an Entwicklung und Sicherheitsmanagement mitwirken. Je nach Art der Unterst\u00fctzung k\u00f6nnen f\u00fcr Stewards auch Meldepflichten f\u00fcr Sicherheitsvorf\u00e4lle oder ausgenutzte Schwachstellen gelten.<\/p>\n Ferner erl\u00e4utert die Kommission, wann eine \u00c4nderung an einem Produkt als \u201ewesentlich\u201c gilt. Updates, die ausschlie\u00dflich Schwachstellen schlie\u00dfen oder das bestehende Sicherheitsniveau erhalten beziehungsweise verbessern, l\u00f6sen demnach in der Regel kein neues Konformit\u00e4tsbewertungsverfahren aus. Anders kann es aussehen, wenn neue Funktionen das Risikoprofil eines Produkts ver\u00e4ndern oder zus\u00e4tzliche Angriffsfl\u00e4chen schaffen. Auch f\u00fcr Reparaturen schafft der Leitfaden Klarheit: Werden nur identische Ersatzteile geliefert, gilt dies nicht als erneutes Inverkehrbringen des Produkts.<\/p>\n Die Uhr tickt<\/p>\n Die Orientierungshilfe konkretisiert zudem Anforderungen, etwa an Risikoanalysen und die k\u00fcnftigen Meldepflichten. Zwar ist der Leitfaden rechtlich nicht bindend. Er d\u00fcrfte aber f\u00fcr Hersteller und nationale Marktaufsichtsbeh\u00f6rden ma\u00dfgeblich daf\u00fcr werden, wie die Verordnung in der Praxis ausgelegt wird. Die Bundesregierung hat daf\u00fcr das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) vorgesehen<\/a>.<\/p>\n EU-Kommissionsvizepr\u00e4sidentin Henna Virkkunen bezeichnete die Handreichung als Teil der Br\u00fcsseler Entlastungsagenda. Sie solle Unternehmen helfen, ihre neuen Pflichten fristgerecht und rechtssicher umzusetzen. Ein cybersicheres und ein unternehmensfreundliches Europa gingen Hand in Hand. Nach Ansicht der Kommission gewinnt der CRA durch die Fortschritte leistungsf\u00e4higer KI-Modelle mit Cyberf\u00e4higkeiten an Bedeutung. Die ersten Meldepflichten werden am 11. September 2026 wirksam. Hersteller m\u00fcssen der Verordnung ab 11. Dezember 2027 vollst\u00e4ndig nachkommen.<\/p>\n