Quickstart: CRA (Cyber Resilience Act)

Was ist der Cyber Resilience Act?

Der europäische Cyber Resilience Act (CRA) zielt darauf ab, die Rahmenbedingungen für die Entwicklung sicherer Produkte mit digitalen Elementen festzulegen, indem sichergestellt wird, dass Hardware- und Softwareprodukte mit weniger Schwachstellen auf den Markt gebracht werden und dass die Hersteller die Sicherheit während des gesamten Lebenszyklus eines Produkts ernst nehmen. Sie wurde im September 2022 ins Europäischen Parlament eingebracht und im März 2024 verabschiedet. Mit dem Gesetz werden gemeinsame Regeln für Hersteller und Entwickler festgelegt.

Zu den wichtigsten Zielen gehören die Verbesserung der Sicherheit von mit dem Internet verbundenen Produkten und Software auf dem EU-Markt, die Verantwortung der Hersteller für die Cybersicherheit während des gesamten Lebenszyklus eines Produkts und die Gewährleistung, dass die Verbraucher angemessene Informationen über die Cybersicherheit von Produkten erhalten. Die Gesetzgebung erlegt denjenigen, die digitale Produkte auf dem EU-Markt in Verkehr bringen, zusätzliche Verpflichtungen auf, wobei der Schwerpunkt auf Meldepflichten, der Einhaltung von Vorschriften, der Behebung von Schwachstellen, der Aktualisierung von Software und der Überprüfung von Produkten liegt. Insbesondere verlagert das Gesetz die Last der Cybersicherheit auf die Softwareentwickler, indem es von deren Fachwissen bei der Behebung von Schwachstellen und der Verteilung von Patches ausgeht und letztlich auf eine sicherere digitale Landschaft in der EU abzielt.

Wer ist betroffen?

Alle Hersteller von Hardware- oder Softwareprodukten, die mit dem Internet verbunden sind, unabhängig davon, ob es sich um Open-Source-Produkte handelt oder nicht, und die Nutzer in der EU haben, d. h. fast jeder – denn Sie haben mit Sicherheit auch Nutzer in der EU.

Wer ist vom CRA ausgenommen

Jeder, der Software entwickelt und veröffentlicht oder Hardware herstellt, die Software für gemeinnützige Zwecke enthält, ist von den CRA-Anforderungen befreit. Es gibt strenge Definitionen dafür, was als gemeinnützig bzw. „nicht gewinnorientiert“ gilt.

Wie wird der CRA durchgesetzt?

Die Mitgliedstaaten werden Marktüberwachungsbehörden (MSA) benennen, die die in dem CRA festgelegten Verpflichtungen durchsetzen werden. Wenn eine Nichteinhaltung festgestellt wird, sind die MSA befugt:

1. die Hersteller aufzufordern, die Nichtkonformität zu beenden und das Risiko zu beseitigen;
2. die Bereitstellung eines Produkts zu verbieten/einzuschränken oder anzuordnen, dass das Produkt zurückgenommen/zurückgerufen wird;
3. Sanktionen zu verhängen (einschließlich Geldbußen bis zu 15 000 000 EUR oder bis zu 2,5 % des weltweiten Umsatzes).

Welche Software ist betroffen?

Alle „Produkte mit digitalen Elementen“. Es gibt zwei Unterkategorien – Klasse 1 und Klasse 2 – von Software, an die höhere Anforderungen gestellt werden. Diese Kategorien sind in Anhang III der CRA ausführlich beschrieben und umfassen Webbrowser, Passwortmanager, VPNs, Netzwerkmanagementsysteme, Firewalls, Identitätsmanagementsysteme, Betriebssysteme, Container-Laufzeitsysteme usw.

Das CRA gilt nicht für Cloud-Computing-Dienste wie Software-as-a-Service (SaaS), die unter die NIS2-Richtlinie fallen, oder für Produkte, die bereits durch EU-Rechtsvorschriften geregelt sind, die für Medizinprodukte, In-vitro-Diagnostika, die Zivilluftfahrt, Kraftfahrzeuge und Produkte gelten, die ausschließlich für die nationale Sicherheit oder militärische Zwecke entwickelt wurden.

Die CRA gilt auch nicht für freie und quelloffene Software (Open Source), die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird. Die ursprünglich geplanten Verantwortlichkeiten für Open-Source-Communities haben sich jedoch stark verändert, als die Gemeinschaft anfing Bedenken zu äußern: nun wurde das Konzept eines „Open-Source-Stewards“ eingeführt.

Welche Verpflichtungen erlegt die CRA mir als kommerziellen Anbieter auf?

Der Cyber Resilience Act erlegt Softwareanbietern vier Hauptkategorien von Verpflichtungen auf: Durchführung von Risikobewertungen, Pflege der Dokumentation, Durchführung von Konformitätsbewertungen und Meldung von Schwachstellen. Hersteller, Importeure und Vertreiber von Hardware- und Softwareprodukten haben 36 Monate Zeit, sich an die neuen Anforderungen anzupassen.

Nachstehend finden Sie einige Beispiele für die Anforderungen pro Kategorie; die vollständige Liste finden Sie in den Anhängen I, V und VI der CRA.

Risikobewertung:

1. Software wird ohne bekannte ausnutzbare Sicherheitsschwachstellen ausgeliefert.
2. Einhaltung und Umsetzung sicherer Entwicklungspraktiken.
3. Veröffentlichung von Informationen über behobene Sicherheitslücken, sobald ein Sicherheitsupdate verfügbar ist.
4. Sicherheitspatches und Aktualisierungen sind unverzüglich und kostenlos verfügbar.

Die vollständige Liste der Sicherheitsbewertungen finden Sie in Anhang I.

Dokumentation:

Die CRA verlangt, dass folgendes bereitgestellt wird:

1. Software Bill of Materials (SBOM), in der die Schwachstellen und die im Produkt enthaltenen Komponenten dokumentiert sind, sowie effektive und regelmäßige Tests.
2. Sobald Sie ein Sicherheitsupdate veröffentlichen, müssen Sie Informationen über die behobenen Schwachstellen öffentlich bekannt geben.

Konformitätsbewertungen:

1. Für hochkritische Produkte muss die Bewertung von einem unabhängigen, von der EU zertifizierten Prüfer durchgeführt werden.
2. Bei anderen Softwaretypen können die Hersteller die Bewertung selbst durchführen und müssen dann die CE-Kennzeichnung auf jedem einzelnen Produkt anbringen, das mit der in der EU-Baumusterprüfbescheinigung beschriebenen Bauart übereinstimmt und die geltenden Anforderungen der Rechtsvorschrift erfüllt.

Meldung von Schwachstellen:

Gemäß Artikel 11 des CRA sind die Softwarehersteller verpflichtet, der EU-Agentur für Cybersicherheit (ENISA) alle nicht behobenen Sicherheitslücken innerhalb von 24 Stunden nach ihrer Entdeckung zu melden.

Wie wirkt sich die CRA auf die Verwendung von Open Source aus?

Bei der Verwendung von Open-Source-Bibliotheken liegt es in der Verantwortung des Anbieters, das mit diesen Bibliotheken verbundene Risiko zu bewerten, zu verfolgen und zu überwachen. Im Folgenden finden Sie einige Auszüge aus den CRA-Vorschriften zu diesem Thema:

• Juristische Personen, die die Entwicklung von freier und Open Source Software, die für kommerzielle Tätigkeiten bestimmt ist, nachhaltig unterstützen, sollten einem maßgeschneiderten Regulierungssystem unterworfen werden. (Absatz 10d)
• Die Gruppe für Verwaltungszusammenarbeit (ADCO) sollte Bewertungen der Abhängigkeit in der Union vornehmen, und die Marktaufsichtsbehörden können Software-Stücklisten (SBOMs) von den Herstellern anfordern, wobei die Vertraulichkeit durch die Übermittlung anonymisierter und aggregierter Informationen gewährleistet wird. (Absatz 10g)
• Die Hersteller müssen bei der Integration von Komponenten, einschließlich freier und quelloffener Software, mit der gebotenen Sorgfalt vorgehen und die Einhaltung der grundlegenden Anforderungen sicherstellen. Zu den Sorgfaltspflichten gehören die Überprüfung der Konformität, regelmäßige Sicherheitsaktualisierungen, Schwachstellenprüfungen und die Behebung festgestellter Schwachstellen durch Information und Behebung, auch bei freien und quelloffenen Komponenten. (Absatz 18a)
• Um die Schwachstellenanalyse zu erleichtern, sollten die Hersteller die in den Produkten enthaltenen Komponenten mit digitalen Elementen identifizieren und dokumentieren, unter anderem durch die Erstellung einer Software-Stückliste (SBOM).(Absatz 37)

Darüber hinaus spricht Artikel 10 von den Verpflichtungen, die Herstellern auferlegt werden:

• Zur Erfüllung der in Absatz 1 festgelegten Verpflichtung müssen die Hersteller bei der Integration von Komponenten, die von Dritten bezogen werden, die gebührende Sorgfalt walten lassen, so dass diese Komponenten die Cybersicherheit des Produkts mit digitalen Elementen nicht gefährden; dies gilt auch für die Integration von Komponenten freier und quelloffener Software, die nicht im Rahmen einer gewerblichen Tätigkeit auf dem Markt bereitgestellt wurden. (Absatz 4)
• Die Hersteller melden bei Feststellung einer Sicherheitslücke in einer Komponente, auch in einer Open-Source-Komponente, die in das Produkt mit digitalen Elementen integriert ist, die Sicherheitslücke der Person oder Einrichtung, die die Komponente herstellt oder wartet, und beheben die Sicherheitslücke gemäß den in Anhang I Abschnitt 2 festgelegten Anforderungen für den Umgang mit Sicherheitslücken.

Haben die Hersteller eine Software- oder Hardware-Änderung entwickelt, um die Schwachstelle in dieser Komponente zu beheben, so stellen sie der Person oder Einrichtung, die die Komponente herstellt oder wartet, den entsprechenden Code oder die Dokumentation zur Verfügung, gegebenenfalls in einem maschinenlesbaren Format. (Absatz 4a)

Wie kann Bitsea helfen?

Der CRA stellt eine Reihe neuer Anforderungen im Bereich der Cybersicherheit auf. Einer der Schlüsselbereiche, in welchem jeder Anbieter einen klaren Überblick haben sollte, ist die Software-Lieferkette. Dazu gehört auch die Nutzung von Open Source: Jedes Unternehmen muss Komponenten identifizieren, verwalten, Sicherheitslücken verfolgen und Patches installieren.

Um die Schwachstellenanalyse zu erleichtern, sollten Hersteller die in den Produkten enthaltenen Komponenten mit digitalen Elementen identifizieren und dokumentieren, unter anderem durch die Erstellung einer Software-Stückliste (SBOM).

Bitsea unterstützt Sie in allen Aspekten des Open-Source-Managements, damit Sie als Unternehmen vor mangelnder Compliance und Cyber-Angriffen auf die Software-Lieferkette geschützt sind. Bitsea hat über ein Jahrzehnt Erfahrung darin, Unternehmen dabei zu helfen, ihren Code zu verstehen und sehr detaillierte und auf ihre Bedürfnisse zugeschnittene SBOMs zu erstellen.

Darüber hinaus bieten wir:

• • Identifizieren von Sicherheitsschwachstellen in SBOM.
• • SBOM verwalten: Benachrichtigung, wenn eine neue Sicherheitslücke entdeckt wird.
• • Aufbau und Einrichtung von Werkzeugketten, um neue Software automatisch auf Open-Source-Komponenten zu analysieren.
• • Verwalten von FOSS-Daten: Welche Komponenten werden in einem Softwaresystem verwendet.
• • Unterstützung bei ISO 5230 & ISO 18974, Vorbereitung auf die Zertifizierung.