Cyber Resilience Act und Open-Source-Software: Was Softwareanbieter und -verwalter wissen müssen

Der Geltungsbereich des CRA für Open-Source-Software (OSS) war einer der umstrittensten Teile der Verordnung. Die OSS-Community äußerte während des Gesetzgebungsverfahrens berechtigte Bedenken, beispielsweise wie die Herstellerpflichten auf nichtkommerzielle, von Freiwilligen getragene Projekte anzuwenden seien. Die endgültige Verordnung bietet eine Antwort, wobei die Überzeugungskraft dieser Antwort davon abhängt, wen man fragt. Seit März 2026 hat der erste Leitlinienentwurf der Europäischen Kommission (EK) begonnen, die Details zu klären.

Für Unternehmen wie Greenbone, die sowohl ein Open-Source-Projekt (OPENVAS) betreuen als auch darauf aufbauende kommerzielle Produkte verkaufen, ist die Antwort klar: Für den kommerziellen Bereich gelten die vollständigen Herstellerpflichten, während für die Aktivitäten der Open-Source-Community die Pflichten des Projektbetreibers gelten. Es ist wichtig zu wissen, wo diese Grenzen verlaufen.

Der dreistufige Ansatz des CRA für Open-Source-Software

Stufe 1: Nichtkommerzielle Open-Source-Projekte und ihre Mitwirkenden (außerhalb des Geltungsbereichs)

Freie und Open-Source-Software (FOSS), die in einem rein nichtkommerziellen Kontext entwickelt und verbreitet wird (d. h. Freiwillige, die Software erstellen und frei weitergeben, ohne kommerzielle Absicht oder Unterstützungsmodell), begründet keine CRA-Verpflichtungen für ihren Urheber oder Vertreiber. Nur FOSS, die im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird, fällt in den Geltungsbereich, und der Leitlinienentwurf der Europäischen Kommission bestätigt, dass die bloße Bereitstellung von nicht monetarisierter FOSS keine kommerzielle Tätigkeit darstellt.

Allerdings ist der Begriff „nichtkommerziell“ möglicherweise immer noch enger definiert, als viele Projekte annehmen. Das Annehmen von Spenden macht ein Projekt nicht automatisch zu einer kommerziellen Aktivität. In Erwägungsgrund 15 der Verordnung (EU) 2024/2847 heißt es jedoch, dass „das Annehmen von Spenden, die die mit der Konzeption, Entwicklung und Bereitstellung verbundenen Kosten übersteigen“, eine kommerzielle Tätigkeit darstellt. Der Leitlinienentwurf der Europäischen Kommission zum CRA und Erwägungsgrund 18 der Verordnung (EU) 2024/2847 legen zudem fest, dass der CRA nicht für Einzelpersonen oder Unternehmen gilt, die lediglich Quellcode zu FOSS-Projekten beitragen, für die sie nicht verantwortlich sind.

Stufe 2: Open-Source-Software-Stewards (geringere Verpflichtungen)

Der CRA führt die rechtliche Definition eines „Open-Source-Software-Stewards“ ein: eine juristische Person, die die Entwicklung von Open-Source-Produkten, die für kommerzielle Tätigkeiten bestimmt sind, nachhaltig und systematisch unterstützt oder die Lebensfähigkeit dieser Produkte sicherstellt. Dies umfasst Software-Stiftungen,

Industriekonsortien und Unternehmen, die OSS-Projekte pflegen und unterstützen, die von anderen kommerziell genutzt werden. Eine natürliche Person gilt gemäß Artikel 3 Absatz 14 der Verordnung (EU) 2024/2847 nicht als OSS-Verwalter.

Verwalter unterliegen nicht denselben Verpflichtungen wie Hersteller. Ihre Verpflichtungen sind geringer als die vollständigen Anforderungen an Hersteller: keine CE-Kennzeichnung, keine formelle Konformitätsbewertung, keine Aufbewahrungspflicht für technische Unterlagen. Gemäß Artikel 24 der Verordnung (EU) 2024/2847 müssen Open-Source-Software-Verwalter jedoch weiterhin:

• eine Cybersicherheitsrichtlinie aufrechterhalten, die die sichere Entwicklung der von ihnen unterstützten OSS-Produkte fördert
• mit den Marktüberwachungsbehörden zusammenarbeiten und Sicherheitsdokumentation auf Anfrage zur Verfügung stellen
• ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, die das Netzwerk und die Informationssysteme betreffen, die für die Entwicklung ihrer OSS-Produkte bereitgestellt werden
• Schwachstellen wirksam beheben und sicherstellen, dass sie den Nutzern ohne unangemessene Verzögerung zugänglich sind
• eine Richtlinie festlegen, die die freiwillige Meldung von Schwachstellen durch die Entwickler des Softwareprodukts fördert

Stewards sind zudem gemäß Artikel 64 Absatz 10 von Bußgeldern für Verstöße gegen den CRA befreit. Die Durchsetzung erfolgt durch Zusammenarbeit und Abhilfemaßnahmen statt durch finanzielle Sanktionen.

Stufe 3: Kommerzielle OSS-Anbieter (vollständige Herstellerpflichten)

Wenn eine natürliche Person oder eine juristische Person (z. B. ein Unternehmen oder eine andere Art von Organisation) OSS entwickelt und vertreibt und diese im Rahmen einer gewerblichen Tätigkeit auf dem EU-Markt in Verkehr bringt, gilt sie gemäß des CRA als Hersteller. Der Schwellenwert des CRA für „gewerbliche Tätigkeit“ ist weit gefasst. Es geht nicht nur um den Verkauf einer Lizenz. Auch die Bereitstellung von kostenpflichtigem Support, SLA-gestütztem Hosting oder professionellen Dienstleistungen rund um ein OSS-Produkt stellt gemäß des CRA eine gewerbliche Tätigkeit dar. Für Hersteller gelten alle Anforderungen aus Anhang I: „Secure-by-Default“-Design, Umgang mit Sicherheitslücken, 24-Stunden-Meldung von Vorfällen, SBOM, technische Dokumentation und CE-Kennzeichnung.

Hersteller bleiben für den Umgang mit Sicherheitslücken in ihren eigenen Produkten verantwortlich, einschließlich solcher, die durch integrierte OSS-Komponenten von Drittanbietern verursacht werden. (EU) 2024/2847, Artikel 13 legt fest, dass Hersteller bei der Integration von Komponenten von Drittanbietern gebotene Sorgfalt walten lassen müssen. Bei Feststellung einer Sicherheitslücke in einer integrierten Komponente, einschließlich einer FOSS-/OSS-Komponente, müssen sie die Sicherheitslücke der Person oder Stelle melden, die diese Komponente herstellt oder wartet, und die Sicherheitslücke unverzüglich gemäß (EU) 2024/2847 Anhang I, Teil II beheben.

Der Leitlinienentwurf der Europäischen Kommission vom März 2026: Was wir derzeit wissen

Die Frist für öffentliche Stellungnahmen zum Leitlinienentwurf der Europäischen Kommission vom März 2026 endete am 31. März 2026. Einige Grenzfälle bleiben weiterhin unklar, obwohl die endgültigen Leitlinien noch im Laufe des Jahres 2026 erwartet werden. Unternehmen sollten alle auf dem Entwurf basierenden Schlussfolgerungen zum Anwendungsbereich überprüfen, sobald die endgültige Fassung veröffentlicht ist. In ihrem Leitlinienentwurf vom März 2026 zur Anwendung des CRA liefert die Europäische Kommission einige Klarstellungen zur Definition des Begriffs „gewerbliche Tätigkeit“ und geht auf weitere wichtige Fragen zum Anwendungsbereich ein.

Zu den wichtigsten Klarstellungen gehören:


• Ein Produkt kann kostenlos und Open-Source sein und dennoch als „auf dem Markt bereitgestellt“ gelten, wenn es auch als Teil einer kommerziellen Dienstleistung oder eines monetarisierten Supportmodells angeboten wird
• Das bloße Vorhandensein öffentlich zugänglichen Codes, beispielsweise in einem GitHub-Repository, stellt noch kein Inverkehrbringen dar; erst eine kommerzielle Beziehung begründet eine Verantwortung
• Bei Dual-Lizenz-Modellen (kostenlose OSS-Edition + kommerzielle Enterprise-Edition) fällt die kommerzielle Edition eindeutig in den Geltungsbereich des CRA; der Status der kostenlosen Edition hängt zudem von ihrer Verbindung zu einer kommerziellen Tätigkeit ab
• Die Verantwortung folgt der Governance: Wer ein Projekt veröffentlicht und effektiv kontrolliert, trägt die Verpflichtungen, nicht derjenige, der Änderungen am Quellcode der Software technisch bereitstellt
• Die Herstellerverantwortung erstreckt sich auch über den ursprünglichen Entwickler hinaus auf Unternehmen, die OSS-Komponenten in Produkte integrieren oder unter eigenem Markennamen vertreiben, die auf dem EU-Markt in Verkehr gebracht werden

Meldungen im September: Die Uhr tickt

Die erste verbindliche CRA-Frist gilt für alle Produkte mit digitalen Elementen, einschließlich OSS. Ab dem 11. September 2026 müssen Hersteller und Verwalter aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden, die die Sicherheit der digitalen Produkte beeinträchtigen könnten, für die sie verantwortlich sind.

Die Meldefristen sind knapp bemessen: Eine Frühwarnung muss innerhalb von 24 Stunden nach Bekanntwerden erfolgen, eine vollständige Meldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb von 14 Tagen bei ausgenutzten Schwachstellen bzw. innerhalb eines Monats bei schwerwiegenden Vorfällen. Die Meldungen werden über die Single Reporting Platform (SRP) der ENISA eingereicht; Anweisungen zur Einbindung und ein Meldehandbuch werden von der ENISA voraussichtlich im Juni 2026 veröffentlicht.

Was das für Greenbone bedeutet

Greenbone ist auf zwei Ebenen tätig: als Hersteller digitaler Produkte und als Open-Source-Software-Steward. Wie oben erläutert, erlegt der CRA für beide Rollen unterschiedliche Verpflichtungen auf. Als Hersteller ist Greenbone für die kommerzialisierten OPENVAS-IT-Sicherheitsprodukte für Unternehmen verantwortlich, und als Steward übernehmen wir die Verantwortung für unsere FOSS-Community-Projekte.

Greenbone kommt seinen Verpflichtungen als Hersteller durch eine breite Palette von IT-Sicherheitsrichtlinien, Kontrollmaßnahmen und Notfallplänen nach. Dazu gehören ein kontinuierliches Schwachstellenmanagement, eine DSGVO-konforme Architektur, dokumentierte Sicherheitsverfahren sowie weitere bewährte Praktiken im Bereich der IT-Sicherheit. Als aktiv nach ISO/IEC 27001:2022 und ISO 9001:2015 zertifiziertes Unternehmen hat sich Greenbone den strengsten Qualitätsstandards für Informationssicherheit verschrieben. Als OSS-Steward ist Greenbone darauf vorbereitet, die CRA-Anforderungen für unsere OPENVAS-Community-Softwareprojekte zu erfüllen.

Schließlich nutzen die Kunden von Greenbone – als Anbieter digitaler Produkte speziell für die Cybersicherheit – unsere OPENVAS-Produktreihe für IT-Sicherheit, um ihre eigenen CRA-Verpflichtungen zu erfüllen. Das bedeutet, dass wir nicht nur für die Erfüllung unserer eigenen CRA-Verpflichtungen verantwortlich sind, sondern auch dafür, die technischen Anforderungen zu verstehen, die andere Organisationen erfüllen müssen, um konform zu bleiben. Diese Doppelrolle als Hersteller digitaler Produkte und als Anbieter von Cybersicherheitsprodukten, die anderen Organisationen dabei helfen, die CRA-Konformität zu erreichen, verschafft Greenbone einen klaren Vorteil: Wir können uns in der Regulierung zurechtfinden und gleichzeitig globale Hersteller digitaler Produkte umfassend dabei unterstützen, dasselbe zu tun.

Empfehlungen für Softwareanbieter, die mit Open Source arbeiten

1. Erfassen Sie Ihre OSS-Nutzung. Jede Open-Source-Komponente in Ihren Produkten muss identifiziert, dokumentiert und nachverfolgt werden. Dies bildet die Grundlage Ihrer SBOM und wird von der CRA unabhängig vom eigenen Compliance-Status der Komponente verlangt.
2. Überprüfen Sie Ihre Geschäftsbeziehungen. Wenn Sie OSS in irgendeiner Weise monetarisieren, beispielsweise durch kostenpflichtigen Support, SaaS-Bereitstellung oder professionelle Dienstleistungen, sollten Sie rechtlichen Rat einholen, ob die vollständigen Herstellerpflichten gelten. Der Monetarisierungstest im Leitlinienentwurf ist der richtige Ausgangspunkt.
3. Bereiten Sie sich jetzt auf die Berichterstattung im September vor. Richten Sie einen internen Prozess ein, der eine Frühwarnung innerhalb von 24 Stunden auslösen kann, und achten Sie auf die Anweisungen der ENISA zur Einbindung in das SRP (voraussichtlich im Juni 2026).
4. Tauschen Sie sich mit der Community aus. Die ORC-Arbeitsgruppe unterhält eine CRA-FAQ und eine Ressourcenplattform für OSS-Verwalter und -Hersteller (cra.orcwg.org und den CRA-Hub auf GitHub). Auch die OpenSSF verfolgt die Entwicklungen im Bereich der CRA-Richtlinien.
5. Verfolgen Sie die endgültigen Leitlinien der Europäischen Kommission. Die Frist für Rückmeldungen endete am 31. März 2026. Wenn die Kommission die endgültige Fassung veröffentlicht, überprüfen Sie alle auf dem Entwurf basierenden Schlussfolgerungen zum Geltungsbereich erneut.

Lesen Sie den vollständigen Leitfaden: Der umfassende Leitfaden zum EU-Cyber-Resilience-Gesetz – alle Anforderungen, Fristen und Sanktionen auf einen Blick.

1. Quellen Europäische Kommission – Cyber Resilience Act (Verordnung (EU) 2024/2847), Amtsblatt
 https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
2. Europäische Kommission – Seite zu CRA und Open-Source-Software-Politik
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
3. Europäische Kommission – Ankündigung des Leitlinienentwurfs (3. März 2026)
https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act
4. Europäische Kommission – CRA-Meldepflichten
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
5. ENISA – Einheitliche Meldeplattform (SRP)
https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
6. ORC-Arbeitsgruppe der Eclipse Foundation — orcwg.org
https://orcwg.org/
7. ORC-Arbeitsgruppe – CRA Hub (FAQ und Ressourcen zur Implementierung)
https://github.com/orcwg/cra-hub
8. ORC-Arbeitsgruppe – Whitepaper: Open-Source-Software-Stewards und der CRA
https://orcwg.org/cra/resources/d3-5-white-paper-on-open-source-software-stewards-and-cra/
9. OpenSSF – Seite zu den politischen Leitlinien des EU-Gesetzes zur Cyber-Resilienz
https://openssf.org/public-policy/eu-cyber-resilience-act/
10. OpenSSF – CRA-Tracker der Global Cyber Policy Working Group
https://policy.openssf.org/CRA/