Cyber Resilience Act (CRA) & Application Security

Der Cyber Resilience Act (CRA) verpflichtet Hersteller von Software- und Hardwareprodukten dazu, Sicherheit über den gesamten Produktlebenszyklus hinweg sicherzustellen.

Ich ordne den CRA aus Sicht der Application Security ein und zeigte, was «Security-by-Design» konkret bedeutet.

Warum der CRA für Softwareentwicklung besonders relevant ist

Der CRA ist die erste EU-Regulierung, die:

  • Softwareprodukte explizit adressiert
  • Security-by-Design und Security-by-Default verlangt
  • Sicherheitsanforderungen über den gesamten Lebenszyklus fordert
  • Sicherheitslücken und Updates regulatorisch verankert

Damit wird Application Security kein Qualitätsmerkmal mehr, sondern eine gesetzliche Anforderung.

Bin ich vom Cyber Resilience Act betroffen?

Direkt betroffen sind:

  • Hersteller von Softwareprodukten
  • Anbieter von SaaS-, On-Premise- oder Embedded-Software
  • Unternehmen, die Software in der EU in Verkehr bringen

Indirekt betroffen sind:

  • Zulieferer von Softwarekomponenten
  • Entwicklungsdienstleister
  • Open-Source-Nutzer in kommerziellen Produkten
  • Schweizer Anbieter mit EU-Kunden

In der Praxis bedeutet das: Wer Softwareprodukte verkauft oder bereitstellt, sollte sich mit dem CRA befassen. Unabhängig vom Unternehmenssitz.

Was fordert der CRA konkret?

Der CRA fordert unter anderem:

  • Berücksichtigung von Sicherheit bereits im Design
  • Minimierung bekannter Schwachstellen
  • sichere Standardkonfigurationen
  • strukturierte Schwachstellenbehandlung
  • transparente Sicherheitsinformationen
  • regelmässige Sicherheitsupdates

Diese Anforderungen lassen sich nicht nachträglich «aufkleben», sondern müssen Teil des Entwicklungsprozesses sein.

Security-by-Design & Security-by-Default

Der CRA macht zwei Prinzipien verbindlich. Beides ist klassische Application Security, aber jetzt mit regulatorischem Rahmen:

Security-by-Design

  • Sicherheitsanforderungen fliessen früh in Architekturentscheidungen ein
  • Risiken werden systematisch identifiziert
  • Bedrohungen werden bewusst adressiert

Security-by-Default

  • Produkte sind in der sicheren Konfiguration ausgeliefert
  • Unsichere Optionen sind nicht standardmässig aktiviert
  • Sicherheitsentscheidungen werden nicht auf Nutzer abgewälzt

Schwachstellenmanagement & Produktlebenszyklus

Ein zentrales Element des CRA ist der Umgang mit Schwachstellen:

  • Identifikation von Sicherheitslücken
  • Bewertung von Risiken
  • zeitnahe Behebung
  • transparente Kommunikation

Für Softwareentwicklung bedeutet das:

  • strukturierte Prozesse statt ad-hoc-Fixes
  • klare Verantwortlichkeiten
  • dokumentierte Entscheidungen
  • Integration in den Entwicklungs- und Release-Prozess

CRA und Open Source

Open Source spielt im CRA eine besondere Rolle.

Wichtig ist die Differenzierung:

  • Open Source allein ist kein Problem
  • Nutzung in kommerziellen Produkten erzeugt Verantwortung

Hersteller müssen:

  • Abhängigkeiten kennen
  • Risiken bewerten
  • Updates und Patches steuern
  • Sicherheitsinformationen bereitstellen

Supply-Chain Security wird damit auch im CRA-Kontext zentral.

Mein Lösungsansatz: CRA-Anforderungen praktikabel umsetzen

Ich unterstütze Softwarehersteller dabei, CRA-Anforderungen praxisnah umzusetzen.

Einordnung & Gap-Analyse

  • Welche CRA-relevanten Anforderungen gelten?
  • Wo steht Ihr Entwicklungsprozess heute?
  • Welche Risiken bestehen realistisch?

Strukturierte Massnahmen

  • Ableitung konkreter Sicherheitsmassnahmen
  • Fokus auf Security-by-Design
  • klare Priorisierung statt Überregulierung

Verankerung im Team

  • Integration in bestehende Entwicklungsprozesse
  • Enablement der Entwickler
  • nachhaltige Umsetzung statt Einmalprojekt

Weiterführende Schritte

Je nach Ausgangslage sind folgende Einstiege sinnvoll:

Diese Leistungen lassen sich einzeln nutzen oder sinnvoll kombinieren.

Erstgespräch buchen

FAQ

Ja.
Auch SaaS-Anbieter gelten als Hersteller, wenn sie Softwareprodukte bereitstellen oder betreiben, die in der EU genutzt werden.

Open Source an sich ist nicht verboten.
Wer Open Source in kommerziellen Produkten nutzt, trägt jedoch Verantwortung für Sicherheit und Schwachstellenmanagement.

Nein.
Secure Coding ist wichtig, ersetzt aber kein systematisches Security-by-Design über Architektur, Prozesse und Produktlebenszyklus hinweg.

  • CRA: Sicherheit von Softwareprodukten
  • NIS2: Cybersicherheit von Organisationen
  • DORA: Digitale Resilienz im Finanzsektor

Gemeinsam fordern sie eine strukturelle Verankerung von Application Security.