Der Security-by-Design-Ansatz wird mit dem Inkrafttreten des Cyber Resilience Act (CRA) ab 2027 von einer freiwilligen Best Practice zur verbindlichen Anforderung über den gesamten Produktlebenszyklus. Gleichzeitig halten sich in vielen Organisationen hartnäckig vereinfachte oder überholte Vorstellungen darüber, was Sicherheit in der Entwicklung eigentlich bedeutet, nicht zuletzt mit Blick auf Kosten, Innovation oder Verantwortlichkeiten.
Open Systems die gängigsten Mythen rund um das Konzept einem Faktencheck unterzogen und zeigt, warum sie zunehmend zu einem Risiko werden können.
Mythos 1: Security kann man später ergänzen
- Faktencheck: Nein, genau das ist das Problem
Die Vorstellung, Sicherheitsfunktionen erst nachträglich zu integrieren, ist weit verbreitet. In der Praxis entstehen sicherheitskritische Entscheidungen jedoch bereits im Design: etwa bei Datenflüssen, Schnittstellen oder Identitätsmodellen.
Werden die Aspekte ohne Security-Perspektive umgesetzt, entstehen strukturelle Schwachstellen, die sich später nur mit großem Aufwand oder gar nicht beheben lassen. Security nachträglich hinzuzufügen, führt daher meist zu doppelten Kosten oder dauerhaftem Risiko.
Mythos 2: Security ist eine reine IT-Aufgabe
- Faktencheck: Nein, echte Sicherheit wird ganzheitlich gedacht
Wer sagt, Sicherheit liege primär bei IT- oder Security-Teams, verschiebt damit Verantwortung an die falsche Stelle im Lebenszyklus. In der Praxis entstehen viele Risiken bereits bei grundlegenden Produktentscheidungen. Etwa, welche Daten überhaupt gesammelt werden, wie einfach sich ein Konto anlegen lässt oder welche Funktionen für Nutzer offen zugänglich sind.
Diese Entscheidungen wirken oft harmlos, bestimmen aber maßgeblich die Angriffsfläche eines Produkts. Die IT kann solche Vorgaben später nur noch absichern, aber nicht mehr grundlegend ändern. Security-by-Design bedeutet deshalb, Sicherheit von Anfang an mitzudenken – nicht erst, wenn das Produkt technisch umgesetzt ist.
Mythos 3: Security bremst Innovation
- Faktencheck: Kurzfristig ja, bewirkt aber langfristig oft das Gegenteil
Wahr ist, dass komplexe Sicherheitsanforderungen zunächst den Aufwand erhöhen und die Entwicklung verlangsamen können. Allerdings: Fehlt diese Grundlage, müssen Funktionen nachträglich überarbeitet werden, Systeme können instabil laufen und Teams sind mit Fehlerbehebung statt mit neuen Features beschäftigt.
Innovation findet dann nicht mehr im Produkt, sondern im Krisenmodus statt. Security-by-Design sorgt deshalb nicht für weniger Innovation, sondern dafür, dass sie dauerhaft tragfähig bleibt.
Mythos 4: Security ist ein Kostenfaktor
- Faktencheck: Nur kurzfristig, strategisch ist sie Risikomanagement
Security erscheint oft als zusätzlicher Budgetposten für Tools, Prozesse und Audits. Die eigentlichen Kosten entstehen jedoch erst durch fehlende Sicherheit: Kritische Events, Ausfälle, Datenverluste oder Reputationsschäden sind meist deutlich teurer und kaum kalkulierbar.
Security-by-Design verschiebt den Fokus von reaktiven Kosten zu proaktiver Absicherung von Geschäfts- und Markenwerten.
Mythos 5: Compliance bedeutet Sicherheit
- Faktencheck: Nein, Compliance ist ein Mindeststandard
Angreifer orientieren sich nicht an Checklisten, sondern an realen Schwachstellen. Sicherheit ist zudem kein statischer Zustand, sie verändert sich mit Nutzung, Systemänderungen und der sich entwickelnden Bedrohungslage.
Ein Security-by-Design-Ansatz, der mit dem Produkt-Launch endet, erzeugt daher auch eine Scheinsicherheit; wirklich wirksam ist nur ein kontinuierlicher Ansatz im Betrieb. Der CRA adressiert diese Notwendigkeit und fordert ein Lifecycle-Denken inklusive Entwicklung, Betrieb, Updates und Reaktion.
„Security-by-Design ist kein Dokumentationsprojekt, sondern eine dauerhafte Management-Aufgabe. Der Cyber Resilience Act macht endlich klar: Sicherheit entscheidet sich nicht in Audits, sondern im Zusammenspiel aus Architektur, Betrieb und Verantwortung über den gesamten Produktlebenszyklus hinweg“, bringt es Stefan Keller, Chief Product Officer bei Open Systems, auf den Punkt.