Zum Inhalt

Framework-Übersicht: Der EU Cyber Resilience Act (CRA)

1. Kontext & Problemstellung

Der Cyber Resilience Act (CRA) erfasst alle Produkte, die "digitale Elemente" enthalten, von günstigen Consumer-Gadgets bis hin zu komplexer B2B-Software und hochmodernen Industriesystemen. Das Ziel ist es, Verbraucher und Organisationen vor Cybersicherheitsrisiken zu schützen.

Es geht also primär um physische Produkte oder Software, die ausgeliefert und beim Kunden lokal installiert wird. Also auch sowas wie Apps aus dem AppStore. Reine SaaS-Lösungen ohne installierbare Client- oder Hardware-Komponente fallen als Daumenregel nicht unter den CRA. Streng genommen definiert der Gesetzestext "Produkte mit digitalen Elementen" jedoch so, dass auch deren "remote data processing solutions" (also Cloud-/SaaS-Komponenten) eingeschlossen sind, wenn diese mit dem Gerät oder Netzwerk verbunden sind und für die Funktion des Produkts benötigt werden. Für FOSS gibt es eigene Regeln, ob sie unter den CRA fallen und so genannte Stewards.

Die Einordnung ist deshalb so entscheidend, weil der CRA die Hersteller langfristig in die Pflicht nimmt: Fällt ein Produkt in den Geltungsbereich, müssen die unten genannten Anforderungen während eines verpflichtenden Support-Zeitraums aufrechterhalten und Schwachstellen aktiv behoben werden. Dieser Zeitraum muss mindestens fünf Jahre betragen, es sei denn, die erwartete Nutzungsdauer des Produkts ist nachweislich kürzer.

2. Technische Kernanforderungen an die Produktentwicklung

Um die Konformität mit dem CRA zu erreichen und letztendlich die verpflichtende CE-Kennzeichnung am Produkt anbringen zu dürfen, müssen Hersteller verschiedene technische Maßnahmen nativ integrieren:

Bewertung von Cybersicherheitsrisiken

  • Gemäß Art. 13 Abs. 2 CRA haben Hersteller eine Bewertung der Cybersicherheitsrisiken durchzuführen, die ein Produkt mit digitalen Elementen birgt.
  • Das Ergebnis dieser Bewertung ist bei der Planungs-, Konzeptions-, Entwicklungs-, Herstellungs-, Liefer- und Wartungsphase zu berücksichtigen.
  • Diese Bewertung dient als zwingende Grundlage für die Umsetzung der wesentlichen Cybersicherheitsanforderungen.
  • Dieser Prozess sollte eigentlich auch kontinuierlich geschehen und dann, wenn sich etwas Größeres am Produkt ändert.

Produkte ohne bekannte ausnutzbare Schwachstellen

  • Der CRA fordert nachdrücklich, dass Produkte mit digitalen Elementen ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden.
  • Dies erfordert bei der Softwareentwicklung eine sorgsame Auswahl von Drittanbieterkomponenten und Open-Source-Bibliotheken.
  • Hersteller müssen ein aktives Schwachstellen-Monitoring auf den verwendeten Bibliotheken durchführen und diese idealerweise stets auf die neuesten Versionen aktualisieren.

Transparenz durch die Software-Stückliste (SBOM)

  • Der CRA verpflichtet Hersteller, eine Software-Stückliste in einem gängigen maschinenlesbaren Format zu erstellen.
  • Aus dieser SBOM müssen zumindest die obersten Abhängigkeiten der Produkte hervorgehen, um Schwachstellen und Komponenten ermitteln zu können.
  • Die SBOM ist ein verpflichtender Bestandteil der Technischen Dokumentation für jedes Produkt mit digitalen Elementen.

Kontinuierliche Sicherheits- und Schwachstellentests

  • Hersteller müssen die Sicherheit eines Produkts mit digitalen Elementen regelmäßig und wirksam testen und überprüfen.
  • Diese Anforderung gilt nicht nur zum Release, sondern während der gesamten erwarteten Produktlebensdauer und dem Unterstützungszeitraum.
  • Es wird empfohlen, solche Tests (wie automatisiertes Codescanning) direkt in den Entwicklungsprozess zu integrieren.

3. Prozesse: Meldepflichten und Vulnerability Disclosure

Der CRA verschiebt die Verantwortung zur proaktiven Überwachung und Meldung massiv in Richtung der Hersteller. Hersteller müssen zwingend eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen.

Strenge Meldepflichten bei Vorfällen

Wenn eine Schwachstelle aktiv ausgenutzt wird oder ein schwerwiegender Sicherheitsvorfall auftritt, greifen extrem enge Meldefristen gegenüber der ENISA und dem national zuständigen CSIRT (in Deutschland voraussichtlich das BSI):

  • Innerhalb von 24 Stunden nach Kenntniserlangung muss eine Frühwarnung abgesetzt werden.
  • Innerhalb von 72 Stunden müssen allgemeine Informationen (z.B. zu Risikominderungsmaßnahmen) nachgeliefert werden.
  • Abschlussbericht: Bei Sicherheitsvorfällen innerhalb eines Monats; bei Schwachstellen innerhalb von 14 Tagen, nachdem ein Patch zur Verfügung steht.

Wichtig ist, dass man nur Schwachstellen melden muss, wo bekannt ist, dass sie im eigenen Produkt vorhanden sind und ausgenutzt werden. Sprich wenn z.B. eine Bibliothek wie Log4J genutzt wird, und dort eine Schwachstelle auftaucht, aber es keine konkreten Anhaltspunkte gibt, das es in dem eigenen Produkt ausgenutzt wurde, muss man das auch nicht melden (aber patchen sollte man es natürlich sofort).

4. Pragmatismus und Erleichterungen für KMU

Der CRA stellt gerade kleine und mittlere Unternehmen (KMU) vor große organisatorische Herausforderungen. Zwar sieht das Gesetz einige formale Erleichterungen vor (z.B. ein vereinfachtes Dokumentationsformat für Kleinst- und Kleinunternehmen oder den Verzicht auf Geldbußen, falls diese die 24-Stunden-Meldefrist verpassen), die grundlegenden Sicherheitsanforderungen bleiben jedoch für alle bestehen.

Das Whitepaper des ATHENE-Forschungszentrums schlägt vor, auf Automatisierung statt Papierkram zu setzen: Die Software-Stückliste (SBOM) muss nicht manuell gepflegt werden, sondern lässt sich als technisches Artefakt direkt in bestehende Build-Systeme integrieren und bei jedem Build vollautomatisiert generieren. Um der Pflicht nach Coordinated Vulnerability Disclosure (CVD) nachzukommen, ist nicht direkt eine teure externe Bug-Bounty-Plattform nötig. Bei einem kleinen Produktportfolio reicht oftmals bereits eine Funktions-E-Mail-Adresse mit PGP-Schlüssel auf der Webseite, die intern an ein Ticketsystem gekoppelt ist.

5. Compliance Einordnung für das Overtime-Projekt

Das Overtime-Projekt würde streng genommen nicht unter den CRA fallen, da es ein reines SaaS ist. Aber sobald man anfängt, Clients auszuliefern, die beim Kunden installiert werden (wie z.B. Slack Desktop, Teams oder Zoom es auch machen), würde man unter das Gesetz fallen. Aus technischer Sicht ist es ohnehin Best Practice, diese Maßnahmen proaktiv umzusetzen. Hier sind einige bereits getroffene Architekturentscheidungen, die auf das Gesetz einzahlen:

  • Erstellung einer maschinenlesbaren Software-Stückliste (SBOM): Trivy scannt in unserer CI/CD-Pipeline vollautomatisch bei jedem Build und generiert nativ eine SBOM im CycloneDX-Format.
  • Produkte ohne bekannte ausnutzbare Schwachstellen bereitstellen: Automatisierter CI-Pipeline-Abbruch (--exit-code 1) durch Trivy, sobald kritische CVEs im Container-Image oder Quellcode gefunden werden.
  • Regelmäßige und wirksame Sicherheitstests während des Lebenszyklus: Da wir auf GitOps und eine Secure Software Supply Chain setzen, durchläuft jeder Code-Commit automatisierte statische Analysen.
  • Reduzierung von Cybersicherheitsrisiken in der Entwicklungs- und Herstellungsphase: Nutzung von Buildah für rootless Container-Builds verhindert die Kompromittierung des Host-Systems während des CI-Prozesses. Renovate Bot aktualisiert benutzte Bibliotheken automatisch.