CRA und Open Source: Die neue Rolle des Open Source Stewards erklärt

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) gibt darauf eine klare Antwort, die viele überrascht: Die Haftung liegt beim Hersteller des Produkts, unabhängig davon, ob die Komponente kommerziell oder frei verfügbar ist.

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.

Betroffen oder nicht? Hersteller, Steward und die CRA-Grauzone

Die Grundregel des CRA ist klar: Wer ein Produkt mit digitalen Elementen auf dem EU-Markt in Verkehr bringt, ist vom CRA betroffen – unabhängig davon, ob das Produkt auf Open Source basiert. Für den Open-Source-Kontext sind drei Gruppen relevant.

Erstens der Hersteller nach Art. 3 Abs. 14 CRA: Wer ein Produkt kommerziell vertreibt, ist Hersteller, auch wenn die Basis Open Source ist. Ein kommerziell vertriebenes Linux-basiertes IoT-Gerät oder ein Industrie-Gateway auf Basis eines Open-Source-Betriebssystems sind typische Beispiele. Für Hersteller gelten die vollen Pflichten: CE-Kennzeichnung, technische Dokumentation, Konformitätsbewertung.

Zweitens der Open Source Steward, eine neue Kategorie, die der CRA in Art. 3 Nr. 14 einführt. Ein Steward ist eine juristische Person, die Open-Source-Projekte für die Nutzung in kommerziellen Tätigkeiten nachhaltig unterstützt, ohne das Produkt selbst in Verkehr zu bringen. 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: Wer Open Source ohne kommerzielle Absicht entwickelt – als Hobby-Maintainer, im akademischen Kontext oder als nicht-kommerzielles Non-Profit-Projekt ohne Industrieförderung – fällt nach Erwägungsgrund 18 und 19 nicht in den Geltungsbereich des CRA.

Die entscheidende Frage ist damit: Wann ist eine Aktivität kommerziell? Erwägungsgrund 19 nennt konkrete Indikatoren: bezahlter Support, kostenpflichtige Tiers, SaaS-Modelle auf Basis des Projekts, employer-maintained Open Source (also Mitarbeiter, deren Hauptaufgabe die Pflege des Projekts ist), Dual-Licensing mit bezahltem Tier, oder indirekte Einnahmen durch Daten oder strategischen Vorteil für ein Unternehmen. Rein altruistische Hobby-Maintainer ohne monetäre Gegenleistung sind dagegen ausgenommen.

Viele populäre Projekte bewegen sich in der Grauzone zwischen diesen Polen. Im Zweifel gilt: Wer die Vertreibungshandlung vornimmt, also das Produkt konkret auf den EU-Markt bringt, ist Hersteller. Die Eclipse Foundation und die Linux Foundation haben Leitfäden veröffentlicht, wie sie die eigene Einordnung vornehmen – eine gute Orientierung für ähnlich strukturierte Organisationen.

Die neue Rolle des Open Source Stewards

Der Begriff Open Source Steward ist eine Schöpfung des CRA. Art. 3 Nr. 14 CRA definiert ihn als eine juristische Person, die Open-Source-Software auf nachhaltige Weise für die Nutzung in kommerziellen Tätigkeiten unterstützt und die Lebensfähigkeit dieser Software sicherstellt, ohne das Produkt selbst in Verkehr zu bringen. Drei Schlüsselkriterien stecken in dieser Definition: juristische Person (kein Einzelpersonen-Maintainer), nachhaltige Unterstützung und fehlende Vertreibungshandlung.

Typische Steward-Organisationen 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 qualifizieren. Die Apache Software Foundation hat dazu eine öffentliche Stellungnahme veröffentlicht, in der sie ihre eigene Einordnung als Steward erläutert.

Der wichtigste Unterschied zum Hersteller: Der Steward bringt das Produkt nicht in Verkehr. Er ist nicht der Ursprung eines kommerziellen Produkts auf dem EU-Markt, sondern die Organisation, die das Projekt am Leben erhält. Das bedeutet: CE-Kennzeichnung, Konformitätsbewertung und technische Dokumentation nach Annex VI entfallen. Stattdessen gelten die deutlich schlankeren Pflichten aus Art. 24 CRA.

Ein wichtiger Hinweis: Der Steward kann nicht als regulatorischer Puffer für Hersteller dienen. Wer ein Open-Source-Projekt in ein eigenes kommerzielles Produkt integriert und dieses in Verkehr bringt, ist Hersteller, nicht Steward – unabhängig davon, ob die genutzte Bibliothek einen CRA-konformen Steward hat.

Art. 24 CRA: Was Open Source Stewards konkret tun müssen

Art. 24 Abs. 1 bis 3 CRA definiert vier konkrete Pflichten für Stewards, die trotz ihrer Schlankheit operativ belastbar umgesetzt werden müssen.

Die erste Pflicht ist eine dokumentierte Security Policy (Art. 24 Abs. 1 lit. a). Der Steward muss eine Sicherheitsrichtlinie für das Projekt einführen und anwenden. Sie muss Prozesse zur Behandlung von Schwachstellen abdecken, die Kommunikation von Sicherheitsinformationen regeln und Kriterien für die Annahme von Security-Contributions definieren. Die Policy muss weniger detailliert sein als Annex I für Hersteller, aber sie muss nachweisbar existieren und angewendet werden. Die praktische Umsetzung ist eine SECURITY.md-Datei im Repository, kombiniert mit einem verlinkten Disclosure-Verfahren. Die OpenSSF stellt dafür Templates bereit.

Die zweite Pflicht ist eine erreichbare CVD-Kontaktstelle (Art. 24 Abs. 1 lit. b). Der Steward muss sicherstellen, dass Sicherheitsforscher Schwachstellen melden können, ohne öffentliche Issues zu erstellen. GitHub Private Vulnerability Reporting ist ein technisch valider Weg, sofern es aktiviert und aktiv betreut wird. Eine security.txt nach RFC 9116 auf der Projektwebsite ist kein gesetzlicher Pflichtbestandteil, aber ein belastbares Signal einer vorhandenen CVD-Kontaktstelle.

Die dritte Pflicht betrifft Meldungen bei aktiv ausgenutzten Schwachstellen (Art. 24 Abs. 2 i.V.m. Art. 14). Stewards müssen aktiv ausgenutzte Schwachstellen in den von ihnen betreuten Projekten an ENISA melden. Die Fristen sind identisch mit der Herstellerpflicht: 24-Stunden-Early-Warning, 72-Stunden-Intermediate-Report, 14-Tage-Final-Report. Ausführlichere Details zu diesen Meldepflichten und ihrer operativen Umsetzung erklärt unser Artikel: CRA Meldepflichten.

Die vierte Pflicht ist die Kooperation mit Marktüberwachungsbehörden (Art. 24 Abs. 3). Stewards müssen auf Anforderung Informationen bereitstellen und bei Untersuchungen mitwirken. Das ist keine aktive Berichtspflicht, sondern eine Reaktionspflicht.

Die Security Policy für ein Open-Source-Projekt kann in öffentlichen Governance-Dokumenten wie GOVERNANCE.md oder SECURITY.md festgehalten werden. Das ist sowohl community-freundlich als auch regulatorisch belastbar, sofern der Inhalt die Anforderungen aus Art. 24 Abs. 1 lit. a abdeckt.

Was Unternehmen beim Einsatz von Open Source beachten müssen

Wer Open-Source-Komponenten in ein kommerzielles Produkt integriert, ist Hersteller im CRA-Sinne und trägt die volle Produktverantwortung. 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 – für den Hersteller des integrierenden Produkts ändert sich dadurch nichts an seinen Pflichten.

Art. 13 Abs. 5 CRA verlangt bei der Integration von Drittkomponenten angemessene Sorgfalt, also nachweisliche Risikobewertung und -minderung. Für Open-Source-Komponenten heißt das: Ein Hersteller muss bewerten, ob ein Projekt aktiv gepflegt wird, ob Schwachstellen zeitnah behoben werden und ob eine Security Policy sowie eine CVD-Kontaktstelle existieren.

Praktische Due-Diligence-Maßnahmen für Open-Source-Komponenten umfassen:

• Bewertung der Projektvitalität: Aktive Maintainer? Regelmäßige Releases? Reaktion auf CVEs in der Vergangenheit?
• OpenSSF Scorecard als automatisierbarer Gesundheitscheck mit einem Score von 0 bis 10 auf Basis von Kriterien wie Branch Protection, Signed Releases und Dependency Updates
• Lizenzprüfung anhand von SPDX-Identifiers
• Prüfung, ob das Projekt einen Art.-24-konformen Steward hat: Existiert eine Security Policy? Gibt es eine CVD-Kontaktstelle?

Für Unternehmen mit einer größeren Anzahl genutzter Open-Source-Komponenten ist ein Open Source Programme 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. Detaillierte Anforderungen an Lieferantenvereinbarungen und Supplier-SBOMs behandelt unser Artikel zur CRA-Lieferkette.

SBOM und Open Source: Komponenten tracken und Risiken monitoren

Die SBOM-Pflicht aus Annex I, Teil II, Anforderung 1 gilt unabhängig davon, ob eine Komponente kommerziell oder Open Source ist. Open-Source-Abhängigkeiten stellen dabei eine besondere Herausforderung dar: Ein einziges npm-Paket kann 50 oder mehr transitive Abhängigkeiten mitbringen, von denen viele keine eigene CVE-Abdeckung haben, weil keine CVE Numbering Authority dahintersteht.

Package URLs (PURLs) sind der Schlüssel zur eindeutigen Identifikation von Open-Source-Paketen in SBOMs. Ein PURL wie pkg:npm/%40angular/core@17.0.0 identifiziert eine Komponente eindeutig und ermöglicht automatisches CVE-Matching gegen NVD, OSV.dev und die ENISA EUVD. CycloneDX und SPDX unterstützen PURLs nativ.

Für Open-Source-Schwachstellen sind neben der NVD zwei Quellen besonders relevant: OSV.dev aggregiert Schwachstellen aus GitHub Security Advisories, PyPI Advisory, Go Vulnerability Database und weiteren Ökosystemen in einem maschinenlesbaren Format. GitHub Security Advisories sind für viele OS-Projekte die primäre Quelle für CVE-Vergaben, da GitHub selbst als CVE Numbering Authority (CNA) agiert.

Ein praxiserprobter Toolstack für SBOM-Generierung und Open-Source-Monitoring:

Der empfohlene Monitoring-Loop ist: SBOM bei jedem Build erzeugen, in Dependency-Track einspielen, automatisches Alerting bei neuen CVEs konfigurieren. Der Bezug zur Meldepflicht ist direkt: Wenn CISA KEV oder die ENISA EUVD eine Open-Source-Komponente als aktiv ausgenutzt markiert, ist das der Auslöser für die 24-Stunden-Early-Warning nach Art. 14 CRA.

Wie ein vollständiges Komponenteninventar für Embedded-Systeme und SPS-Umgebungen aufgebaut wird, beschreibt unser Artikel: SBOM für Embedded-Systeme. Einen Einstieg in die SBOM-Grundlagen bietet unser Artikel: SBOM-Grundlagen.

Community-Initiativen: OpenSSF, Alpha-Omega und die Sicherheitsinfrastruktur

Die CRA-Debatte hat die Open-Source-Community stark geprägt. 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 – Branch Protection, Signed Releases, Dependency Update Tools, Code Review und mehr – und gibt einen Score von 0 bis 10. SLSA (Supply-chain Levels for Software Artifacts) ist ein Framework mit vier Vertrauensstufen für Build-Integrität; ab Level 2 gibt es Versionskontrolle und einen nachvollziehbaren Build-Prozess, Level 3 und 4 sind für hochsicherheitskritische Lieferketten relevant. Sigstore und Cosign ermöglichen keyless Signing von Open-Source-Releases über OIDC und ein öffentliches Transparenzprotokoll (Rekor), das die Herkunft von Binaries nachträglich verifizierbar macht. Das OpenSSF Best Practices Badge schließlich ist ein Community-geprüftes Self-Assessment für Open-Source-Projekte, das von der CISA als Orientierung für die Komponentenauswahl empfohlen wird.

Das Alpha-Omega-Projekt ergänzt OpenSSF durch direkte Sicherheitsarbeit an konkreten Projekten. Finanziert von Microsoft und Google, fokussiert es auf zwei Stränge: Gezielte manuelle Security Engagements bei kritischen Projekten wie Node.js, Python, OpenSSL oder Rust (Alpha) und automatisiertes Scanning des langen Schwanzes des OS-Ökosystems (Omega). 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 der Sovereign Tech Fund relevant. Die deutsche Förderinitiative finanziert Sicherheitsverbesserungen in kritischer Open-Source-Infrastruktur wie curl, OpenSSH oder Projekten im Log4j-Nachfolgebereich. Projekte, die STF-Förderung erhalten haben, können als vertrauenswürdiger eingestuft werden, da eine externe Sicherheitsbewertung stattgefunden hat.

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 sollte Anlass für eine vertiefte Bewertung sein. Alpha-Omega-Audit-Ergebnisse gehören als Input in die Risikoeinschätzung nach Art. 13 Abs. 5 CRA.

Praktische Umsetzung für Open-Source-Projekte

Dieser Abschnitt richtet sich an Maintainer und Organisationen, die als Steward nach Art. 24 CRA agieren oder einordnen müssen, ob das auf sie zutrifft.

Die SECURITY.md-Datei ist der GitHub-Standard für die Kommunikation einer Security Policy und CVD-Kontaktstelle. Sie gehört in das Repository-Root oder den .github/-Ordner. Wenn sie vorhanden ist, zeigt GitHub automatisch einen Button Report a vulnerability auf der Projektseite an. Eine minimale SECURITY.md für ein Art.-24-konformes Projekt sieht so aus:

# Security Policy

## Supported Versions

| Version | Supported |
| ------- | --------- |
| 2.x     | ✅ Ja     |
| 1.x     | ❌ Nein   |

## Schwachstellen melden

Bitte melde Sicherheitslücken **nicht** als öffentliches Issue.
Nutze stattdessen [GitHub Private Vulnerability Reporting](https://github.com/YOUR-ORG/YOUR-REPO/security/advisories/new)
oder sende eine E-Mail an security@example.org.

Wir bestätigen den Eingang innerhalb von **5 Werktagen**
und kommunizieren den geplanten Fix-Zeitraum.

## Coordinated Disclosure

Wir folgen einem 90-Tage-Disclosure-Fenster ab dem Zeitpunkt der Meldung.
Bei aktiv ausgenutzten Schwachstellen behalten wir uns eine frühere Veröffentlichung vor.

Für Projekte mit eigener Website oder Dokumentationsdomäne ist eine security.txt nach RFC 9116 unter /.well-known/security.txt ein belastbares Signal einer CVD-Kontaktstelle:

Contact: mailto:security@example.org
Expires: 2027-07-21T00:00:00.000Z
Preferred-Languages: de, en
Policy: https://example.org/security-policy

Den Generator für security.txt-Dateien stellt securitytxt.org bereit.

GitHub Private Vulnerability Reporting ermöglicht die Schwachstellenkoordination direkt im Repository. Sicherheitsforscher können Schwachstellen privat melden, ohne ein öffentliches Issue zu erstellen. Der Maintainer arbeitet die CVE-Koordination in GitHub Security Advisories ab und kann direkt eine CVE-ID anfordern, da GitHub als CVE Numbering Authority (CNA) registriert ist. Eine Schritt-für-Schritt-Anleitung dazu stellt die GitHub-Dokumentation bereit.

Eine Art.-24-konforme Minimalstruktur für ein Open-Source-Projekt umfasst sechs Punkte:

1. SECURITY.md erstellt, mit Kontaktweg und Scope
2. GitHub Private Vulnerability Reporting aktiviert oder E-Mail-Kontakt eingerichtet
3. Disclosure Policy mit Timeline und Safe-Harbor-Erklärung dokumentiert
4. Supported Versions klar kommuniziert
5. security.txt auf der Projektwebsite vorhanden (falls zutreffend)
6. Prozess für CVE-Assignment definiert (GitHub CNA, MITRE direkt oder via Koordinator)

Ausführlichere Grundlagen zur CVD-Policy – auch für Hersteller – erklärt unser Artikel: CRA CVD: Vulnerability Disclosure Policy.

Open Source Security als geteilte Verantwortung

Der CRA beendet die Grauzone um Open Source – 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 deutlich schlankere 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: Ein OS-Inventar als SBOM erstellen und bestehende Open-Source-Komponenten auf Projektvitalität und Security Practices prüfen. Den OpenSSF Scorecard als Screening-Kriterium in den Komponentenauswahlprozess integrieren. Und für genutzte Open-Source-Projekte prüfen, ob eine Security Policy und CVD-Kontaktstelle existieren, da das ein Indikator für einen Art.-24-konformen Steward ist.

Für potenzielle Stewards gilt: Prüfen, ob Art. 24 CRA greift, SECURITY.md und CVD-Kontaktstelle einrichten, eine Security Policy für das Projekt dokumentieren und einen Meldeprozess für aktiv ausgenutzte Schwachstellen an ENISA vorbereiten. Die Grauzone zwischen kommerziell und nicht-kommerziell bleibt bestehen; im Zweifel ist eine rechtliche Einschätzung sinnvoll.

Weiterführende Artikel der Reihe: CRA-Lieferkette: Supply Chain, SBOM für Embedded-Systeme und CRA CVD: Vulnerability Disclosure Policy.

Wie handhabst du die Open-Source-Sorgfaltspflicht in deinem Produkt – oder planst du, als Steward zu agieren? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.