Sichere Entwicklung (8.25–8.34)
A.8 Technologische Maßnahmen
Sichere Software-Entwicklung
Der letzte Block (8.25–8.34) richtet sich an Organisationen, die Software entwickeln oder entwickeln lassen. Wer das nicht tut, schließt diese Maßnahmen oft in der SoA begründet aus. Für alle anderen gilt: Sicherheit muss in den gesamten Entwicklungslebenszyklus eingebaut sein („Security by Design").
Grundsätze & Lebenszyklus (8.25–8.28)
- 8.25 Lebenszyklus einer sicheren Entwicklung – Regeln für sichere Entwicklung über den gesamten SDLC festlegen.
- 8.26 Anforderungen an die Anwendungssicherheit – Sicherheitsanforderungen werden früh ermittelt, spezifiziert und genehmigt.
- 8.27 Sichere Systemarchitektur & Entwicklungsgrundsätze – Prinzipien wie Defense in Depth, Least Privilege, Fail-Secure von Anfang an.
- 8.28 Sichere Codierung (neu) – Coding-Standards gegen typische Schwachstellen (Input-Validierung, Output-Encoding, sichere Bibliotheken). Verwandt: SQL-Injection und Prepared Statements.
Prüfen & Trennen (8.29–8.31)
- 8.29 Sicherheitsprüfung bei Entwicklung & Abnahme – Tests (SAST, DAST, Pentests) sind fester Teil des Prozesses.
- 8.30 Ausgegliederte Entwicklung – auch externe Entwicklung wird geleitet, überwacht und überprüft (siehe Lieferanten).
- 8.31 Trennung von Entwicklungs-, Test- und Produktionsumgebungen – getrennte Umgebungen verhindern, dass Tests die Produktion gefährden.
DEV ──► TEST/STAGING ──► PROD
(spielen) (prüfen) (echte Daten – streng geschützt)
getrennt & gesichert
Änderungen, Testdaten & Audits (8.32–8.34)
- 8.32 Änderungssteuerung (Change Management) – Änderungen an Systemen folgen einem geregelten Verfahren (Antrag, Test, Freigabe, Rückfallplan). Verhindert, dass „mal eben" eine Lücke entsteht.
- 8.33 Testdaten – Testdaten sorgfältig auswählen und schützen; echte Produktivdaten möglichst maskieren (8.11).
- 8.34 Schutz der Systeme während Audit-Tests – Tests an Produktivsystemen werden vorab zwischen Prüfer und Management geplant und vereinbart, um Störungen zu vermeiden.
DevSecOps als roter Faden
Modern fasst man diese Maßnahmen unter DevSecOps zusammen: Sicherheit wird automatisiert und kontinuierlich in die Entwicklungs-Pipeline integriert, statt am Ende „draufgeprüft" zu werden. So wird sichere Entwicklung zur Gewohnheit, nicht zur Ausnahme.
Warum werden Entwicklungs-, Test- und Produktionsumgebungen getrennt (8.31)?