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. Reine SaaS-Lösungen 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.

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.

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.

4. 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, 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.