Der größte Teil des Codes in modernen Produkten stammt nicht aus dem eigenen Haus – haften müssen Unternehmen nach dem Cyber Resilience Act (CRA) trotzdem für jede einzelne Open-Source-Komponente. Wer fremde Bibliotheken, Frameworks oder Betriebssysteme integriert und das Ergebnis monetarisiert, wird (möglicherweise unbemerkt) zu einem Hersteller mit sämtlichen Pflichten.
Wir erklären die Pflichten zum Open-Source-Management unter dem CRA und wie sich Unternehmen rechtzeitig richtig aufstellen.
Warum ist Open Source unter dem CRA ein spezielles Thema?
Die meisten Produkte mit digitalen Elementen enthalten heute Open-Source-Komponenten. Sie stecken in Frameworks, Treibern, Betriebssystemen oder einzelnen Programmbibliotheken und sparen Unternehmen erhebliche Entwicklungszeit. Der Cyber Resilience Act verlangt nun, dass Hersteller die Sicherheit ihres gesamten Produkts über den kompletten Lebenszyklus gewährleisten, unabhängig davon, ob einzelne Bestandteile selbst entwickelt oder aus dem Open-Source-Ökosystem übernommen wurden.
Open-Source-Software wird jedoch üblicherweise ohne Herstellerhaftung und ohne Garantie bereitgestellt. Diese Lücke will der europäische Gesetzgeber mit dem CRA schließen. Wer Open-Source-Software in ein kommerzielles Produkt integriert, kann sich nicht auf die fehlende Haftung der ursprünglichen Entwickler zurückziehen.
Wann fällt Open-Source-Software unter den CRA?
Der Gesetzgeber hat dabei eine wichtige Grenze gezogen. Der CRA erfasst freie und quelloffene Software nur, wenn sie im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird. Die bloße Veröffentlichung von Quellcode, die Mitarbeit an Community-Projekten oder die unentgeltliche Bereitstellung ohne Gewinnerzielungsabsicht fallen nicht in den Anwendungsbereich des CRA.
Entscheidend ist, ob die Bereitstellung Teil einer kommerziellen Tätigkeit ist. Insbesondere die Monetarisierung ist dafür ein zentrales Kriterium. Wer für eine Open-Source-Lösung etwa kostenpflichtigen Support, gehostete Versionen oder kommerzielle Lizenzmodelle anbietet, kann dadurch zum Hersteller im Sinne des CRA werden. Einzelne Entwickler, die in ihrer Freizeit zu Projekten beitragen, bleiben dagegen außen vor.
Auch freiwillige Spenden machen ein Projekt nicht kommerziell, solange der Zugang zur Software nicht an eine Spende geknüpft ist und die Einnahmen die Kosten für Konzeption, Entwicklung und Bereitstellung nicht übersteigen.
Für gemeinnützige Organisationen enthält Erwägungsgrund 18 CRA eine wichtige Auslegungshilfe. Die Entwicklung freier und quelloffener Software durch eine gemeinnützige Organisation soll nicht als kommerzielle Tätigkeit gelten, sofern die Organisation so angelegt ist, dass alle Einnahmen nach Abzug der Kosten der Verwirklichung gemeinnütziger Ziele dienen. In diesem Fall kann es bereits an einer Bereitstellung auf dem Markt im Sinne von Art. 3 Nr. 22 CRA fehlen, so dass die Herstellerpflichten nicht ausgelöst werden.
Der Entwurf einer Leitlinie zur Umsetzung des CRA der EU-Kommission vom März 2026 bestätigt diese Lesart und stellt unter anderem klar, dass die bloße Veröffentlichung von Quellcode in öffentlichen Repositories kein Bereitstellen auf dem Markt ist. Bietet ein Unternehmen parallel eine kostenlose Community-Version und eine kostenpflichtige Version an, löst nur die kostenpflichtige Version Herstellerpflichten aus.
Was gilt für Anbieter, die Open-Source-Komponenten integrieren?
Wer ein Produkt mit digitalen Elementen unter eigenem Namen oder eigener Marke auf den Markt bringt, gilt im Sinne des CRA als Hersteller. Das gilt auch dann, wenn wesentliche Teile des Produkts aus Open-Source-Komponenten bestehen. Die Verantwortung für die Cybersicherheit des Gesamtprodukts verbleibt beim Hersteller, unabhängig davon, wer den ursprünglichen Code geschrieben hat.
Sorgfaltspflichten
Der CRA formuliert dazu in Art. 13 Abs. 5 eine ausdrückliche Sorgfaltspflicht. Danach müssen Hersteller bei der Integration von Komponenten Dritter mit der gebotenen Sorgfalt sicherstellen, dass diese die Sicherheit des Produkts nicht beeinträchtigen. Das gilt ausdrücklich auch für freie und quelloffene Software, und zwar unabhängig davon, ob die Komponente selbst jemals kommerziell in Verkehr gebracht wurde.
In der Praxis bedeutet das, dass bereits bei der Auswahl einer Open-Source-Abhängigkeit der Pflegezustand, die Aktualität, die Historie bekannter Schwachstellen und die Aktivität der dahinterstehenden Community bewertet und dokumentiert werden müssen. Eine unzureichend gepflegte oder faktisch verwaiste Bibliothek stellt ein erhebliches Risiko dar, weil im Ernstfall niemand mehr Sicherheitsupdates bereitstellt.
Software-Stückliste (SBOM)
Grundlage jedes Open-Source-Managements ist die systematische Erfassung aller verwendeten Komponenten. Die Software-Stückliste (Software Bill of Materials –SBOM), ist dafür das zentrale Werkzeug. Sie listet alle Bestandteile eines Produkts einschließlich der jeweiligen Version auf und macht sichtbar, wo Schwachstellen auftreten können. Der CRA verlangt eine SBOM, die mindestens die obersten Abhängigkeitsebenen in einem gebräuchlichen maschinenlesbaren Format abdeckt.
Ergänzende Orientierung bietet die Technische Richtlinie TR-03183-2 des Bundesamts für Sicherheit in der Informationstechnik (BSI). Eine besondere Herausforderung liegt dabei in transitiven Abhängigkeiten, denn jede eingebundene Open-Source-Komponente kann ihrerseits auf weitere Open-Source-Bausteine zurückgreifen. Ohne automatisierte Analyse-Werkzeuge, sogenannte Software-Composition-Analysis-Tools, lässt sich diese Tiefe später kaum noch manuell überblicken. Es lohnt sich daher von Beginn an die Abhängigkeit genau zu dokumentieren.
Schwachstellenmanagement
Darüber hinaus verlangt der CRA ein aktives Schwachstellenmanagement über den gesamten Unterstützungszeitraum des Produkts, der grundsätzlich mindestens fünf Jahre beträgt. Anbieter müssen bekannte Sicherheitslücken in eingesetzten Open-Source-Komponenten verfolgen, bewerten und beheben, sei es durch Updates, das Einspielen von Patches, die Pflege eines eigenen Forks oder den Austausch der betroffenen Komponente.
Bemerkenswert ist dabei die Rückkopplung in das Open-Source-Ökosystem:
- Entdeckt ein Hersteller eine Schwachstelle in einer integrierten Komponente, muss er nach Art. 13 Abs. 6 CRA diese der Person oder Organisation melden, die die Komponente herstellt oder wartet.
- Entwickelt er selbst eine Änderung, um die Schwachstelle zu beheben, muss er den betreffenden Code oder die einschlägigen Unterlagen an das Projekt zurückgeben, gegebenenfalls in einem maschinenlesbaren Format.
Der CRA macht Hersteller damit faktisch zu aktiven Teilnehmern der Open-Source-Sicherheitsgemeinschaft, statt sie nur konsumieren zu lassen.
Lieferkettensicherheit
Schließlich bleibt die Verantwortung für ein integriertes Produkt auch dann beim Anbieter, wenn eine Open-Source-Komponente über einen Zulieferer bezogen wird. Der CRA verlangt hier eine durchgängige Lieferkettensicherheit, bei der auch fremdbezogene digitale Bestandteile in die eigene Risikobewertung einfließen.
CRA-Atteste für Open-Source-Komponenten
Künftig sollen diese komplexen Sorgfaltspflichten erleichtert werden. Nach Art. 25 CRA kann die EU-Kommission freiwillige Programme zur Sicherheitsbescheinigung einführen, mit denen sich die CRA-Konformität von Open-Source-Software attestieren lässt. Hersteller können dann bevorzugt auf attestierte Komponenten zurückgreifen und so ihre Sorgfaltspflicht leichter nachweisen.
Was sind Open-Source-Stewards und welche Verantwortung tragen sie?
Nicht jede Organisation, die Open-Source-Software bereitstellt, wird automatisch zum Hersteller im Sinne des CRA. Das Gesetz führt mit dem Open-Source-Steward, im Deutschen auch Verwalter quelloffener Software genannt, in Art. 3 Nr. 14 CRA eine neue Akteurskategorie ein. Gemeint ist eine juristische Person, die kein Hersteller ist, aber die Entwicklung von Open-Source-Produkten, die für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig unterstützt. Darunter fallen etwa Software-Stiftungen und Industriekonsortien, aber auch Unternehmen, die Community-Projekte dauerhaft pflegen, ohne sie selbst zu vermarkten. Natürliche Personen können keine Steward-Rolle einnehmen.
Für Verwalter quelloffener Software bzw. Open-Source-Stewards gilt nach Art. 24 CRA ein deutlich schlankeres Pflichtenprogramm. Sie müssen
- eine dokumentierte Cybersicherheitsstrategie einführen, die eine sichere Entwicklung und einen wirksamen Umgang mit Schwachstellen fördert,
- mit den Marktüberwachungsbehörden zusammenarbeiten und
- aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle in eingeschränktem Umfang melden.
Eine CE-Kennzeichnung, eine Konformitätsbewertung oder eine vollständige technische Dokumentation sind dagegen nicht erforderlich. Zudem sind Stewards nach Art. 64 Abs. 10 lit. b CRA von Bußgeldern ausgenommen.
Achtung: Vorsicht ist dennoch geboten, denn sobald ein Steward beginnt, die betreute Software zu monetarisieren, rückt er in die Herstellerrolle mit dem vollen Pflichtenprogramm ein.
Wann wird aus einem Nutzer ein Hersteller im Sinne des CRA?
Unternehmen, die Open-Source-Software lediglich intern einsetzen, ohne sie weiterzugeben oder in ein eigenes Produkt zu integrieren, unterliegen in der Regel nicht den CRA-Herstellerpflichten.
Die Rolle ändert sich jedoch, sobald ein Unternehmen ein Open-Source-Produkt unter eigenem Namen oder eigener Marke auf dem Markt bereitstellt. Wer Open-Source-Software im Rahmen einer kommerziellen Tätigkeit unter eigenem Namen oder eigener Marke auf dem Markt bereitstellt, etwa als Teil eines Geräts oder einer eigenen Distribution, kann den Herstellerpflichten unterliegen. Der CRA führt außerdem den Begriff der wesentlichen Veränderung (im Englischen: substantial modification) ein (Art. 3 Nr. 30 CRA): Wird eine Open-Source-Komponente so angepasst, dass sich ihre Cybersicherheitseigenschaften ändern oder ihr ursprünglicher Verwendungszweck erweitert wird, kann das Unternehmen dadurch selbst zum Hersteller im Sinne des CRA werden. In diesem Fall entstehen dieselben Konformitätsbewertungs- und Dokumentationspflichten sowie dieselben Meldepflichten wie für jeden anderen Hersteller auch.
Für Unternehmen lohnt sich deshalb eine ehrliche Bestandsaufnahme der eigenen Praxis. Wird die Open-Source-Komponente nur intern eingesetzt oder unverändert vertrieben, bleibt die Rolle als Nutzer oder Händler in der Regel unangetastet. Wird sie dagegen modifiziert, mit eigenen Funktionen versehen, monetarisiert oder an Dritte weitergegeben, rückt eine Umqualifizierung zum Hersteller näher. Je stärker ein Unternehmen sich der zweiten Konstellation annähert, desto dringender sollte die eigene Rolle rechtlich geprüft werden.
Welche Sorgfaltspflichten bleiben auch ohne formale Herstellerrolle sinnvoll?
Auch wenn ein Unternehmen formal nicht unter die CRA-Herstellerpflichten fällt, ist es ratsam, ein eigenes Vorgehen für den Umgang mit Open-Source-Software zu etablieren. Dazu gehört ein Inventar der eingesetzten Open-Source-Komponenten, das zumindest die wichtigsten Bibliotheken und deren Versionen erfasst. Ergänzend sollte ein kontinuierliches Monitoring bekannter Sicherheitslücken in diesen Komponenten erfolgen, etwa über öffentliche Schwachstellendatenbanken oder automatisierte Benachrichtigungsdienste.
Auch das Lizenz-Management verdient Aufmerksamkeit, denn unterschiedliche Open-Source-Lizenzen bringen unterschiedliche Pflichten mit sich, etwa zur Offenlegung von Quellcode bei Weitergabe oder andere sogenannte Copyleft-Effekte.
Wer Produkte mit Open-Source-Anteilen von Lieferanten bezieht, sollte zudem vertraglich absichern, dass der Lieferant Auskunft über enthaltene Komponenten gibt und im Idealfall eine SBOM zur Verfügung stellt. Solche Anforderungen lassen sich bereits im Einkaufsprozess verankern, etwa als Standardklausel in Beschaffungsverträgen. Sie zahlen sich doppelt aus, weil sie die eigene Risikobewertung erleichtern und zugleich eine belastbare Grundlage schaffen, falls das Unternehmen später doch in eine CRA-relevante Rolle hineinwächst.
Ab wann gelten die Pflichten zum Open-Source-Management des CRA?
Der CRA ist am 11. Dezember 2024 in Kraft getreten, seine Pflichten greifen jedoch gestaffelt:
- Bereits ab dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle – sie treffen neben Herstellern in eingeschränktem Umfang auch Open-Source-Stewards.
- Die übrigen Herstellerpflichten, darunter Konformitätsbewertung, CE-Kennzeichnung, SBOM und Schwachstellenmanagement, gelten ab dem 11. Dezember 2027.
Unternehmen, die Open-Source-Komponenten in ihre Produkte integrieren, sollten die verbleibende Zeit nutzen, um Inventare, Prozesse und Zuständigkeiten aufzubauen.
Wie kann activeMind beim Open-Source-Management unter dem CRA unterstützen?
Um Unternehmen auf dem Weg zur CRA-Compliance beim Management von Open-Source-Komponenten zu unterstützen, entwickeln unsere Experten zum einen eine umfassende SBOM inkl. etwaiger Abhängigkeiten aus der Lieferkette (Open-Source-Nutzung in Vorprodukten bzw. durch Lieferanten bereitgestellte Open-Source-Software). Zum anderen etablieren wir ein Schwachstellenmanagement von Erfüllung der CRA-Meldepflichten über die Behebung der Sicherheitslücken bis zur CRA-konformen Dokumentation.
Ihre Vorteile:
- Unsere Juristen verfügen über tiefgreifende IT-Kenntnisse, wissen also genau, wie die Umsetzung in der Praxis erfolgt.
- Sie profitieren von Prozessen und Best Practices der Cybersicherheit, die sich bereits bei zahlreichen Unternehmen verschiedenster Branchen über Jahre hinweg bewährt haben.
Das Open-Source-Management unter dem Cyber Resilience Act dürfte wegen seiner Vielschichtigkeit Unternehmen sehr herausfordern. Unsere Experten helfen Ihnen gerne, Umwege zu vermeiden und praktikable Lösungen zu entwickeln.
Kontaktieren Sie uns jetzt für ein kostenfreies Erstgespräch!
Fazit – Verantwortung endet nicht an der Lizenzgrenze
Open-Source-Software entbindet weder Anbieter noch Nutzer von der Verantwortung für die Cybersicherheit eines Produkts. Anbieter, die Open-Source-Komponenten integrieren, tragen die volle CRA-Herstellerverantwortung. Sie müssen die Sorgfaltspflicht bei der Komponentenauswahl erfüllen, Schwachstellen über den gesamten Unterstützungszeitraum managen und gefundene Sicherheitslücken an die Open-Source-Projekte zurückmelden. Open-Source-Stewards profitieren von einem reduzierten Pflichtenprogramm, solange sie die betreute Software nicht monetarisieren.
Unabhängig von der eigenen Rolle gilt, dass ein aktuelles Open-Source-Inventar und ein funktionierendes Schwachstellenmonitoring heute keine Kür mehr sind, sondern die Grundlage jeder belastbaren CRA-Compliance-Strategie.
