Security-by-Design im Faktencheck

Gastbeitrag von Stefan Keller*

Der Security-by-Design-Ansatz wird mit dem Inkrafttreten des CRA 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 hat fünf zentrale Mythen auf den Prüfstand gestellt:

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.

*Stefan Keller ist Chief Product Officer bei Open Systems, einem international tätigen Anbieter von co-managed SASE- und Zero-Trust-Betriebsmodellen