Die Upstream-Pflicht nach Art. 13 Abs. 6 CRA und ihre Grenzen bei FOSS (Free and Open Source Software) und Geschäftsgeheimnissen
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen nach Art. 14 CRA an CSIRT und ENISA melden. Eine andere Pflicht findet bislang wenig Beachtung. Art. 13 Abs. 6 CRA verlangt, dass Hersteller eine Schwachstelle in einer eingebauten Komponente an deren Quelle melden. Haben sie die Lücke selbst geschlossen, müssen sie den Fix dorthin zurückgeben.
In der Softwareentwicklung heißt diese Richtung „upstream“. Bei FOSS führt sie zu den Maintainer:innen, die das Projekt pflegen. Die Pflicht gilt ab dem 11. Dezember 2027 und wirft eine heikle Frage auf. Was passiert, wenn der Fix eigenen proprietären Code berührt oder Geschäftsgeheimnisse offenlegen würde?
Die EU-Kommission hat dazu in ihren unverbindlichen Leitlinien zum CRA vom 27. Juli 2026 (C(2026) 5252) erstmals Stellung bezogen.
Das Gesetz verlangt zwei getrennte Schritte
Art. 13 Abs. 6 CRA enthält zwei Pflichten. Nach Unterabsatz 1 meldet der Hersteller eine Schwachstelle in einer integrierten Komponente, „einschließlich einer quelloffenen Komponente“, an die Person oder Einrichtung, die diese Komponente herstellt oder wartet. Das kann auch eine einzelne Entwicklerin sein, die selbst nie unter den CRA fällt.
Hat der Hersteller eine Software- oder Hardware-Änderung entwickelt, um die Schwachstelle in der Komponente zu beheben, teilt er nach Unterabsatz 2 „den betreffenden Code oder die einschlägigen Unterlagen“ mit, „gegebenenfalls in einem maschinenlesbaren Format“.
Zwei Details im Wortlaut werden gern übersehen. Die Norm verlangt Code oder Unterlagen, eine Pflicht zur Herausgabe von Quellcode enthält sie also nicht. Außerdem bezieht sich „gegebenenfalls“ nur auf das Format. Ob der Hersteller den Fix teilt, steht nicht in seinem Ermessen. Erwägungsgrund 34 und die FAQ der Kommission klingen zwar weicher. Erwägungsgründe verdrängen den Normtext aber nicht.
Die Kommission zieht der Pflicht enge Grenzen
Die Leitlinien begrenzen die Upstream-Pflicht an mehreren Stellen.
- Die Pflicht betrifft nur die Version der Komponente, die Sie tatsächlich eingebaut haben. Ältere oder neuere Versionen müssen Sie nicht untersuchen.
- Sie erfasst nur Schwachstellen in der Komponente selbst. Entsteht die Lücke erst durch das Zusammenspiel mit Ihrem eigenen Code oder durch die Kombination mehrerer Komponenten, besteht keine Meldepflicht. Zeigt die Integration bislang unbekannte Eigenschaften der Komponente, ermutigt die Kommission lediglich zur Weitergabe.
- Hat die Komponente keine Maintainer:innen mehr, entfällt die Pflicht. Dasselbe gilt, wenn Sie das Projekt geforkt haben, also eine eigene Kopie unabhängig weiterentwickeln. Wer regelmäßig mit dem Originalprojekt synchronisiert, pflegt allerdings keinen unabhängigen Fork.
- Schließen Sie die Lücke an anderer Stelle Ihres Systems, etwa durch eine geänderte Konfiguration, müssen Sie diese Änderung nicht teilen.
- Sie schulden keinen Erfolg. Ob das Projekt Ihren Fix übernimmt, müssen Sie nicht sicherstellen.
Geschäftsgeheimnisse bleiben geschützt, wenn der Fix sauber getrennt ist
Viele Unternehmen befürchten, über die Upstream-Pflicht eigenen Code offenlegen zu müssen. Diese Sorge ist meist unbegründet. Lücken im proprietären Integrationscode lösen nach den Leitlinien keine Upstream-Pflicht aus. Liegt die Schwachstelle in der Komponente selbst, genügen die „einschlägigen Unterlagen“. Eine technische Beschreibung der Lücke und des Lösungswegs kann also ausreichen, wenn sich der Code nicht ohne proprietäre Bestandteile weitergeben lässt.
Die Vertraulichkeitsregel in Art. 63 CRA schützt Quellcode nur gegenüber den mit dem CRA befassten Stellen, etwa Behörden. Die Norm verpflichtet alle an der Anwendung des CRA Beteiligten, Informationen vertraulich zu behandeln, die sie bei ihrer Tätigkeit erhalten. Dazu zählen etwa Marktüberwachungsbehörden, notifizierte Stellen, CSIRTs, ENISA und die Kommission. Geschützt sind ausdrücklich geistiges Eigentum und Geschäftsgeheimnisse einschließlich Quellcode. Das hilft Ihnen, wenn eine Behörde Ihre technische Dokumentation oder Ihre SBOM anfordert.
Maintainer:innen gehören nicht zu diesem Kreis. Sie erfüllen keine Aufgaben nach dem CRA und erhalten Ihren Fix lediglich als Adressat:innen der Upstream-Meldung. Open-Source-Projekte arbeiten zudem öffentlich. Was Sie dort einreichen, ist in aller Regel früher oder später für alle im Repository lesbar. Auch vertrauliche Meldewege für Sicherheitslücken enden meist mit der Veröffentlichung des Fixes. Eine Geheimhaltungsvereinbarung werden Sie mit einem ehrenamtlich betriebenen Projekt kaum abschließen können. Mit kommerziellen Zulieferern lässt sich Vertraulichkeit dagegen vertraglich regeln.
Ist eine Information einmal veröffentlicht, ist auch der Schutz als Geschäftsgeheimnis verloren. Das Geschäftsgeheimnisgesetz schützt nur Informationen, die nicht allgemein bekannt sind und angemessen geheim gehalten werden (§ 2 Nr. 1 GeschGehG). Gegenüber Maintainer:innen schützen Sie Geschäftsgeheimnisse deshalb allein über die Gestaltung des Fixes. Klären Sie vor der Weitergabe, welcher Code die Komponente betrifft und welcher zu Ihrem eigenen Produkt gehört. Upstream geht nur der erste Teil. Lässt sich beides nicht trennen, beschreiben Sie Lücke und Lösungsweg in den Unterlagen, ohne Ihre eigene Implementierung offenzulegen.
Bei Copyleft entscheidet die Architektur des Fixes
Bei Open-Source-Komponenten gehen die Leitlinien weiter. Die Kommission will den Fix lizenzkompatibel geteilt sehen, etwa unter derselben Lizenz. Im Verordnungstext steht das nicht. Im Ergebnis entsteht eine faktische Pflicht, den eigenen Beitrag zu lizenzieren, die eine unverbindliche Mitteilung nicht begründen kann. Wir halten diese Passage für die rechtlich problematischste der Leitlinien.
Praktisch relevant wird das bei starken Copyleft-Lizenzen wie der GPL. Enthält der Fix proprietäre Bestandteile, müssten Sie diese bei einer Weitergabe unter derselben Lizenz ebenfalls unter die GPL stellen. Der CRA löst diesen Konflikt nicht. Wer eine GPL-Komponente verändert und das Produkt vertreibt, muss den geänderten Quelltext allerdings bereits nach den Lizenzbedingungen der GPL an seine Kund:innen herausgeben. Entwickeln Sie Fixes deshalb möglichst klein und getrennt vom eigenen Code und dokumentieren Sie diese Trennung.
Die Beitragsregeln des Projekts sollte der Hersteller nach den Leitlinien beachten. Ein Sign-off nach dem Developer Certificate of Origin (DCO) ist regelmäßig zumutbar. Ein Contributor License Agreement (CLA) mit weitreichender Rechteeinräumung geht nach unserer Einschätzung über Art. 13 Abs. 6 CRA hinaus. Die Norm verlangt eine Mitteilung, keine Rechteübertragung.
Vorbeugen können Sie mit der Software Bill of Materials (SBOM), der Stückliste aller Komponenten Ihres Produkts. Die BSI-Richtlinie TR-03183-2 verlangt dort auch Lizenzangaben. So erkennen Sie vor dem Ernstfall, bei welchen Komponenten ein Fix lizenzrechtlich heikel wird.
Fehlende Dokumentation kostet Bußgeld und kann Haftung auslösen
Verstöße gegen Art. 13 CRA können nach Art. 64 Abs. 2 CRA Bußgelder bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes auslösen, je nachdem, welcher Betrag höher ist. Nach Art. 13 Abs. 7 CRA müssen Hersteller bekannt gewordene Schwachstellen systematisch dokumentieren. Jede Upstream-Entscheidung gehört deshalb mit Begründung in die technische Dokumentation.
Hinzu kommt die neue Produkthaftungsrichtlinie (EU) 2024/2853 für Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht werden. Nach deren Art. 11 Abs. 2 lit. c entlastet sich ein Wirtschaftsakteur nicht, wenn der Fehler auf fehlenden sicherheitsnotwendigen Software-Updates beruht und dies seiner Kontrolle unterliegt. Wer eine schwächere Lösung wählt, nur um die Weitergabe des Fixes zu vermeiden, geht damit ein Haftungsrisiko ein.
