Eingabevalidierung? „Das macht das Framework.” SQL-Injection? „Wir verwenden doch ein ORM.” Cross-Site Scripting? „Ist das überhaupt noch relevant?” — Drei Antworten, die in Code Reviews erschreckend häufig vorkommen. A.8.28 verlangt, dass sichere Codierungsprinzipien über den gesamten Entwicklungsprozess hinweg angewandt werden — von der Konfiguration der Entwicklungsumgebung bis zur sicheren Auslieferung des fertigen Produkts.
Die Kontrolle adressiert den Code selbst: Wie wird er geschrieben, geprüft, getestet und ausgeliefert?
Was verlangt die Norm?
- Codierungsrichtlinien definieren. Verbindliche Standards für sicheres Programmieren, die für alle Entwickler gelten.
- Entwicklungstools sicher konfigurieren. IDEs, Compiler und Build-Tools mit aktivierten Sicherheitsoptionen (Warnungen, sichere Defaults).
- Sichere Techniken anwenden. Eingabevalidierung, Output-Encoding, parametrisierte Queries, sichere Fehlerbehandlung, Secrets Management.
- Code regelmäßig prüfen. Code Reviews mit Sicherheitsfokus, statische Analyse, dynamische Tests.
- Externe Bibliotheken kontrollieren. Drittanbieter-Code auf Sicherheit prüfen, Abhängigkeiten aktuell halten, Software Composition Analysis (SCA) einsetzen.
- Updates sicher ausliefern. Releases signieren, Integritätsprüfung ermöglichen, sichere Verteilungswege nutzen.
In der Praxis
Secure Coding Guidelines erstellen. Ein Dokument pro Programmiersprache/Framework: Wie wird Input validiert? Wie werden Queries gebaut? Wie wird mit Fehlern umgegangen? Wie werden Secrets verwaltet? Konkrete Beispiele für richtigen und falschen Code.
SAST in die CI-Pipeline integrieren. Tools wie SonarQube, Semgrep, Checkmarx oder Bandit (Python) prüfen den Code bei jedem Commit auf bekannte Schwachstellenmuster. Kritische Findings blockieren den Build.
Software Composition Analysis (SCA) einsetzen. Dependabot, Snyk oder OWASP Dependency-Check scannen automatisch alle Abhängigkeiten auf bekannte CVEs. Veraltete oder verwundbare Bibliotheken werden automatisch gemeldet.
Secure Code Reviews standardisieren. Jeder Pull Request durchläuft einen Code Review mit Sicherheits-Checkliste: Eingabevalidierung vorhanden? Keine Secrets im Code? Fehlerbehandlung korrekt? Zugriffskontrollen implementiert? Die Checkliste macht den Review reproduzierbar.
Typische Audit-Nachweise
- Secure Coding Guidelines — dokumentierte Standards pro Sprache/Framework (→ Richtlinie sichere Softwareentwicklung im Starter Kit)
- SAST-Berichte — Ergebnisse der statischen Codeanalyse
- SCA-Berichte — Scan-Ergebnisse für Drittanbieter-Abhängigkeiten
- Code-Review-Protokolle — Nachweis der sicherheitsfokussierten Reviews
- Schulungsnachweise — Secure-Coding-Trainings der Entwickler
KPI
Anteil der Code-Reviews mit Prüfung auf Einhaltung sicherer Codierungsstandards
Gemessen als Prozentsatz: Wie viele deiner Code-Reviews enthalten eine explizite Sicherheitsprüfung? Ziel: 100%.
Ergänzende KPIs:
- Anzahl der kritischen SAST-Findings pro 1000 Codezeilen (Ziel: abnehmend)
- Anteil der Abhängigkeiten ohne bekannte kritische CVEs (Ziel: über 95%)
- Mittlere Behebungszeit für Sicherheits-Findings im Code
BSI IT-Grundschutz
- CON.8 (Software-Entwicklung) — sichere Codierungspraktiken, Code Reviews, Versionskontrolle.
- CON.10 (Entwicklung von Webanwendungen) — spezifische Anforderungen für sichere Webentwicklung (Input-Validierung, Session-Management, CSRF-Schutz).
Verwandte Kontrollen
- A.8.25 — Sicherer Entwicklungslebenszyklus: Der übergeordnete Rahmen für sichere Softwareentwicklung.
- A.8.4 — Zugriff auf den Quellcode: Schutz des Codes vor unbefugtem Zugriff und Manipulation.
- A.8.29 — Sicherheitstests: Tests, die die Einhaltung der Codierungsstandards verifizieren.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.28 — Sicheres Programmieren
- ISO/IEC 27002:2022 Abschnitt 8.28 — Umsetzungshinweise zum sicheren Programmieren
- BSI IT-Grundschutz, CON.8 — Software-Entwicklung