Compliance-Lexikon · CRA
Secure Development Lifecycle – Praxis
Secure Development Lifecycle wird von Auditoren nicht danach bewertet, ob das Thema bekannt ist, sondern ob eine belastbare, datierte Umsetzung nachweisbar ist. Dieser Artikel zeigt, was konkret vorzubereiten ist.
Was Auditoren konkret prüfen
Der Auditor erwartet keinen theoretischen Idealzustand, sondern einen nachvollziehbaren Prozess mit Verantwortlichkeiten, Fristen und Nachweisen. Existiert ein dokumentierter Secure Development Lifecycle mit definierten Sicherheitsprüfpunkten in jeder Entwicklungsphase?
Häufige Fehler in der Praxis
- Sicherheitsprüfungen finden nur am Ende des Entwicklungsprozesses statt, nicht kontinuierlich
- Threat Modeling wird nicht systematisch für neue Features durchgeführt
- Ergebnisse von Sicherheitstests fließen nicht in nachfolgende Entwicklungszyklen zurück
Praxis-Tipp
Ein SDLC ist kein einmaliges Rahmenwerk, sondern ein sich wiederholender Zyklus. Erkenntnisse aus Sicherheitsvorfällen oder Tests sollten systematisch in zukünftige Entwicklungsphasen zurückfließen.
Sicherheitsprüfpunkte im Entwicklungszyklus
Ein wirksamer Secure Development Lifecycle definiert Prüfpunkte in jeder Phase: Threat Modeling in der Konzeption, sichere Coding-Standards und Code-Reviews in der Implementierung, automatisierte Sicherheitstests (SAST/DAST) vor Release und ein definierter Prozess für den Umgang mit gemeldeten Schwachstellen nach Release.
Evidence-Anforderungen im Audit
Vorzulegen sind in der Regel: Dokumentierter SDLC-Prozess mit Prüfpunkten je Phase, Nachweis durchgeführter Threat-Modeling-Sessions und Sicherheitstests. Eine strukturierte Ablage dieser Nachweise erspart im Audit-Fall zeitraubende Nachrecherchen.
Nächster Schritt
Compliance-Stresstest starten
Kostenloser Stresstest auf Basis der BAM-Objekte – unverbindlich, 20 Minuten.
Die strategische Einordnung – warum Secure Development Lifecycle über die technische Umsetzung hinaus Bedeutung hat – findet sich auf Ebene 3.