Nachdem der beschlossene Gesetzestext für den Cyber Resilience Act (CRA) Ende 2024 veröffentlicht wurde, sind nun die Vorbereitungen für die Umsetzung gestartet. Bis Ende 2027 müssen Unternehmen die Anforderungen des CRA vollständig erfüllen, einige Regelungen gelten allerdings schon ab Mitte 2026. Im Rahmen verschiedener Standardisierungsvorhaben wird bis dahin noch festgelegt, was dann auf welche Art erfüllt sein muss. Die Open Source Business Alliance (OSBA) engagiert sich an unterschiedlichen Stellen bei diesen Umsetzungsaktivitäten. Hier geben wir einen kleinen Einblick in einige dieser Initiativen.
CRA-Compliance: Die Uhr für die Umsetzung tickt
Am 20. November 2024 wurde der CRA im „Official Journal“ der European Union veröffentlicht. Laut Gesetzestext müssen Unternehmen 36 Monate nach dieser Veröffentlichung die Anforderungen des CRA erfüllen, also Ende 2027. Einige Anforderungen mit Blick auf die Meldepflichten der Hersteller müssen jedoch bereits 21 Monate nach der Veröffentlichung des CRA erfüllt werden, also bereits im Herbst 2026.
Gerade für Unternehmen, die sich bisher noch gar nicht mit dem CRA und den Anforderungen und Dokumentationspflichten auseinander gesetzt haben, ist es wichtig, dass sie die verbleibende Zeit bis 2026 bzw. 2027 nutzen, um sich möglichst frühzeitig mit dem Themenkomplex zu beschäftigen. Es ist nicht ratsam, sich erst kurz vor Ablauf der Frist damit zu befassen, welche der umfangreichen Pflichten zu erfüllen sind. Für einen ersten Einstieg in das Thema bietet sich z.B. dieses Interview zu den Grundlagen des CRA an.
Neben dem CRA auch die Product Liability Directive im Blick behalten
Neben dem CRA wurde 2024 auch die Product Liability Directive (PLD) verabschiedet. Hier wird geregelt, wann und wie Hersteller von fehlerhaften Produkten für Mängel haften müssen. So können Software-Hersteller beispielsweise für Schäden haftbar gemacht werden, die aus fehlenden oder unzureichenden Software-Updates oder schwachen Sicherheitsmaßnahmen rund um ein digitales Produkt entstanden sind.
Während der CRA eine EU-Verordnung ist, die direkt in allen EU-Mitgliedsstaaten wirksam wird, ist die PLD eine Richtlinie. Das bedeutet, dass die EU-Mitgliedsstaaten die Vorgaben aus der PLD jeweils noch in ihr nationales Recht umsetzen müssen. Die EU-Mitgliedsstaaten haben dafür bis 2026 Zeit.
Standardisierung, Richtlinien und Handreichungen
Im Gesetzestext des CRA selbst sind die Anforderungen an die betroffenen Unternehmen noch recht allgemein formuliert. So sollen sie beispielsweise eine Bewertung der Cybersicherheitsrisiken durchführen, die ein Produkt mit digitalen Elementen mit sich bringen kann. Was aber genau im Rahmen dieser Risikobewertung getan werden muss und wann ein Unternehmen wirklich alle vernünftigerweise erwartbaren Anstrengungen unternommen hat, um diese Anforderungen zu erfüllen, ist derzeit noch nicht klar definiert. Es gibt also im Moment noch keine praktischen Checklisten, die eine Firma einfach abarbeiten könnte.
Normung und Standardisierung
Aus diesem Grund hat die EU-Kommission die Europäischen Normungs- und Standardisierungsorganisationen ETSI und CEN/CENELEC gebeten, die konkreten technischen Anforderungen an die Unternehmen detaillierter auszuarbeiten. Welche Anforderungen standardisiert werden sollen, hat die EU-Kommission in ihrem offiziellen „standardization request“ festgelegt. Der „standardization request“ ist noch nicht final verabschiedet, das wird voraussichtlich im Laufe des Jahres 2025 passieren.
In dem „standardization request“ werden 41 Standards genannt, die festgelegt werden müssen:
- 15 davon sind „horizontale Standards„, die alle Unternehmen unabhängig von der Branche betreffen. Z.B. „Wie entwickele ich ein sicheres Produkt?“. Diese horizontalen Standards werden beim Europäischen Komitee für Normung und dem Europäischen Komitee für elektrotechnische Normung (CEN/CELENEC) erarbeitet. Die 15 horizontalen Standards teilen sich in drei Gruppen auf:
- „Principles for cyber resilience“:
Risikobeurteilung und -management über den gesamten Produktlebenszyklus hinweg. - „Generic Security Requirements“:
Anforderungen rund um die Produktentwicklung. - „Vulnerability handling“:
Die erforderlichen Prozesse im Umgang mit Sicherheitslücken.
- „Principles for cyber resilience“:
- 26 der 41 Standards sind „vertikale Standards„, sie betreffen bestimmte technische Bereiche oder Branchen oder sind produktspezifisch. Diese vertikalen Standards werden beim „Europäischen Institut für Telekommunikationsnormen“ (ETSI) erarbeitet.
Mitarbeit im DIN
Wenn sich Unternehmen oder Verbände an der Erarbeitung dieser CRA-Standards auf EU-Ebene beteiligen möchten, müssen sie zunächst Mitglied in ihrer nationalen Normungs- und Standardisierungsorganisation werden. In Deutschland ist das das Deutsche Institut für Normung (DIN). Mitglieder aus dem für den CRA zuständigen Arbeitsausschuss im DIN werden dann in das entsprechende „Spiegelgremium“ auf EU-Ebene entsendet, in dem Mitglieder aus allen EU-Mitgliedsstaaten zusammen die CRA-Standards ausarbeiten.
Damit bei diesen Standardisierungsarbeiten auch die Perspektive der Open-Source-Branche vertreten ist, wurde die Open Source Business Alliance (OSBA) 2024 Mitglied im DIN. Derzeit beteiligen sich zwei OSBA-Mitglieder an der Standardisierung im DIN bzw. bei CEN/CENELEC und nehmen für die OSBA an den Sitzungen teil.
Standardisierung von CycloneDX
Die OSBA ist zudem im Zusammenhang mit dem CRA Mitglied bei Ecma geworden. Ecma International ist eine private, internationale Normungsorganisation zur Normung von Informations- und Kommunikationssystemen und Unterhaltungselektronik.
Ecma standardisiert u.a. CycloneDX. Das ist ein wichtiger technischer Standard für Software Bills of Material (SBOM). Diese spielen im Zusammenhang mit dem CRA eine wichtige Rolle, da über SBOMs Informationen entlang der Lieferkette erfasst und kommuniziert werden können. Die SBOM listet auf, welche Softwarekomponenten oder Pakete in einem Produkt integriert sind. Die Aufstellung der Software-Bestandteile, die in der SBOM aufgelistet werden, erleichtert Herstellern und Unternehmen u.a. die schnelle Prüfung, ob sie von einer Sicherheitslücke betroffen sind. Auch hier vertritt ein OSBA-Mitglied den Verband, beteiligt sich an der Standardisierungsarbeit und trägt aktuelle Informationen in die entsprechende Arbeitsgruppe zurück.
CRA Expert Group
Die EU-Kommission hat für die Begleitung der Standardisierung und der Umsetzungsvorbereitungen eine „CRA Expert Group“ ins Leben gerufen. Diese soll die Kommission u.a. bei der Erstellung von Hilfestellungen und Hinweisen für die Umsetzung des CRA beraten.
OSBA-Mitglied Stackable GmbH hat sich auf einen Sitz in der CRA Expert Group beworben und wurde von der EU-Kommission für die Mitarbeit ausgewählt. Neben Stackable sind auch noch einige andere Open-Source-Organisationen in der CRA Expert Group vertreten, u.a. die deutsche Sovereign Tech Agency (STA), die Apache Software Foundation (ASF), die Open Source Security Foundation (OpenSSF) und die Eclipse Foundation.
Technische Richtlinien des Bundesamtes für Sicherheit in der Informationstechnik
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bietet ebenfalls Unterstützung bei der Umsetzung und hat mit Bezug zum CRA eine Technische Richtlinie zu „Cyber-Resilienz-Anforderungen“ (TR-03183) erarbeitet. Damit soll Software-Herstellern die Umsetzung der Anforderungen des CRA erleichert werden, indem Begriffe näher definiert und Beispiele genannt werden. Zudem werden mögliche Vorgehensweisen bei der Umsetzung beschrieben. Die Technische Richtlinie bietet daher einen guten Einstieg für Hersteller, die sich fragen, welche konkreten Schritte sie unternehmen können, um auf eine CRA-Compliance hinzuarbeiten.
Die Richtlinie zu Cyber-Resilienz-Anforderungen (TR-03183) ist unterteilt in drei Teile:
- Teil 1 – General Requirements:
Erklärungen zu Begriffen sowie die Beschreibung der Sicherheitsanforderungen („Security Requirements“) und der Dokumentationspflichten („Documentation Obligations“) aus dem CRA. - Teil 2 – Software Bill of Materials:
Erklärungen zu verschiedenen Arten von SBOMs. - Teil 3 – Vulnerability Reports and Notifications:
Der Umgang mit Schwachstelleninformationen und koordinierte Schwachstellenmeldung.
Das BSI arbeitet an weiteren Dokumenten zur Unterstützung bei der Umsetzung des CRA. So hat das BSI auch eine Technische Richtlinie „Sicherer Software-Lebenszyklus“ (TR-03185) mit Best Practices zur Software-Entwicklung veröffentlicht. Das BSI erläutert aber auf seiner Webseite, dass sich diese Technische Richtlinie in ihrem aktuellen Stand nicht auf Prozesse zur Entwicklung von Open Source Software anwenden lässt. Für diesen Zweck müssten die Anforderungen an die Eigenheiten der Entwicklung von Open Source Software angepasst werden. Möglicherweise wird das BSI hier also noch eine eigene Technische Richtlinie mit Bezug zur sicheren Software-Entwicklung von Open Source Software erarbeiten.
Die Technische Richtlinie „Common Security Advisory Framework (CSAF)“ (TR-03191) bietet Hinweise, wie Sicherheitsinformationen über Schwachstellen automatisiert abgerufen und verarbeitet werden können. Das reduziert den Aufwand beim Management der Sicherheitsinformationen und erlaubt eine einfache, automatisierte Feststellung der Betroffenheit oder Nicht-Betroffenheit durch eine Schwachstelle – ganz unabhängig davon, ob Open Source oder proprietäre Software im Einsatz ist.
Der ultimative Überblick über den CRA-Gesetzestext
OSBA-Mitglied Karsten Klein von metaeffekt GmbH hat im Rahmen der Task Force CRA in der OSBA ein bemerkenswertes Dokument erstellt, mit dem man sich einen sehr guten Überblick über alle Details des Gesetzestextes verschaffen kann. In diesem Tabellendokument findet sich zum einen eine detaillierte Übersicht über die Timeline des CRA: also wo im CRA sind welche Fristen (z.B. für die Umsetzung) festgelegt und wann laufen diese Fristen ab. Zum anderen bietet das Dokument eine vollständige Übersicht über die einzelnen Artikel und Paragrafen des CRA, diese sind auf Deutsch und Englisch direkt nebeneinander gestellt.
In dem Dokument findet sich zudem ebenfalls eine Aufschlüsselung der verschiedenen Rollen, Akteure und Organisationen, die im CRA genannt werden und die alle unterschiedliche Aufgaben und Verpflichtungen erfüllen müssen. Seine besondere Wirkkraft entfaltet das Dokument durch die Möglichkeit, die einzelnen Artikel und Paragrafen des CRA nach den verschiedenen Rollen oder anderen Aspekten zu filtern. Das Dokument hilft also, den CRA in der Ansicht jeweils auf eine an die jeweilige Rolle angepasste Form für zu reduzieren. So ergibt sich schnell ein Überblick, an welchen Stellen im CRA Anforderungen beispielsweise an die Open-Source-Software-Stewards, die Software-Hersteller oder andere Akteure gestellt werden.
Das Tabellendokument, das OSBA-intern unter der Bezeichnung „Requirements Analyse“ bekannt ist, kann hier als .xlsx und hier als .ods heruntergeladen werden.
Die Task Force CRA in der OSBA arbeitet derzeit an einer Handreichung, in die u.a. Informationen aus dieser Requirements Analyse einfließen sollen, und die zentrale Anwendungsfälle und Akteure aus dem Cyber Resilience Act beschreibt. Die Handreichung ordnet dabei auch das Thema SBOM in den Anwendungsfällen ein und erörtert, welchen Kriterien eine SBOM zur Qualifikation für die angedachten Verfahren genügen muss („qualified SBOM“). Die Handreichung soll insbesondere Open-Source-Unternehmen wichtige Hinweise zur Umsetzung des CRA geben.
Die Task Force CRA in der OSBA befasst sich bis zum Inkrafttreten des CRA 2027 mit den Anforderungen und Auswirkungen des CRA auf Unternehmen im Open-Source-Umfeld. Die Task Force CRA trifft sich regelmäßig alle zwei Wochen. Interessierte sind herzlich zum Reinschnuppern und zur Mitarbeit eingeladen!
