OpenSSF definiert drei Rollen, um Open‑Source‑Projekte beim EU‑Cyber‑Resilience‑Act zu unterstützen

Der Cyber‑Resilience‑Act (CRA) der Europäischen Union führt umfassende Sicherheitsverpflichtungen für alle Produkte ein, die digitale Komponenten enthalten, und wirkt sich tiefgreifend auf die gesamte Open‑Source‑Lieferkette aus. Um die komplexen gesetzlichen Vorgaben zu entmystifizieren, veröffentlichte die Open Source Security Foundation (OpenSSF) im September 2026 einen vorbereitenden Leitfaden, der das Ökosystem in drei klar abgegrenzte Rollen unterteilt und für jede Rolle die jeweiligen Pflichten im Kontext des CRA detailliert beschreibt.

Drei Rollen, drei Verantwortungsbereiche

Der Leitfaden differenziert das Open‑Source‑Umfeld in (1) Maintainer oder Mitwirkende, die Code beisteuern, (2) Open‑Source‑Stewards, juristische Personen, die langfristige Unterstützung und Governance für Projekte übernehmen, und (3) Hersteller, die fertige Produkte vermarkten, in denen Open‑Source‑Code eingebettet ist. Diese Taxonomie spiegelt die juristische Sprache des CRA wider, die zwischen reinen Code‑Beitragenden und Akteuren, die Produkte auf den Markt bringen, unterscheidet.

Für die Mehrheit der nicht‑kommerziellen Mitwirkenden bedeutet das, dass sie nicht als „Hersteller“ im Sinne des CRA gelten und damit nicht den umfassenden Melde‑ und Behebungspflichten des Gesetzes unterliegen. Ihre Kernaufgabe bleibt, die Qualität und Sicherheit des von ihnen entwickelten Codes sicherzustellen, ohne die schwere Compliance‑Belastung, die kommerzielle Akteure erwarten.

Die Rolle des Open‑Source‑Stewards

Ein Open‑Source‑Steward ist eine juristische Person, die langfristige Ressourcen, Governance‑Strukturen und Sicherheitsprozesse für Projekte bereitstellt, die in kommerziellen Anwendungen genutzt werden. Zu den typischen Aufgaben eines Stewards gehören das Erarbeiten und Pflegen einer Sicherheitsrichtlinie, das Koordinieren von Schwachstellenmeldungen sowie das Fördern der Zusammenarbeit zwischen Downstream‑Nutzern und den ursprünglichen Entwicklern.

Obwohl der CRA erst ab dem 11. Dezember 2027 explizite Pflichten für Stewards vorsieht, empfiehlt OpenSSF, bereits jetzt etablierte Sicherheitskontakte, klare Eskalationspfade und kollaborative Prozesse zu implementieren. Dieses proaktive Vorgehen erleichtert den nachgelagerten Herstellern die Einhaltung ihrer eigenen CRA‑Fristen und reduziert das Risiko von Verzögerungen bei der Produktfreigabe.

Hersteller und ihre strengen Fristen

Hersteller, die ein Produkt unter ihrer eigenen Marke vertreiben, tragen die breiteste Palette an Verpflichtungen. Seit dem 11. September 2026 müssen sie jede aktiv ausgenutzte Schwachstelle oder jeden schweren Sicherheitsvorfall innerhalb von 24 Stunden an die zuständige EU‑Behörde melden und die betroffenen Kunden innerhalb von 72 Stunden formal informieren. Verstöße können zu erheblichen Geldbußen und sogar zu Beschränkungen des Marktzugangs führen.

• Ein aktuelles SECURITY.md in jedem Repository pflegen
• Eine dedizierte Sicherheitskontakt‑Adresse bereitstellen, die kontinuierlich überwacht wird
• Supply‑Chain‑Attestierungs‑Tools wie SLSA, Sigstore, GUAC und OSPS Baseline einsetzen
• Eskalationsverfahren dokumentieren und mit Downstream‑Partnern teilen

Der Leitfaden betont zudem, dass diese Werkzeuge in automatisierte CI/CD‑Pipelines integriert werden sollten. Durch das Erzeugen kryptografischer Provenienz‑Records (SLSA) und das Signieren von Artefakten (Sigstore) können Projekte die Integrität ihrer Builds nachweisen – eine Anforderung, die Hersteller bei Audits durch EU‑Behörden erfüllen müssen.

Da ein einzelnes Unternehmen mehrere Rollen gleichzeitig übernehmen kann, rät der Leitfaden zu einer klaren internen Zuordnung der Verantwortlichkeiten. Beispielsweise muss ein Unternehmen, das sowohl zu einer Open‑Source‑Bibliothek beiträgt als auch ein Hardware‑Gerät verkauft, das diese Bibliothek enthält, die Beitragstätigkeit als Maintainer‑Aufgabe und die Geräte‑Verkaufstätigkeit als Herstellungs‑Aufgabe behandeln, jeweils mit eigenen Compliance‑Check‑listen.

OpenSSFs Empfehlungen stellen keine Rechtsberatung dar, sondern dienen als Orientierungshilfe für die Gemeinschaft, den Geist des CRA zu respektieren. Die Stiftung ermutigt alle Akteure, frühzeitig rechtlichen Rat einzuholen, insbesondere weil die Durchsetzungsmechanismen des CRA noch weiterentwickelt werden.

Praktische Schritte für deutsche Unternehmen

Für Unternehmen mit Sitz in Deutschland bedeutet dies konkret, zunächst zu prüfen, welche der drei definierten Rollen sie selbst einnehmen oder delegieren. Anschließend sollten sie die von OpenSSF vorgeschlagenen Sicherheitsdokumentationen – etwa ein aktuelles SECURITY.md und eine dedizierte Kontaktadresse – einführen und die empfohlenen Tools in ihre Build‑ und Release‑Prozesse integrieren.

Ein weiterer wichtiger Schritt ist die Etablierung schneller Meldeprozesse für entdeckte Schwachstellen, sodass die 24‑Stunden‑Meldepflicht und die 72‑Stunden‑Kundenbenachrichtigung zuverlässig eingehalten werden können. Durch klare interne Abläufe und regelmäßige Schulungen können Unternehmen das Risiko von Strafzahlungen minimieren.

Zusätzlich sollten Unternehmen regelmäßige Audits ihrer Supply‑Chain‑Prozesse durchführen, um sicherzustellen, dass alle genutzten Open‑Source‑Komponenten den Provenienz‑ und Signatur‑Anforderungen des CRA entsprechen. Dies stärkt nicht nur die Compliance, sondern erhöht auch die Gesamtsicherheit der Produkte im EU‑Markt.

Schließlich empfiehlt OpenSSF, aktiv an branchenspezifischen Arbeitsgruppen teilzunehmen, um Best Practices zu teilen und gemeinsam mit Regulierungsbehörden an der Weiterentwicklung des CRA mitzuwirken. Ein offener Dialog kann dazu beitragen, zukünftige regulatorische Anpassungen frühzeitig zu antizipieren und die Wettbewerbsfähigkeit deutscher Unternehmen zu sichern.

Insgesamt bietet der OpenSSF‑Leitfaden einen praxisorientierten Fahrplan, der sowohl technische als auch organisatorische Maßnahmen umfasst und Unternehmen dabei unterstützt, den wachsenden regulatorischen Anforderungen des EU‑Cyber‑Resilience‑Acts gerecht zu werden, ohne die Innovationskraft der Open‑Source‑Gemeinschaft zu gefährden.