Wenn ein Patch für Open-Source zur gesetzlichen Pflicht wird: CRA-Schwachstellenbehandlung und die neue Verantwortung der Softwarehersteller

Der Cyber Resilience Act (CRA) bringt eine subtile, aber tiefgreifende Veränderung in die Art und Weise, wie Hersteller über Open-Source-Software denken müssen. Jahrelang bedeutete die Integration von Free and Open Source Software (FOSS) in Produkte größtenteils, dass man auf die Pflege durch die ursprünglichen Maintainer vertraute, Schwachstellen überwachte und Updates einspielte, sobald Patches verfügbar waren. Unter dem CRA gilt dieses passive Modell nicht mehr. In bestimmten Situationen schafft eine Schwachstelle in einer Open-Source-Komponente nicht nur ein technisches Problem – sie begründet eine gesetzliche Handlungspflicht.

In diesem Moment wird ein FOSS-Patch mehr als eine gute Praxis: Er wird zur regulatorischen Pflicht.

Von passiver Nutzung zu aktiver Verantwortung

Nach Anhang I, Teil II des CRA müssen Hersteller Schwachstellen unverzüglich während der Support-Periode des Produkts beheben. Diese Pflicht gilt für das Produkt in seiner Gesamtheit, einschließlich aller integrierten Komponenten.

Die FAQ der Europäischen Kommission präzisiert dies weiter: Wenn ein Hersteller eine Komponente, einschließlich einer FOSS-Komponente, nutzt und eine Schwachstelle entdeckt, muss er diese beheben. Liefert der ursprüngliche Maintainer keinen Fix, ist nicht mehr verfügbar oder wird die Komponente nicht mehr unterstützt, kann der Hersteller nicht einfach auf neue Versionen oder Varianten verweisen. Er muss das Risiko auf andere Weise mindern, z. B. durch Deaktivierung der Funktionalität, Austausch der Komponente oder die Entwicklung eines eigenen Patches.

Dies verändert das Governance-Modell von Open Source in regulierten Produkten grundlegend. Nutzung von FOSS bedeutet nun auch Verantwortung und Pflege.

Artikel 13(6): Die Pflicht zur Weitergabe des Fixes

Die Änderung hört nicht bei der Behebung auf. Artikel 13(6) führt eine zusätzliche Pflicht ein: Entwickelt ein Hersteller einen Patch für eine Komponente, muss er diesen Patch an die Person oder Organisation weitergeben, die die Komponente pflegt.

Diese Regelung stärkt die koordinierte Schwachstellenbehandlung und die Resilienz des Ökosystems. Sie bringt jedoch auch neue rechtliche und operative Überlegungen mit sich. Ein Hersteller, der eine Open-Source-Komponente modifiziert, um CRA-Pflichten zu erfüllen, konsumiert nicht länger nur Code, sondern wird nun unter der Regulierung auch zum „Contributor“. Der Patch ist keine freiwillige Handlung – er kann gesetzlich vorgeschrieben sein.

Copyleft trifft Compliance

Für Komponenten unter Copyleft-Lizenzen wie GPL, LGPL, AGPL oder MPL wird die Situation noch komplexer. Ein Sicherheits-Patch kann ein abgeleitetes Werk darstellen. Die Verbreitung der modifizierten Komponente – ob in Firmware, Embedded Systems oder als Download-Update – kann entsprechende Veröffentlichungs- und Hinweis-Pflichten auslösen.

In vielen Fällen stimmen regulatorische und lizenzrechtliche Anforderungen überein: Beide fördern Transparenz und Zusammenarbeit entlang der Wertschöpfungskette. Aber diese Übereinstimmung ist nicht immer nahtlos. Hersteller müssen prüfen, ob ihre Behebungsstrategie Veröffentlichungspflichten, Vertraulichkeitsfragen oder Exportkontrollanforderungen beeinflusst. Der CRA ersetzt nicht die Open-Source-Lizenzierung. Er arbeitet neben ihr. Das bedeutet, dass Entscheidungen zur Schwachstellenbehebung nun an der Schnittstelle zwischen regulatorischer Compliance und Urheberrecht getroffen werden.

Wenn der Support der genutzten Komponenten endet

Der CRA behandelt auch Fälle, in denen integrierte Komponenten das Ende ihres Support-Zeitraums erreichen. Hält die Support-Periode des Herstellerprodukts an – in vielen Branchen mindestens fünf Jahre – müssen Schwachstellen in nicht mehr unterstützten Komponenten dennoch behandelt werden.

Die Kommissionsleitlinien verdeutlichen: In solchen Fällen kann der Hersteller verpflichtet sein, die Komponente auszutauschen oder eigenständig einen Patch zu entwickeln. Das Fehlen von Support in der Lieferkette befreit den Hersteller nicht von seiner Pflicht.

Dies hat erhebliche Auswirkungen auf langlebige Industrieanlagen, Embedded Devices und Produkte mit langen Lebenszyklen. Die Auswahl von Komponenten hängt nicht mehr nur von Funktionalität und Kosten ab, sondern auch von Langzeitwartbarkeit und Risikoverteilung.

Transparenz in der Lieferkette wird entscheidend

Diese Pflichten erhöhen die Bedeutung von Software Bills of Materials (SBOMs) und Software Composition Analysis (SCA). Ohne präzisen Überblick über integrierte Komponenten, deren Versionen und Support-Status kann ein Hersteller nicht sinnvoll bewerten, ob eine Schwachstelle eine Behebungspflicht auslöst.

Eine SBOM ist nicht länger nur ein Transparenz-Instrument. Sie wird zu einem Compliance-Instrument. Hersteller können damit betroffene Produkte schnell identifizieren, prüfen, ob Patches für die Lieferkette existieren, Lizenzfolgen eigener Patches bewerten und Behebungsentscheidungen für Marktaufsichtsbehörden dokumentieren.

Auf diese Weise verwandelt SBOM-gesteuerte Governance regulatorisches Risiko in handhabbare Engineering-Workflows.

Ein neues Governance-Modell für FOSS

Der CRA erschwert die Nutzung von Open-Source-Komponenten nicht. Im Gegenteil: Er erkennt FOSS explizit an und berücksichtigt sie. Aber er strukturierte die Verantwortlichkeiten neu.

Integrieren Hersteller FOSS in Produkte, die auf dem EU-Markt bereitgestellt werden, übernehmen sie Verantwortung für die Cybersicherheit während der Support-Periode. Taucht eine Schwachstelle auf und liegt kein Fix für die genutzte Komponente vor, bleibt die Pflicht zu handeln bestehen. In bestimmten Fällen ist das Erstellen und Teilen eines Patches nicht nur beste Praxis, sondern Pflicht. Dies ist eine neue Realität für Produkt-Hersteller. Open Source bleibt ein starker Innovationstreiber, muss in regulierten Märkten jedoch nun in strukturierte Schwachstellenbehandlung, Lizenzbewusstsein und Lifecycle-Governance eingebettet werden.

Bitsea unterstützt Unternehmen bei der Umsetzung

Bei Bitsea helfen wir Organisationen, sich in diesem sich wandelnden Umfeld zurechtzufinden. Wir kombinieren SBOM-gesteuerte Transparenz, tiefgehende Open-Source-Prüfungen, kontinuierliche Schwachstellenanalyse und regulatorische Expertise. So stellen wir sicher, dass ein FOSS-Patch, sobald er zur gesetzlichen Pflicht wird, strategisch, compliant und mit vollständiger Lieferkettentransparenz umgesetzt wird.