Die neue Webanwendung geht live. Drei Tage später meldet ein Sicherheitsforscher eine SQL-Injection-Schwachstelle. Die Ursache: Sicherheitsanforderungen wurden nie definiert, Code Reviews fanden nicht statt, und Tests beschränkten sich auf Funktionalität. A.8.25 fordert, dass Informationssicherheit von der ersten Entwurfsphase an in den Entwicklungslebenszyklus integriert wird — durch definierte Regeln, getrennte Umgebungen, sichere Programmierpraktiken und regelmäßige Sicherheitsüberprüfungen.
Security by Design ist das Prinzip hinter dieser Kontrolle: Sicherheit wird eingebaut, nicht nachgerüstet.
Was verlangt die Norm?
- Umgebungstrennung. Entwicklung, Test und Produktion sind voneinander getrennt (Details in A.8.31).
- Sichere Codierungspraktiken. Definierte Standards für sicheres Programmieren, die alle Entwickler befolgen.
- Sicherheitsanforderungen ab der Entwurfsphase. Security Requirements werden zusammen mit den funktionalen Anforderungen spezifiziert.
- Regelmäßige Sicherheitsüberprüfungen. Code Reviews, statische Analyse, dynamische Tests und Penetrationstests.
- Sichere Code-Verwaltung. Quellcode in Versionskontrollsystemen mit Zugriffsschutz und Nachvollziehbarkeit (A.8.4).
In der Praxis
Security Gates definieren. An definierten Punkten im Entwicklungsprozess werden Sicherheitsaspekte geprüft: Threat Modeling vor der Implementierung, Code Review vor dem Merge, SAST/DAST vor dem Release, Pentest vor dem Go-Live. Jedes Gate hat definierte Kriterien.
OWASP als Referenz nutzen. Die OWASP Top 10 (Web), OWASP Mobile Top 10, OWASP API Security Top 10 und der OWASP ASVS (Application Security Verification Standard) liefern konkrete Checklisten für Sicherheitsanforderungen und Tests.
CI/CD-Pipeline mit Sicherheitstests. Automatisierte Sicherheitsscans (SAST, DAST, SCA) in die CI/CD-Pipeline integrieren. Sicherheitsprobleme werden wie funktionale Fehler behandelt: Der Build schlägt fehl, bis das Problem behoben ist.
Entwickler schulen. Regelmäßige Trainings zu sicherer Entwicklung: OWASP Top 10, Input-Validierung, Output-Encoding, sichere Session-Verwaltung, Secrets Management. Praxisnahe Formate (CTF, Code-Katas) sind wirksamer als Frontalvorträge.
Typische Audit-Nachweise
Auditoren erwarten bei A.8.25 typischerweise diese Nachweise:
- Secure-SDLC-Richtlinie — dokumentierter Entwicklungsprozess mit Security Gates (→ Richtlinie sichere Softwareentwicklung im Starter Kit)
- Threat Models — dokumentierte Bedrohungsanalysen für kritische Anwendungen
- SAST/DAST-Berichte — Ergebnisse automatisierter Sicherheitsscans
- Code-Review-Statistik — Nachweis, dass Reviews durchgeführt werden
- Schulungsnachweise — Teilnahme an Secure-Coding-Trainings
KPI
Anteil der Entwicklungsprojekte, die den sicheren Entwicklungslebenszyklus einhalten
Gemessen als Prozentsatz: Wie viele deiner aktiven Entwicklungsprojekte durchlaufen die definierten Security Gates? Ziel: 100%.
Ergänzende KPIs:
- Anteil der Releases mit erfolgreich durchlaufener Security-Pipeline
- Anzahl der in der Produktion entdeckten Sicherheitslücken (Ziel: abnehmend)
- Anteil der Entwickler mit aktuellem Secure-Coding-Training
BSI IT-Grundschutz
- CON.8 (Software-Entwicklung) — der Kernbaustein. Verlangt sichere Entwicklungsrichtlinien, Umgebungstrennung, Code Reviews, Versionskontrolle und Sicherheitstests.
- APP.7 (Webanwendungen und Webservices) — spezifische Sicherheitsanforderungen für webbasierte Anwendungen.
- CON.10 (Entwicklung von Webanwendungen) — konkrete Anforderungen an die sichere Entwicklung von Webanwendungen.
Verwandte Kontrollen
- A.8.26 — Anwendungssicherheitsanforderungen: Die Sicherheitsanforderungen, die im SDLC umgesetzt werden.
- A.8.28 — Sicheres Programmieren: Die konkreten Codierungspraktiken innerhalb des SDLC.
- A.8.29 — Sicherheitstests in Entwicklung und Abnahme: Tests als Bestandteil der Security Gates.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.25 — Sicherer Entwicklungslebenszyklus
- ISO/IEC 27002:2022 Abschnitt 8.25 — Umsetzungshinweise zum sicheren SDLC
- BSI IT-Grundschutz, CON.8 — Software-Entwicklung