Werden wir zum Verwalter, nur weil Hersteller unser Projekt finanziell unterstützen?

Nicht allein deswegen. Die regelmäßige Förderung durch Hersteller, die die Komponente in eigene Produkte integrieren, ist ein Anzeichen dafür, dass das Produkt für kommerzielle Tätigkeiten bestimmt ist. Wer als Verwalter dafür einsteht, sagt sie damit nicht. Dafür braucht es eine juristische Person, deren Zweck oder Ziel die systematische und nachhaltige Unterstützung genau dieser Entwicklung ist und die die Brauchbarkeit des Produkts sicherstellt. Ein loser Kreis von Beitragenden ohne Rechtsform erfüllt das nicht; dann gibt es schlicht keinen Adressaten für Artikel 24.

Reicht eine SECURITY.md im Repository als dokumentierte Cybersicherheitsstrategie?

Als Baustein ja, als Ganzes in der Regel nicht. Artikel 24 Absatz 1 verlangt eine Strategie, die Dokumentation, Behebung und Beseitigung von Schwachstellen abdeckt, die freiwillige Meldung nach Artikel 15 fördert und den Informationsaustausch in der Open-Source-Gemeinschaft unterstützt. Eine Kontaktadresse deckt davon nur einen Teil ab. Sie muss außerdem auf überprüfbare Weise dokumentiert sein, also nachvollziehbar versioniert und auffindbar. Auf begründetes Verlangen ist sie in einer Sprache vorzulegen, die die Behörde leicht versteht; eine ausschließlich englische Fassung kann dafür zu wenig sein.

Müssen wir einem Hersteller eine SBOM und eine Konformitätserklärung liefern, wenn er sie verlangt?

Aus dem CRA folgt das nicht. Artikel 24 zählt die Pflichten des Verwalters abschließend auf; die Software-Stückliste (SBOM) und die EU-Konformitätserklärung gehören zu den Herstellerpflichten und bleiben es auch dann, wenn eine quelloffene Komponente im Produkt steckt. Die Sorgfaltspflicht bei der Integration fremder Komponenten trifft nach Artikel 13 Absatz 5 den Hersteller selbst. Vertraglich können Sie natürlich mehr zusagen, doch das ist dann eine geschäftliche Entscheidung und keine Rechtspflicht.

Cyber Resilience Act

Verwalter quelloffener Software

Legaldefinition Art. 3 Nr. 14 CRA

„eine juristische Person, bei der es sich nicht um einen Hersteller handelt, die den Zweck oder das Ziel hat, die Entwicklung spezifischer Produkte mit digitalen Elementen, die als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig zu unterstützen, und die die Brauchbarkeit dieser Produkte sicherstellt“

Verordnung (EU) 2024/2847, Art. 3 Nr. 14 CRA

Der Verwalter quelloffener Software ist eine Rolle, die der Cyber Resilience Act (CRA) eigens geschaffen hat: eine juristische Person, die die Entwicklung bestimmter quelloffener Produkte dauerhaft trägt, ohne sie selbst in den Verkehr zu bringen. Erwägungsgrund 19 nennt die dafür vorgesehene Regelung vereinfacht und maßgeschneidert.

Die Definition in Artikel 3 Nummer 14 setzt vier Dinge voraus: eine juristische Person, die kein Hersteller ist; den Zweck oder das Ziel, die Entwicklung spezifischer Produkte systematisch und nachhaltig zu unterstützen; dass diese Produkte als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind; und dass der Verwalter die Brauchbarkeit dieser Produkte sicherstellt. Fehlt eines dieser Merkmale, greift die Rolle nicht.

Wer darunter fällt

Erwägungsgrund 19 nennt ausdrücklich bestimmte Stiftungen sowie Einrichtungen, die freie und quelloffene Software im wirtschaftlichen Kontext entwickeln und veröffentlichen, einschließlich gemeinnütziger Einrichtungen. Als dauerhafte Unterstützung führt er unter anderem auf:

Hosting und Verwaltung von Plattformen für die Zusammenarbeit bei der Softwareentwicklung
Hosting von Quellcode oder Software
Verwalten oder Administrieren quelloffener Produkte
Steuerung der Entwicklung solcher Produkte

Auf der Produktseite entscheidet die Zweckbestimmung: Erfasst sind nur Produkte, die letztlich für kommerzielle Tätigkeiten bestimmt sind, etwa zur Integration in kommerzielle Dienste oder in kostenpflichtige Produkte. Trägt ein Hersteller, der eine Komponente einbaut, regelmäßig zu deren Entwicklung bei oder unterstützt er sie regelmäßig finanziell, um die Kontinuität des Softwareprodukts zu sichern, wertet der Erwägungsgrund das als eine solche Bestimmung.

Die Pflichten nach Artikel 24

Artikel 24 verlangt drei Dinge, mehr nicht.

Cybersicherheitsstrategie (Absatz 1). Der Verwalter entwickelt und dokumentiert auf überprüfbare Weise eine Cybersicherheitsstrategie, die die sichere Entwicklung des Produkts und einen wirksamen Umgang mit Schwachstellen durch dessen Entwickler fördert. Sie muss insbesondere Dokumentation, Behebung und Beseitigung von Schwachstellen abdecken, die freiwillige Meldung nach Artikel 15 fördern und den Austausch über aufgedeckte Schwachstellen in der Open-Source-Gemeinschaft unterstützen. Den Besonderheiten des Verwalters und seinen rechtlichen und organisatorischen Vorkehrungen ist dabei ausdrücklich Rechnung zu tragen.

Zusammenarbeit (Absatz 2). Auf Verlangen arbeitet der Verwalter mit der Marktüberwachungsbehörde zusammen, um die Cybersicherheitsrisiken des Produkts zu mindern. Auf begründetes Verlangen legt er die Unterlagen zur Strategie in Papierform oder elektronisch vor, in einer für die Behörde leicht verständlichen Sprache.

Meldungen (Absatz 3). Die Meldepflicht nach Artikel 14 Absatz 1 für eine aktiv ausgenutzte Schwachstelle trifft den Verwalter nur, soweit er an der Entwicklung des Produkts beteiligt ist. Artikel 14 Absätze 3 und 8 (Meldung schwerwiegender Sicherheitsvorfälle und Unterrichtung der Nutzer) greifen nur, soweit ein solcher Vorfall die Netz- und Informationssysteme beeinträchtigt, die der Verwalter für die Entwicklung bereitstellt. Beide Erstreckungen sind eng zugeschnitten.

Was nicht gilt

Die grundlegenden Cybersicherheitsanforderungen aus Anhang I, die technische Dokumentation nach Artikel 31, die Konformitätsbewertung und die EU-Konformitätserklärung richten sich an Hersteller, nicht an Verwalter. Folgerichtig sagt Erwägungsgrund 19 ausdrücklich, dass ein Verwalter die CE-Kennzeichnung an Produkten, deren Entwicklung er unterstützt, nicht anbringen darf. Auch ein Unterstützungszeitraum ist nicht festzulegen.

Durchsetzung ohne Geldbußen

Zuständig sind nach Artikel 52 Absatz 3 die Marktüberwachungsbehörden. Stellen sie einen Verstoß gegen Artikel 24 fest, fordern sie den Verwalter auf, für geeignete Korrekturmaßnahmen zu sorgen. Die Gruppe zur administrativen Zusammenarbeit (ADCO) befasst sich auch mit spezifischen Fragen der Marktüberwachung bei Verwaltern (Artikel 52 Absatz 15).

Geldbußen sind ausgeschlossen: Artikel 64 Absatz 10 Buchstabe b nimmt Verwalter quelloffener Software bei jedem Verstoß gegen die Verordnung von den Bußgeldvorschriften aus. Erwägungsgrund 120 ergänzt, dass die Mitgliedstaaten gegen sie auch keine anderen finanziellen Sanktionen verhängen sollten. Das Durchsetzungsmittel ist damit die Aufforderung zur Korrektur, nicht das Bußgeld.

Die Grenze zum Hersteller

Die Definition nimmt Hersteller ausdrücklich aus. Den Ausschlag gibt die Vermarktung: Monetarisiert eine Einrichtung das Produkt selbst, wird es damit im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt (Erwägungsgrund 18). Wer es unter eigenem Namen entwickelt und vermarktet, ist dafür Hersteller nach Artikel 3 Nummer 13, mit allen Pflichten. Ob eine Einrichtung für ein Projekt Verwalter und zugleich für ein anderes Hersteller sein kann, sagt die Verordnung nicht ausdrücklich: Der Wortlaut der Definition stellt auf die Person ab, die Pflichten des Artikels 24 hängen dagegen an bestimmten Produkten.

Was offen bleibt

Zwei weitere Punkte regelt der CRA nicht ausdrücklich. Erstens fehlt eine eigene Regel dazu, wann ein Verwalter mit Sitz außerhalb der Union von Artikel 24 erfasst wird; die Verordnung knüpft sonst an die Bereitstellung auf dem Markt an (Artikel 2 Absatz 1), und genau die liegt beim Verwalter nach Erwägungsgrund 19 nicht vor. Zweitens gilt Artikel 14 zwar bereits ab dem 11. September 2026, seine Erstreckung auf Verwalter erfolgt aber über Artikel 24 Absatz 3. Dieser gilt wie die übrige Verordnung erst ab dem 11. Dezember 2027.

Klarheit soll von zwei Seiten kommen. Die Kommission veröffentlicht Leitlinien, die ausdrücklich auch den Anwendungsbereich in Bezug auf freie und quelloffene Software behandeln (Artikel 26 Absatz 2 Buchstabe a). Daneben kann sie durch delegierte Rechtsakte freiwillige Programme zur Bescheinigung der Sicherheit einführen, um die Sorgfaltspflicht nach Artikel 13 Absatz 5 zu erleichtern (Artikel 25). Nach Erwägungsgrund 21 sollen solche Programme so ausgestaltet sein, dass eine Bescheinigung nicht nur von den Entwicklern und Beitragenden initiiert oder finanziert werden kann, sondern auch von Dritten wie integrierenden Herstellern, Nutzern oder öffentlichen Verwaltungen.

Fragen aus der Praxis

: Nicht allein deswegen. Die regelmäßige Förderung durch Hersteller, die die Komponente in eigene Produkte integrieren, ist ein Anzeichen dafür, dass das Produkt für kommerzielle Tätigkeiten bestimmt ist. Wer als Verwalter dafür einsteht, sagt sie damit nicht. Dafür braucht es eine juristische Person, deren Zweck oder Ziel die systematische und nachhaltige Unterstützung genau dieser Entwicklung ist und die die Brauchbarkeit des Produkts sicherstellt. Ein loser Kreis von Beitragenden ohne Rechtsform erfüllt das nicht; dann gibt es schlicht keinen Adressaten für Artikel 24.
: Als Baustein ja, als Ganzes in der Regel nicht. Artikel 24 Absatz 1 verlangt eine Strategie, die Dokumentation, Behebung und Beseitigung von Schwachstellen abdeckt, die freiwillige Meldung nach Artikel 15 fördert und den Informationsaustausch in der Open-Source-Gemeinschaft unterstützt. Eine Kontaktadresse deckt davon nur einen Teil ab. Sie muss außerdem auf überprüfbare Weise dokumentiert sein, also nachvollziehbar versioniert und auffindbar. Auf begründetes Verlangen ist sie in einer Sprache vorzulegen, die die Behörde leicht versteht; eine ausschließlich englische Fassung kann dafür zu wenig sein.
: Aus dem CRA folgt das nicht. Artikel 24 zählt die Pflichten des Verwalters abschließend auf; die Software-Stückliste (SBOM) und die EU-Konformitätserklärung gehören zu den Herstellerpflichten und bleiben es auch dann, wenn eine quelloffene Komponente im Produkt steckt. Die Sorgfaltspflicht bei der Integration fremder Komponenten trifft nach Artikel 13 Absatz 5 den Hersteller selbst. Vertraglich können Sie natürlich mehr zusagen, doch das ist dann eine geschäftliche Entscheidung und keine Rechtspflicht.

Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.