Der Security-by-Design-Ansatz wird mit dem Inkrafttreten des Cyber Resilience Act 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 stellt fünf zentrale Mythen auf den Prüfstand und konfrontiert sie mit der Realität.
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 diese 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 einem dauerhaften 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.
