Security by Design: Wie sichere Software schon in der Planung entsteht

In vielen Projekten kommt Sicherheit als letzter Punkt vor dem Launch: ein Scan, eine Liste, schnelle Patches. Das Problem ist nicht der Test — das Problem ist der Zeitpunkt. Zu diesem Zeitpunkt sind die Architekturentscheidungen, die die Lücken verursacht haben, längst eingefroren.

Security by Design heißt nicht „mehr testen". Es heißt: die wenigen billigen Entscheidungen früh treffen, die die teuren Risiken strukturell unwahrscheinlich machen.

Warum der späte Test eine Entdeckung ist, keine Verteidigung

Ein Penetrationstest kurz vor dem Launch findet, was bereits gebaut wurde. Er kann nicht mehr ändern, wie es gebaut wurde. Eine fehlerhafte Zugriffskontrolle, die im Datenmodell verankert ist, lässt sich nicht „wegpatchen" — sie ist eine Architektur, kein Bug. Der späte Test ist Verifikation, nicht Strategie.

Vier billige Entscheidungen, die früh viel sparen

1. Vertrauensgrenzen bewusst ziehen

Wo endet das Vertrauenswürdige, wo beginnt fremde Eingabe? Diese Grenzen früh zu benennen verhindert genau die Injection- und Zugriffsfehler, die später teuer sind (siehe OWASP Top 10 einfach erklärt).

2. Minimale Rechte als Standard

Jede Komponente, jeder Dienst, jeder Token bekommt so wenig Rechte wie möglich. Das ist keine spätere Härtung, sondern eine Designhaltung, die den Schaden im Fehlerfall klein hält.

3. Geheimnisse und Konfiguration trennen

Schlüssel, Passwörter, Tokens gehören nie in den Code und nie ins Repository. Diese eine frühe Regel verhindert eine der häufigsten realen Einbruchsursachen.

4. Sichtbarkeit von Anfang an

Logging und Monitoring nachträglich einzubauen heißt, blind gewesen zu sein, als es zählte. Der BSI-Lagebericht ordnet fehlende Sichtbarkeit regelmäßig als verschärfenden Faktor ein.

Security ist auch Liefergeschwindigkeit

Der Accelerate State of DevOps Report 2024 von DORA zeigt: stabile, schnelle Lieferung und Sicherheit sind keine Gegensätze. Saubere Grenzen, kleine Änderungen, automatisierte Prüfungen machen ein System gleichzeitig sicherer und schneller änderbar. Unsicherheit ist meist dieselbe Wurzel wie Trägheit: nachträglich aufgesetzte Struktur.

Der Review-Loop schlägt den Endtest

Wenige, regelmäßige Sicherheitsfragen während der Entwicklung — „was ist hier fremde Eingabe, welche Rechte braucht das wirklich, was wird protokolliert" — fangen mehr ab als ein großer Test am Ende. Verifikation am Schluss bleibt sinnvoll, aber als Bestätigung, nicht als Rettung (siehe Penetrationstest für Web-Anwendungen).

Checkliste für Security by Design

• Sind Vertrauensgrenzen früh benannt, nicht implizit?
• Gilt minimale Rechte als Standard, nicht als spätere Härtung?
• Sind Geheimnisse strikt von Code und Repo getrennt?
• Ist Logging/Monitoring von Anfang an vorgesehen?
• Gibt es einen Security-Review-Loop, nicht nur einen Endtest?
• Werden kleine, prüfbare Änderungen ausgeliefert?
• Ist der Penetrationstest Bestätigung, nicht die einzige Verteidigung?

Häufige Fragen

Ersetzt Security by Design den Penetrationstest? Nein. Es macht den Test billiger und sein Ergebnis besser. Beides gehört zusammen: Design verhindert, Test bestätigt.

Verlangsamt frühe Sicherheit das Projekt? Kurzfristig minimal, langfristig nicht — nachträgliche Security-Umbauten sind die eigentliche Bremse.

Brauchen wir dafür Security-Spezialisten im Team? Nicht zwingend. Die wirksamsten Entscheidungen — Grenzen, minimale Rechte, Geheimnistrennung — sind Disziplin, kein Spezialwissen.

Was ist der häufigste Fehler? Sicherheit als Endphase planen. Dann ist sie eine Entdeckung von Problemen, deren Ursache nicht mehr billig zu ändern ist.

Fazit

Sichere Software entsteht nicht im Test vor dem Launch, sondern in wenigen frühen Entscheidungen: klare Vertrauensgrenzen, minimale Rechte, getrennte Geheimnisse, Sichtbarkeit von Anfang an. Der Penetrationstest bestätigt das dann — er ersetzt es nicht.

Weiterlesen

• OWASP Top 10 einfach erklärt: die wichtigsten Risiken — was Security by Design strukturell verhindert.
• Penetrationstest für Web-Anwendungen: Ablauf und Nutzen — die Bestätigung am Ende.

Nächster Schritt

Sie wollen Sicherheit früh verankern statt spät entdecken? Beginnen Sie mit einer kurzen Einschätzung Ihrer Anforderungen. Wir benennen Vertrauensgrenzen und Rechte am Anfang — und planen den Test als Bestätigung.

Quellen

• OWASP, Top Ten Web Application Security Risks — owasp.org
• BSI, Die Lage der IT-Sicherheit in Deutschland — bsi.bund.de
• DORA, Accelerate State of DevOps Report 2024 — dora.dev