Wie sieht ein sicherer SDLC aus, und welche Sicherheitsaktivitäten finden in jeder Phase statt?
Kurzantwort
Ein sicherer SDLC verankert Sicherheit in jeder Phase, statt sie am Ende anzuflanschen. Anforderungen umfassen Sicherheits- und Missbrauchsfälle, Design ergänzt Threat Modeling, Entwicklung nutzt sicheres Coding und SAST plus Dependency Scanning, Tests ergänzen DAST und Penetrationstests, und Betrieb ergänzt Monitoring, Patching und Incident Response – Sicherheit nach links verlagert.
Ein sicherer Software Development Life Cycle integriert Sicherheit als kontinuierliche Aktivität über den gesamten Entwicklungsprozess statt als Tor am Ende. Die Kernidee ist Shift Left: Je früher ein Mangel gefunden wird, desto günstiger und einfacher ist er zu beheben – ein am Whiteboard erkannter Designfehler kostet fast nichts; derselbe Fehler in der Produktion nach einem Einbruch ist enorm teuer.
Sicherheit in jeder Phase
- Anforderungen: Erfasse Sicherheits- und Compliance-Anforderungen neben den funktionalen und schreibe Missbrauchsfälle – wie könnte jemand diese Funktion missbrauchen? – nicht nur User Stories.
- Design: Führe Threat Modeling (z. B. STRIDE) durch, um zu erkennen, wie das System angegriffen werden könnte, und plane Kontrollen von vornherein ein. Architekturentscheidungen wie Vertrauensgrenzen und Authentifizierungsflüsse sind hier am günstigsten richtig zu treffen.
- Entwicklung: Befolge sichere Coding-Standards, führe SAST (statische Analyse) in der IDE und CI aus und nutze SCA / Dependency Scanning, um verwundbare Drittanbieter-Bibliotheken zu erkennen – die meisten modernen Apps bestehen größtenteils aus fremdem Code.
- Test / QA: Ergänze DAST (dynamisches Testen gegen die laufende App), Fuzzing und gezielte Penetrationstests vor dem Release.
- Deployment: Scanne Infrastructure-as-Code und Container-Images, verwalte Secrets ordentlich und härte die Laufzeitkonfiguration.
- Betrieb / Wartung: kontinuierliches Monitoring und Logging, zeitnahes Patching und ein getesteter Incident-Response-Plan, um Durchgerutschtes zu bewältigen. Erkenntnisse fließen in die Anforderungen zurück.
Damit es funktioniert
Automatisiere die Prüfungen in der CI/CD-Pipeline, damit Sicherheit schnelles Feedback ist und kein manueller Flaschenhals. Verwende risikobasierte Gates – den Build bei kritischen Befunden fehlschlagen lassen, bei geringeren warnen –, damit Sicherheit die Auslieferung ermöglicht, statt sie zu blockieren.
Worauf Interviewer achten
Eine Antwort auf Senior-Niveau ordnet konkrete Aktivitäten konkreten Phasen zu (Threat Modeling im Design, SAST/SCA in der Entwicklung, DAST/Penetrationstests in der QA, Monitoring im Betrieb), erklärt, warum Shift Left Geld spart, und zeigt Bewusstsein dafür, all dies in die Pipeline zu integrieren, ohne die Auslieferung zum Stillstand zu bringen.
Wahrscheinliche Anschlussfragen
- Warum ist das Beheben einer Schwachstelle umso günstiger, je früher sie entdeckt wird?
- Was ist der Unterschied zwischen SAST, DAST und SCA?
- Wie integrierst du Security-Gates, ohne die Pipeline zu blockieren?