Wie würden Sie Sicherheits-Governance in den SDLC einbetten, statt sie am Ende anzuflanschen?
Kurzantwort
Betten Sie Sicherheit in jede SDLC-Phase ein, statt am Ende zu testen: Anforderungen umfassen Sicherheits- und Datenschutzanforderungen, das Design umfasst Bedrohungsmodellierung, die Entwicklung folgt sicheren Codierstandards mit SAST, das Testen ergänzt DAST und Reviews, und das Release erfordert eine Freigabe — alles gesteuert durch Richtlinie, Funktionstrennung und Änderungskontrolle. Fehler früh zu beheben ist drastisch günstiger als nach dem Release.
Diese Frage liegt an der Schnittstelle der Domänen Softwareentwicklungssicherheit und Governance. Interviewer wollen sehen, dass Sie Sicherheit als gesteuerte Lebenszyklusaktivität behandeln, nicht als einmaliges Gate, und dass Sie sie in geschäftlichen und prozessualen Begriffen rahmen können.
Sicherheit in jeder Phase
Governance bedeutet eine definierte Sicherheitsaktivität und ein Gate in jeder SDLC-Phase:
- Anforderungen — explizite Sicherheits- und Datenschutzanforderungen neben den funktionalen erfassen (Authentifizierung, Datenverarbeitung, regulatorische Bedürfnisse).
- Design — Bedrohungsmodellierung durchführen (z. B. STRIDE), um architektonische Schwachstellen zu finden, bevor Code existiert, wenn sie am günstigsten zu beheben sind.
- Entwicklung — sichere Codierstandards durchsetzen und SAST in der Pipeline ausführen.
- Testen — DAST, Abhängigkeitsscans und sicherheitsorientiertes Code-Review ergänzen.
- Bereitstellung — eine Sicherheits-Freigabe verlangen und eine gehärtete Konfiguration verifizieren.
- Betrieb / Wartung — patchen, überwachen und Erkenntnisse in die Anforderungen zurückspeisen.
Warum sich Shift Left auszahlt
Das wirtschaftliche Argument ist zentral: Die Kosten zur Behebung eines Fehlers steigen stark, je später er gefunden wird. Ein Designfehler, der in der Bedrohungsmodellierung entdeckt wird, kostet ein Gespräch; derselbe Fehler in Produktion kann einen Vorfall, Notfall-Patching und Reputationsschaden bedeuten. „Shift Left" ist Governance, die Kosten und Risiko gemeinsam optimiert.
Governance-Kontrollen rund um den SDLC
Prozessdisziplin zählt ebenso viel wie Tooling: Funktionstrennung, damit die Person, die Code schreibt, ihn nicht eigenmächtig in Produktion bringt, Änderungsmanagement, damit Releases geprüft und umkehrbar sind, und Konfigurationsmanagement, damit Umgebungen bekannt und konsistent sind. Diese Kontrollen verhindern sowohl ehrliche Fehler als auch böswilliges Einschleusen.
Worauf Interviewer achten
Eine phasenweise Zuordnung der Sicherheitsaktivitäten mit der Bedrohungsmodellierung im Design, das Shift-Left-Kostenargument und die Governance-Hüllen — Funktionstrennung, Änderungs- und Konfigurationsmanagement — die sichere Entwicklung wiederholbar machen, statt sie von individuellen Heldentaten abhängig zu machen.
Wahrscheinliche Anschlussfragen
- Was ist Bedrohungsmodellierung und in welche Phase gehört sie?
- Warum ist Funktionstrennung zwischen Entwicklern und Produktionsbereitstellung wichtig?
- Wie unterstützen Änderungsmanagement und Konfigurationsmanagement sichere Releases?