Das ist keine Mehrbelastung für gute Softwareentwicklung. Es ist die Beschreibung von guter Softwareentwicklung.

Viele Softwareunternehmen denken Cybersicherheit von hinten. Produkt ist fertig. Release steht an. Dann kommt der Penetrationstest. Schwachstellen werden gefunden. Einige werden behoben. Das Produkt geht raus. Sicherheit erledigt. Das ist kein Security by Design. Das ist Sicherheit als Abschlussritual. Der Unterschied ist fundamental. Wer Sicherheit ans Ende des Entwicklungsprozesses stellt behandelt sie wie eine Qualitätsprüfung bei der Auslieferung – nicht wie eine Eigenschaft die in das Produkt eingebaut wurde. Und wie bei jeder Qualitätsprüfung am Ende gilt: Was dort gefunden wird hat bereits die gesamte Entwicklung durchlaufen. Es steckt in der Architektur. Im Code. In den Abhängigkeiten. Und es herauszubekommen kostet ein Vielfaches dessen was es gekostet hätte es von Anfang an richtig zu machen. Security by Design bedeutet dass Sicherheit nicht geprüft wird nachdem das Produkt gebaut wurde. Sie wird eingebaut bevor die erste Zeile Code geschrieben wird. Was das konkret bedeutet: Sicherheitsanforderungen werden zu Beginn definiert – nicht nachträglich ergänzt. Die Architektur wird auf Angriffsvektoren analysiert bevor sie gebaut wird. Authentifizierung, Datenverschlüsselung und Zugriffsrechte sind keine Features die später hinzukommen – sie sind Teil des Grunddesigns. Code Reviews schließen Sicherheitsperspektiven ein. Und Abhängigkeiten werden systematisch auf bekannte Schwachstellen geprüft – nicht einmalig sondern kontinuierlich. Der Cyber Resilience Act macht genau das zur Pflicht. Wer Produkte mit digitalen Elementen auf dem EU-Markt verkauft muss nachweisen dass Sicherheit von Anfang an mitgedacht wurde. Ein Penetrationstest kurz vor Release reicht als Nachweis nicht aus. Er ist ein Werkzeug – aber kein Ersatz für eine Sicherheitsarchitektur die von Anfang an trägt. Das ist keine Mehrbelastung für gute Softwareentwicklung. Es ist die Beschreibung von guter Softwareentwicklung.