Wie sieht ein sicherer SDLC aus?
Kurzantwort
Ein sicherer SDLC bettet Sicherheit in jede Phase ein, statt am Ende zu testen: Anforderungen (Sicherheits- und Missbrauchsfälle), Design (Threat Modeling), Implementierung (sichere Coding-Standards, SAST/SCA in der IDE und CI), Test (DAST, Pentest), Release (Gates und Freigabe) und Betrieb (Monitoring, Patching, Feedback). Shift-Left verlagert Defekte nach vorne, wo sie billig zu beheben sind; Reifegradmodelle wie OWASP SAMM und BSIMM messen, wie gut man es tatsächlich tut.
Ein sicherer SDLC bedeutet, dass Sicherheit eine Eigenschaft davon ist, wie Sie Software bauen, kein Scan, den Sie in der Woche vor dem Launch ausführen. Interviewer fragen danach, um abzuschätzen, ob Sie „Shift-Left" operationalisieren können — die Entdeckung von Defekten nach vorne zu verlagern, wo eine Behebung einen Code-Kommentar statt eines Vorfalls kostet.
Sicherheit in jeder Phase
- Anforderungen. Sicherheitsanforderungen und Missbrauchsfälle neben den Features erfassen — „was dies niemals erlauben sollte" ist genauso wichtig wie „was es tun sollte".
- Design. Die Architektur per Threat Modeling untersuchen und sichere Muster wählen, bevor Code existiert. Der billigste Bug ist der, der nie gebaut wird.
- Implementierung. Sichere Coding-Standards plus automatisiertes SAST und SCA (Software Composition Analysis/Abhängigkeiten), die in der IDE und bei jedem Pull Request laufen, damit das Feedback unmittelbar ist.
- Test. DAST, Fuzzing und gezielte manuelle Penetrationstests gegen laufende Builds.
- Release. Sicherheits-Gates und Freigabe — aber risikoangepasst, sodass ein informativer Befund niedriger Schwere kein Deployment blockiert, während ein kritischer es tut.
- Betrieb. Laufzeit-Monitoring, Patching, Geheimnis- und Konfigurationshygiene und das Zurückspeisen von Vorfällen in Anforderungen und Bedrohungsmodelle.
Warum Shift-Left funktioniert
Die Kosten der Behebung eines Defekts steigen stark an, je später er gefunden wird. Einen Injection-Fehler in einem Pull-Request-SAST-Check abzufangen kostet Minuten; ihn als Datenpanne abzufangen kostet Offenlegung, Ausfallzeit und Vertrauen. Shift-Left verlagert den Entdeckungspunkt schlicht dorthin, wo die Behebung billig ist.
Reife messen
Man steuert, was man misst. OWASP SAMM ist ein präskriptives, selbst bewertbares Reifegradmodell über Governance, Design, Implementierung, Verifikation und Betrieb hinweg. BSIMM ist deskriptiv — es berichtet, was reale Unternehmen tatsächlich tun, sodass Sie sich mit Ihresgleichen vergleichen können.
Worauf Interviewer achten
Sie wollen konkrete Berührungspunkte pro Phase, das richtige Tool am richtigen Ort (SAST früh, DAST bei laufenden Apps, SCA für Abhängigkeiten), risikoangepasste Gates statt pauschaler Blocker und das Bewusstsein, dass ein Reifegradmodell „uns ist Sicherheit wichtig" in etwas Messbares verwandelt.
Wahrscheinliche Anschlussfragen
- Was ist der Unterschied zwischen SAST, DAST und SCA, und wo passt jedes hin?
- Wie unterscheiden sich OWASP SAMM und BSIMM in ihrem Zweck?
- Wie fügen Sie der CI ein Sicherheits-Gate hinzu, ohne jedes Deployment zu blockieren?