Secure SDLC für mittelständische Hersteller

Dieser Beitrag ist ein Entwurf und wird noch fachlich geprüft.

Ein Secure SDLC beginnt nicht mit möglichst vielen Freigabedokumenten. Er definiert passende Security-Anforderungen, Produktrisiken, klare Testkriterien, verantwortete Release-Gates und Prozesse für Meldung und Behebung von Schwachstellen.

Was ein Secure SDLC leisten muss

Ein sicherer Entwicklungsprozess beantwortet für jedes Release drei Fragen: Welche Sicherheitsanforderungen gelten? Wie wurde geprüft, dass sie erfüllt sind? Wer hat das freigegeben? Wenn diese Antworten aus dem normalen Entwicklungsalltag entstehen – aus Tickets, Reviews und Pipelines –, ist der Prozess tragfähig.

Die Bausteine

Anforderungen und Risiken

Security-Anforderungen werden wie fachliche Anforderungen behandelt: im Backlog, mit Akzeptanzkriterien. Ein leichtgewichtiges Threat Modeling bei Architekturänderungen zeigt, wo sie nötig sind.

Definition of Done mit Security-Checks

Code-Review, statische Analyse und Abhängigkeitsprüfung gehören in die Definition of Done – automatisiert, wo möglich, damit sie nicht vom Zeitdruck abhängen.

Release-Gates

Vor einem Release wird geprüft, dass keine bekannten kritischen Schwachstellen offen sind oder bewusst akzeptiert wurden. Die Entscheidung ist dokumentiert und einer Person zugeordnet.

Vulnerability Handling

Nach dem Release beginnt die eigentliche Arbeit: Meldungen annehmen, bewerten, beheben und Updates ausliefern.

Empfohlene erste Schritte

1. Den tatsächlichen Entwicklungsablauf aufnehmen – nicht den dokumentierten.
2. Vorhandene Kontrollen identifizieren und bewerten.
3. Wenige, wirksame Gates definieren und in einem Team erproben.
4. Nachweise dort ablegen, wo sie ohnehin entstehen.

Quellen

1. NIST SP 800-218: Secure Software Development Framework (SSDF)
2. OWASP Software Assurance Maturity Model (SAMM)