Open Source steckt in fast jedem Produkt mit digitalen Elementen, doch wer trägt die Verantwortung, wenn eine Schwachstelle in einer integrierten Open-Source-Komponente auftaucht? Der Cyber Resilience Act (CRA) schafft dafür erstmals eine eigene Rolle für Open-Source-Verantwortliche. Dieser Artikel erklärt, wer als Open Source Steward gilt, welche Pflichten Art. 24 CRA tatsächlich fordert und was Hersteller beim Einsatz von Open Source beachten müssen.
Die Verantwortung für die CRA-Konformität des Gesamtprodukts verbleibt beim Hersteller, auch wenn darin frei verfügbare Open-Source-Komponenten stecken. Der CRA regelt damit vor allem Pflichten, Konformität, Marktüberwachung und Sanktionen, nicht automatisch die gesamte zivilrechtliche Haftungskette.
In der Open-Source-Community war der CRA lange umstritten. Frühe Entwürfe drohten, selbst ehrenamtliche Maintainer in den Geltungsbereich zu ziehen. Die finale Fassung ist deutlich ausgewogener: Sie enthält wichtige Ausnahmen für nicht-kommerzielle Projekte und schafft eine neue, eigenständige Rolle, den Open Source Steward. Dieser Artikel richtet sich an beide Seiten, an Hersteller, die Open-Source-Komponenten einsetzen, und an Organisationen, die Open-Source-Projekte betreiben und prüfen müssen, ob Art. 24 CRA für sie gilt. Er setzt Grundkenntnisse des CRA voraus; einen kompakten Einstieg bietet unser Artikel: Was kommt auf Maschinenbauer zu?. Er ergänzt außerdem unsere Artikel zur CRA-Lieferkette und zu SBOM für Embedded-Systeme.
Die Grundregel des CRA ist klar: Wer ein Produkt mit digitalen Elementen entwickelt oder herstellen lässt und es unter eigenem Namen oder eigener Marke auf dem EU-Markt vermarktet, ist als Hersteller vom CRA betroffen. Ob das Produkt auf Open Source basiert, ändert daran nichts. Für den Open-Source-Kontext sind drei Gruppen relevant.
Erstens der Hersteller nach Art. 3 Nr. 13 CRA. Ein Unternehmen, das ein Linux-basiertes IoT-Gerät oder ein Industrie-Gateway unter eigener Marke auf den Markt bringt, bleibt Hersteller, auch wenn Betriebssystem, Frameworks und Bibliotheken aus Open Source stammen. Ein bloßer Wiederverkäufer fremder Produkte ist dagegen nicht automatisch Hersteller und wird nur in bestimmten Konstellationen wie ein Hersteller behandelt. Für Hersteller gelten die vollen Pflichten, etwa CE-Kennzeichnung, Konformitätsbewertung und technische Dokumentation.
Zweitens der Open Source Steward, eine neue Kategorie, die der CRA in Art. 3 Nr. 14 einführt. Ein Verwalter quelloffener Software ist eine juristische Person, die kein Hersteller ist, die Entwicklung bestimmter, für kommerzielle Tätigkeiten bestimmter Open-Source-Produkte systematisch und nachhaltig unterstützt und deren Brauchbarkeit sicherstellt. Für Stewards gelten erleichterte Pflichten nach Art. 24 CRA, auf die der nächste Abschnitt eingeht.
Drittens gibt es Projekte, die gar nicht vom CRA betroffen sind. Nicht monetarisierte Open-Source-Software fällt grundsätzlich nicht schon deshalb in den Anwendungsbereich, weil Hersteller das Projekt finanzieren oder eigene Entwickler daran mitarbeiten. Für die Abgrenzung zwischen nicht-kommerzieller Tätigkeit, Geschäftstätigkeit und Steward-Rolle helfen vor allem die Erwägungsgründe 15, 18 und 19.
Die entscheidende Frage ist damit: Wann wird aus Open Source eine Geschäftstätigkeit? Entgeltliche technische Unterstützung, Gewinnerzielungsabsicht oder Einnahmen, die klar über die Kostendeckung hinausgehen, sprechen eher für eine kommerzielle Tätigkeit. Finanzierung durch Industrie, projektbezogene Beiträge von Unternehmensentwicklern oder eine gemeinnützige Trägerstruktur reichen für sich genommen noch nicht aus.
Viele populäre Projekte bewegen sich in der Grauzone zwischen nicht-kommerzieller Entwicklung, Stewardship und kommerzieller Herstellerverantwortung. Einige Organisationen haben ihre Position inzwischen ausdrücklich beschrieben. Die Linux Foundation bezeichnet sich in ihrem CRA-Bericht als führenden Open Source Software Steward und bereitet ihre Projekte und Mitglieder auf die damit verbundenen Aufgaben vor. Red Hat hat sich für 15 konkret benannte Open-Source-Projekte formell als Open Source Software Steward eingeordnet, darunter Fedora, CentOS Stream und Ansible. Das Beispiel zeigt zugleich, dass die Einordnung als Steward organisations- und projektbezogen geprüft werden muss und nicht automatisch für sämtliche Aktivitäten einer Organisation gilt.
| Kategorie | Beispiele | CRA-Pflichten | CE-Kennzeichnung |
|---|---|---|---|
| Hersteller | Kommerzielles IoT-Gerät auf Linux-Basis | Volle Herstellerpflichten (Art. 13) | Pflicht |
| Open Source Steward | Linux Foundation, Eclipse Foundation, Apache ASF | Erleichterte Pflichten (Art. 24) | Nicht erforderlich |
| Nicht betroffen | Hobby-Projekt, akademische Forschung ohne Kommerzialisierung | Keine CRA-Pflichten | Nicht relevant |
Der Begriff Open Source Steward ist eine Schöpfung des CRA. Art. 3 Nr. 14 CRA definiert ihn als juristische Person, die kein Hersteller ist, die Entwicklung bestimmter Open-Source-Produkte für kommerzielle Tätigkeiten systematisch und nachhaltig unterstützt und deren Brauchbarkeit sicherstellt. Die Definition ist enger, als viele Zusammenfassungen suggerieren. Nicht nur das fehlende Inverkehrbringen zählt, sondern auch der Organisationszweck, die nachhaltige Unterstützung und der Bezug auf bestimmte Produkte.
Typische Beispiele für Open Source Stewards sind die Linux Foundation, die Eclipse Foundation, die Apache Software Foundation oder die CNCF. Aber auch Unternehmen, die Open-Source-Projekte wie VS Code, React oder .NET auf Basis eigener kommerzieller Interessen fördern, ohne das Projekt selbst als fertiges Produkt zu vermarkten, können als Steward gelten.
Der wichtigste Unterschied zum Hersteller: Der Steward bringt nicht das Gesamtprodukt in Verkehr und ist gerade kein Hersteller im Sinne des Art. 3 Nr. 13. Er ist nicht der Ursprung eines kommerziellen Produkts auf dem EU-Markt, sondern die Organisation, die bestimmte Open-Source-Produkte dauerhaft unterstützt. Das bedeutet: CE-Kennzeichnung, Konformitätsbewertung und technische Dokumentation des Produkts nach Anhang VII entfallen. Stattdessen gelten die deutlich schlankeren Pflichten aus Art. 24 CRA. Für Stewards sind dabei vor allem drei Punkte verpflichtend: eine dokumentierte Cybersicherheitsstrategie, Zusammenarbeit mit Behörden auf Verlangen und Meldepflichten nur in den eng begrenzten Fällen des Art. 24 Abs. 3.
| Thema | Hersteller | Open Source Steward |
|---|---|---|
| Dokumentierte Cybersicherheitsstrategie | Im Herstellerregime produktbezogen | Pflicht nach Art. 24 Abs. 1 |
| Kooperation mit Marktüberwachungsbehörden | Pflicht | Pflicht nach Art. 24 Abs. 2 |
| Meldepflichten an ENISA | Voll nach Art. 14 | Pflicht nur in den in Art. 24 Abs. 3 genannten Fällen |
| CE-Kennzeichnung | Pflicht | Nicht erforderlich |
| Technische Dokumentation des Produkts | Pflicht nach Anhang VII | Nicht erforderlich |
| Konformitätsbewertung | Pflicht | Nicht erforderlich |
| Software Bill of Materials (SBOM) | Pflicht | Keine ausdrückliche Pflicht nach Art. 24 |
| Vertraulicher Meldeweg | Praktisch Teil der Vulnerability Policy | Sinnvolle Umsetzung, aber keine eigene ausdrückliche Pflicht |
Ein wichtiger Hinweis: Der Steward kann nicht als regulatorischer Puffer für Hersteller dienen. Ein Hersteller, der ein Open-Source-Projekt in sein eigenes kommerzielles Produkt integriert und dieses unter eigenem Namen vermarktet, bleibt Hersteller, unabhängig davon, ob die genutzte Bibliothek von einem Open Source Steward im Sinne des Art. 3 Nr. 14 unterstützt wird.
Art. 24 Abs. 1 bis 3 CRA definiert keine vier Einzelpflichten mit Buchstaben, sondern drei Pflichtengruppen, die sauber von praktischen Umsetzungsmaßnahmen getrennt werden sollten.
Der Steward muss eine überprüfbar entwickelte, dokumentierte und tatsächlich angewendete Cybersicherheitsstrategie haben.
Diese Strategie soll sichere Entwicklung und wirksamen Umgang mit Schwachstellen fördern, freiwillige Meldungen nach Art. 15 unterstützen und insbesondere Dokumentation, Behebung, Beseitigung und Informationsaustausch zu Schwachstellen abdecken.
Eine öffentliche SECURITY.md, interne Zuständigkeiten, Triage-Prozesse und ein definierter vertraulicher Meldeweg sind dafür sinnvolle Bausteine. Eine einzelne Datei im Repository wie SECURITY.md erfüllt Art. 24 für sich genommen aber noch nicht.
Auf Verlangen muss der Steward mit Marktüberwachungsbehörden zusammenarbeiten. Auf begründetes Verlangen muss er die Dokumentation dieser Cybersicherheitsstrategie in verständlicher Form vorlegen.
Bestimmte Meldepflichten aus Art. 14 gelten auch für Stewards, aber nur in begrenzten Konstellationen:
Wichtig ist die Abgrenzung: Das ist keine pauschale Gleichstellung mit dem vollständigen Hersteller-Workflow. Ob eine 24-Stunden-Meldung greift und welche Folgepflichten konkret ausgelöst werden, musst du entlang der Verweisstruktur des Art. 24 Abs. 3 prüfen. Ausführlichere Details zum allgemeinen Hersteller-Workflow erklärt unser Artikel: CRA Meldepflichten. Für Stewards musst du dort die Einschränkungen aus Art. 24 Abs. 3 mitlesen.
Praktisch heißt das: SECURITY.md, Private Vulnerability Reporting, eine security.txt nach RFC 9116 oder öffentliche Governance-Dokumente können Teil einer belastbaren Umsetzung sein. Sie sind aber Umsetzungsbausteine, keine wörtlich so genannten Einzelpflichten im Gesetz.
Für das operative Minimum eines Stewards zählt weniger die konkrete Datei als der belastbare Prozess dahinter: klare Zuständigkeiten für Triage und Freigabe, dokumentierte Entscheidungen, unterstützte Versionen und ein vertraulicher Meldeweg. Ob dieser über SECURITY.md, GitHub Private Vulnerability Reporting, eine E-Mail-Adresse oder ergänzend über security.txt sichtbar gemacht wird, ist eine Umsetzungsfrage und nicht die gesetzliche Pflicht selbst.
Auch wenn ein Hersteller Open-Source-Komponenten verwendet, bleibt er für die CRA-Konformität des unter seinem Namen vermarkteten Gesamtprodukts verantwortlich. Das bedeutet konkret: Es gibt keine pauschale Ausnahme für kostenlos verfügbaren Open Source. Ob eine Bibliothek einen bekannten Steward hat oder von einem einzelnen Maintainer ohne jede Community-Struktur gepflegt wird, ändert nichts daran, dass der Hersteller das Endprodukt verantwortet.
Art. 13 Abs. 5 CRA verlangt bei der Integration von Drittkomponenten, einschließlich Open Source, angemessene Sorgfalt, damit diese Komponenten die Cybersicherheit des Produkts nicht beeinträchtigen. Stellt der Hersteller eine Schwachstelle in einer integrierten Komponente fest, verlangt die Norm je nach Konstellation außerdem Informationen an den Hersteller oder Maintainer der Komponente und gegebenenfalls die Weitergabe relevanter Korrekturen.
Praktische Due-Diligence-Maßnahmen für Open-Source-Komponenten umfassen:
Für Unternehmen mit einer größeren Anzahl genutzter Open-Source-Komponenten ist ein Open Source Program Office (OSPO) eine zunehmend verbreitete Best Practice. Ein OSPO verwaltet das Inventar der eingesetzten Open-Source-Komponenten, prüft Lizenz-Compliance, definiert eine Contribution-Policy und koordiniert das Sicherheitsmonitoring. Für die CRA-Due-Diligence ist das OSPO die natürliche organisatorische Heimat.
Eine häufige Verwechslung: Open Source nutzen und Open Source Steward sein sind zwei verschiedene Rollen. Wer Open-Source-Komponenten nur konsumiert und in ein eigenes Produkt integriert, hat Hersteller-Pflichten, keine Steward-Pflichten. Die SBOM gehört damit auf die Herstellerseite und gerade nicht in das Pflichtenset des Art. 24. Wenn du tiefer in Inventarisierung, PURLs und Monitoring einsteigen willst, schau in unsere Artikel: SBOM für Embedded-Systeme und SBOM-Grundlagen. Detaillierte Anforderungen an Lieferantenvereinbarungen und Supplier-SBOMs behandelt unser Artikel zur CRA-Lieferkette.
Der CRA hat in der Open-Source-Community intensive Diskussionen ausgelöst. Parallel ist ein Ökosystem von Sicherheitsinitiativen gewachsen, das Herstellern bei der CRA-konformen Komponentenauswahl und -bewertung konkret hilft.
Die Open Source Security Foundation (OpenSSF) ist das zentrale Dach dieser Initiativen. Sie ist ein Projekt der Linux Foundation mit Mitgliedern wie Google, Microsoft, Amazon und Intel. Für Hersteller sind vier OpenSSF-Projekte besonders relevant:
Die OpenSSF Scorecard analysiert GitHub-Repositories auf 18 Sicherheitskriterien, etwa Branch Protection, Signed Releases, Dependency Update Tools und Code Review, und gibt einen Score von 0 bis 10.
SLSA (Supply-chain Levels for Software Artifacts) arbeitet in der aktuellen Spezifikation mit mehreren Tracks. Für Hersteller ist heute vor allem der Build-Track mit Levels 0 bis 3 relevant, weil er Anforderungen an nachvollziehbare Builds, Provenance und Build-Härtung greifbar macht.
Sigstore und Cosign ermöglichen keyless Signing von Open-Source-Releases über OIDC und ein öffentliches Transparenzprotokoll namens Rekor, das die Herkunft von Binaries nachträglich verifizierbar macht.
Das OpenSSF Best Practices Badge ist eine freiwillige und kostenlose Selbstzertifizierung, mit der Open-Source-Projekte dokumentieren, inwieweit sie etablierte Entwicklungs- und Sicherheitspraktiken umsetzen. Es kann Herstellern als zusätzliches Kriterium bei der Bewertung einer Komponente dienen. Auch die CISA empfiehlt grundsätzlich, gut gepflegte Open-Source-Projekte auszuwählen.
Das Alpha-Omega-Projekt ergänzt OpenSSF durch direkte Sicherheitsarbeit an konkreten Projekten. Finanziert von Microsoft und Google, konzentriert sich das Projekt auf zwei Bereiche: gezielte manuelle Sicherheitsprüfungen kritischer Open-Source-Projekte wie Node.js, Python, OpenSSL und Rust sowie automatisiertes Scanning des übrigen Open-Source-Ökosystems. Für Hersteller sind die öffentlich dokumentierten Alpha-Audit-Ergebnisse ein belastbarer Input für die eigene Risikoeinschätzung.
Für den deutschen Markt ist außerdem das Programm Sovereign Tech Fund der Sovereign Tech Agency relevant. Das Programm finanziert Verbesserungen an kritischer Open-Source-Infrastruktur wie curl, OpenSSH oder Projekten im Log4j-Umfeld. Förderung ist dabei ein nützliches Zeichen für Relevanz und Investitionsbereitschaft, ersetzt aber keine projektspezifische Sicherheitsbewertung.
Für Hersteller ergibt sich daraus ein konkreter Prozessschritt: Den OpenSSF-Scorecard-Wert einer Open-Source-Komponente als Kriterium bei der Komponentenauswahl dokumentieren. Ein Score unter 5 für eine sicherheitskritische Abhängigkeit kann als interne Heuristik Anlass für eine vertiefte Bewertung sein, ist aber kein CRA-Schwellenwert. Alpha-Omega-Audit-Ergebnisse gehören als Input in die Risikoeinschätzung nach Art. 13 Abs. 5 CRA.
Der CRA beendet die Grauzone um Open Source nicht vollständig, aber die finale Fassung ist wesentlich ausgewogener als frühe Entwürfe es befürchten ließen. Nicht-kommerzielle Open-Source-Projekte sind ausgenommen. Stewards tragen Pflichten nach Art. 24, aber in deutlich schlankerer Form als Hersteller. Und Hersteller, die Open Source integrieren, können auf eine gewachsene Infrastruktur aus OpenSSF-Tools, SBOM-Standards und Community-Initiativen zurückgreifen, die die Umsetzung erleichtert.
Für Hersteller ergeben sich drei konkrete nächste Schritte:
Für potenzielle Stewards gilt: Prüfe zuerst, ob du die Definition des Art. 3 Nr. 14 überhaupt erfüllst. Dokumentiere dann eine belastbare Cybersicherheitsstrategie, richte einen vertraulichen Meldeweg ein und kläre, in welchen Entwicklungskonstellationen Art. 24 Abs. 3 tatsächlich Meldepflichten auslöst. Die Grauzone zwischen kommerziell und nicht-kommerziell bleibt bestehen; im Zweifel ist eine rechtliche Einschätzung sinnvoll.
Wenn du die angrenzenden Themen Lieferkette, SBOM und Vulnerability Disclosure weiter vertiefen willst, schau in unsere Artikel zur CRA-Lieferkette: Supply Chain, zu SBOM für Embedded-Systeme und zur CRA CVD: Vulnerability Disclosure Policy.
Wie handhabst du die Open-Source-Sorgfaltspflicht in deinem Produkt, und wo ziehst du die Grenze zwischen Hersteller und Steward? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.
Weitere Artikel zu ähnlichen Themen.
