Funktionale Tests bestanden, Performance-Tests bestanden, Abnahme erteilt — und eine Woche nach Go-Live findet ein Bug-Bounty-Hunter eine Remote Code Execution. Sicherheitstests waren kein Teil des Abnahmeprozesses. A.8.29 verlangt, dass Sicherheitstests ein verbindlicher Bestandteil des Entwicklungs- und Abnahmeprozesses sind — für jedes neue System, jedes Upgrade und jede neue Version.
Die Kontrolle stellt sicher, dass Sicherheitsanforderungen vor der Produktivstellung validiert werden.
Was verlangt die Norm?
- Sicherheitstests in den Entwicklungsprozess integrieren. Tests decken Sicherheitsfunktionen, sichere Codierung und Konfiguration ab.
- Testplan erstellen. Basierend auf der Kritikalität des Systems: Umfang, Methoden, Zeitplan, erwartete Ergebnisse, Bewertungskriterien.
- Automatisierte und manuelle Methoden kombinieren. Code-Reviews, Schwachstellenscans, Penetrationstests, SAST, DAST.
- Ausgelagerte Komponenten einbeziehen. Sicherheitsanforderungen für zugekaufte oder ausgelagerte Komponenten vertraglich festlegen.
- Realistische Testumgebung. Tests in einer Umgebung durchführen, die der Produktion ähnelt.
In der Praxis
Security-Testplan pro Anwendung. Für jede Anwendung definieren: Welche Tests? Welche Frequenz? Welche Kriterien für Bestehen/Nichtbestehen? Wer führt durch? Wer bewertet? Der Testplan ist der Referenzrahmen für alle Sicherheitstests.
SAST/DAST in der CI/CD-Pipeline. Automatisierte Scans bei jedem Build. Kritische Findings blockieren das Deployment. Mittlere Findings erzeugen Tickets mit definierter Behebungsfrist. Niedrige Findings werden im nächsten Sprint adressiert.
Penetrationstests für kritische Anwendungen. Externe Pentester testen die Anwendung aus Angreifersicht. Der Pentest-Bericht dokumentiert Findings, Schweregrad und Empfehlungen. Alle kritischen und hohen Findings werden vor dem Go-Live behoben.
Abnahmekriterien mit Sicherheitskomponente. Keine Produktivfreigabe ohne bestandene Sicherheitstests. Die Abnahmekriterien definieren: Keine offenen kritischen oder hohen Sicherheits-Findings, SAST-Scan durchgeführt, Dependency-Check bestanden.
Typische Audit-Nachweise
- Security-Testpläne — dokumentierte Teststrategien pro Anwendung (→ Richtlinie sichere Softwareentwicklung im Starter Kit)
- SAST/DAST-Berichte — Scan-Ergebnisse mit Behebungsstatus
- Pentest-Berichte — Ergebnisse mit Maßnahmenplan (→ Pentest-Bericht im Starter Kit)
- Abnahmeprotokolle — Freigabe mit Sicherheitskomponente
- Behebungsnachweise — Nachweis, dass kritische Findings vor Go-Live behoben wurden
KPI
Anteil der Releases mit abgeschlossenen Sicherheitstests vor Produktivstellung
Gemessen als Prozentsatz: Wie viele deiner Releases haben die definierten Sicherheitstests vor dem Deployment bestanden? Ziel: 100%.
Ergänzende KPIs:
- Anteil der kritischen Findings, die vor Go-Live behoben wurden (Ziel: 100%)
- Mittlere Behebungszeit für Pentest-Findings
- Anzahl der nach Go-Live entdeckten Sicherheitslücken (Ziel: abnehmend)
BSI IT-Grundschutz
- OPS.1.1.6 (Software-Tests und -Freigaben) — der Kernbaustein. Verlangt dokumentierte Testverfahren, Sicherheitstests vor Produktivnahme, Freigabeprozess mit Sicherheitskomponente.
Verwandte Kontrollen
- A.8.28 — Sicheres Programmieren: Codierungsstandards, deren Einhaltung durch Tests verifiziert wird.
- A.8.25 — Sicherer Entwicklungslebenszyklus: Sicherheitstests als Bestandteil der Security Gates im SDLC.
- A.8.8 — Verwaltung technischer Schwachstellen: Schwachstellen, die in Tests gefunden werden, fließen ins Schwachstellenmanagement.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.29 — Sicherheitstests in Entwicklung und Abnahme
- ISO/IEC 27002:2022 Abschnitt 8.29 — Umsetzungshinweise
- BSI IT-Grundschutz, OPS.1.1.6 — Software-Tests und -Freigaben