ISO 27001 in der Softwareentwicklung: Annex A, Secure SDLC und Praxis

© TenMedia GmbH

Welche Annex-A-Controls die Softwareentwicklung betreffen

Der Annex A der ISO 27001:2022 enthält 93 Controls — Sicherheitsmaßnahmen, aus denen Organisationen die für sie relevanten auswählen. Für Softwareunternehmen sind vor allem die technologischen Controls der Kategorie 8 entscheidend. Fünf davon betreffen den Entwicklungsprozess unmittelbar.

Control 8.25: Secure Development Lifecycle. Die Norm fordert, dass Regeln für die sichere Entwicklung von Software definiert und angewendet werden. Das klingt abstrakt, hat aber konkrete Konsequenzen: Sicherheitsanforderungen müssen bereits in der Planungsphase erfasst werden — nicht erst als nachträglicher Prüfschritt vor dem Go-live. Bei TenMedia beginnt jedes Projekt mit einer Risikobewertung, die den Schutzbedarf der zu verarbeitenden Daten und die Angriffsfläche der geplanten Architektur bewertet.

Control 8.26: Anforderungen an die Anwendungssicherheit. Sicherheitsanforderungen müssen identifiziert, spezifiziert und bei jeder Änderung aktualisiert werden. In der Praxis bedeutet das: Wenn eine Anwendung personenbezogene Daten verarbeitet, werden die Anforderungen an Verschlüsselung, Authentifizierung und Autorisierung explizit im Pflichtenheft verankert — nicht als allgemeine Absichtserklärung, sondern als testbare Kriterien.

Control 8.28: Secure Coding. Dieses Control ist neu in der 2022er-Fassung und fordert explizit sichere Programmierpraktiken. Dazu gehören die Anwendung anerkannter Coding Standards, die Vermeidung bekannter Schwachstellenmuster (OWASP Top 10), die Nutzung aktueller Frameworks und Libraries sowie die regelmäßige Prüfung auf bekannte Verwundbarkeiten in Abhängigkeiten. Bei TenMedia nutzen wir automatisierte Tools wie Dependency Scanning in der CI/CD-Pipeline, um veraltete oder verwundbare Pakete frühzeitig zu erkennen.

Control 8.31: Trennung von Entwicklungs-, Test- und Produktionsumgebungen. Entwicklungs-, Test- und Produktionsumgebungen müssen voneinander getrennt sein, um das Risiko unbefugter Zugriffe oder versehentlicher Änderungen an Produktivsystemen zu minimieren. Welche Auswirkungen das auf den Entwicklungsalltag hat, beschreiben wir weiter unten im Detail.

Control 8.32: Change Management. Änderungen an Produktivsystemen dürfen nicht unkontrolliert erfolgen. Jede Änderung — ob Feature, Bugfix oder Konfigurationsanpassung — muss genehmigt, dokumentiert und nachvollziehbar sein. Das betrifft nicht nur den Quellcode, sondern auch Infrastrukturänderungen, Datenbankmigrationen und Konfigurationsdateien.

Secure SDLC — von der Planung bis zum Deployment

Ein Secure Software Development Lifecycle (SDLC) ist kein eigenständiges Framework, sondern die Integration von Sicherheitsmaßnahmen in den bestehenden Entwicklungsprozess. ISO 27001 gibt das Ziel vor, den konkreten Weg wählt jedes Unternehmen selbst. Bei TenMedia sieht das so aus:

• Anforderungsanalyse
  Sicherheitsanforderungen werden gemeinsam mit funktionalen Anforderungen erfasst. Welche Daten verarbeitet die Anwendung? Welche Schutzstufe erfordern sie? Welche regulatorischen Vorgaben gelten — DSGVO, branchenspezifische Regelungen, behördliche Anforderungen? Die Antworten fließen in ein Sicherheitskonzept ein, das Teil der Projektdokumentation wird.

• Architektur und Design
  Bevor Code geschrieben wird, bewerten wir die Architektur auf potenzielle Angriffsvektoren. Welche Schnittstellen sind öffentlich erreichbar? Wo werden Daten gespeichert, wie werden sie übertragen? Brauchen wir eine Web Application Firewall? Ist eine Mandantentrennung erforderlich? Diese Fragen werden im Architekturentwurf beantwortet, nicht erst in der Testphase.

• Entwicklung
  Während der Entwicklung gelten die im ISMS definierten Coding Standards. Dazu gehören Eingabevalidierung, Ausgabecodierung, der Einsatz parametrisierter Datenbankabfragen, die Vermeidung hardcodierter Credentials und die konsequente Nutzung aktueller Framework-Versionen. Automatisierte Tools — Linter, SAST-Scanner, Dependency-Checker — prüfen den Code bei jedem Commit.

• Testing
  Neben funktionalen Tests führen wir gezielte Sicherheitstests durch: automatisierte Schwachstellenscans gegen die Anwendung (DAST), manuelle Prüfung sicherheitskritischer Funktionen (Authentifizierung, Autorisierung, Datenzugriff) und Penetrationstests bei besonders sensiblen Anwendungen.

• Deployment
  Der Rollout auf Produktionsumgebungen erfolgt ausschließlich über die CI/CD-Pipeline — kein manuelles Hochladen, keine direkten Änderungen auf dem Server. Jede Deployment-Aktion wird protokolliert. Rollback-Mechanismen stehen bereit, falls ein Release Probleme verursacht.

Code Reviews und Vier-Augen-Prinzip

ISO 27001 macht Code Reviews faktisch verpflichtend — nicht durch einen einzelnen Control, sondern durch das Zusammenspiel mehrerer Anforderungen: Secure Coding (8.28), Change Management (8.32) und die übergeordnete Forderung nach Kontrolle und Nachvollziehbarkeit.

Bei TenMedia bedeutet das: Kein Code erreicht die Produktionsumgebung, ohne von mindestens einer zweiten Person geprüft worden zu sein. Der Prozess ist dreistufig:

Automatisierte Prüfung. Bei jedem Pull Request laufen automatisch Linting-Regeln, Unit-Tests, SAST-Scanner und Dependency-Checks. Schlägt einer dieser Checks fehl, kann der Pull Request nicht gemergt werden.

Manuelles Review. Ein Entwickler, der nicht am betreffenden Code mitgearbeitet hat, prüft die Änderung auf Logikfehler, Sicherheitslücken, Architekturkonformität und Wartbarkeit. Bei sicherheitskritischen Bereichen — Authentifizierung, Verschlüsselung, Zugriffssteuerung — wird ein Senior-Entwickler hinzugezogen.

Dokumentation. Die Review-Ergebnisse werden im Versionskontrollsystem festgehalten: Wer hat wann was geprüft und freigegeben? Diese Dokumentation ist nicht nur für interne Zwecke relevant, sondern auch für externe Audits.

Trennung von Entwicklungs-, Test- und Produktionsumgebung

Control 8.31 fordert die Trennung von Umgebungen. Für Standardsoftware-Projekte mag das trivial klingen — bei Individualsoftware ist es alles andere als selbstverständlich. Drei Aspekte sind besonders relevant:

Zugriffsrechte. Entwickler haben Zugriff auf die Entwicklungsumgebung. Auf die Produktionsumgebung haben nur autorisierte Personen Zugriff — und auch das nur für definierte Tätigkeiten (Deployment, Incident Response, Monitoring). Die Berechtigungen werden regelmäßig überprüft und bei Personalwechseln sofort angepasst.

Testdaten. Produktionsdaten dürfen nicht unverändert in Test- oder Entwicklungsumgebungen übernommen werden, wenn sie personenbezogene Informationen enthalten. Data Masking — die Anonymisierung oder Pseudonymisierung von Testdaten — ist in ISO 27001:2022 erstmals als eigenes Control (8.11) verankert. In der Praxis setzen wir anonymisierte Datensätze oder synthetische Testdaten ein, die die Struktur der Produktionsdaten abbilden, ohne reale Personendaten zu exponieren.

Infrastruktur. Die Umgebungen laufen auf getrennter Infrastruktur. Keine gemeinsamen Datenbanken, keine gemeinsamen Server, keine „Abkürzungen” für schnelle Fixes. Änderungen durchlaufen immer den Pfad Entwicklung → Staging/Test → Produktion.

Was das für Auftraggeber bedeutet

Die beschriebenen Maßnahmen sind keine internen TenMedia-Regeln, die bei Zeitdruck aufgeweicht werden. Sie sind Bestandteil unseres ISMS und werden jährlich vom TÜV Süd geprüft. Für Auftraggeber ergeben sich daraus handfeste Vorteile:

Nachvollziehbarkeit. Jede Codeänderung, jedes Deployment, jedes Review ist dokumentiert. Bei Audits, Compliance-Prüfungen oder Sicherheitsvorfällen kann jederzeit rekonstruiert werden, was wann von wem geändert wurde.

Keine Schatten-Deployments. Änderungen an der Produktionsumgebung sind nur über den definierten Prozess möglich. Kein Entwickler kann „mal eben schnell” etwas auf dem Server ändern, ohne dass es dokumentiert und geprüft wird.

Kontinuität bei Teamwechseln. Dokumentierte Prozesse und standardisierte Abläufe bedeuten, dass ein Personalwechsel im Entwicklungsteam nicht zu einem Sicherheitsrisiko wird. Das neue Teammitglied arbeitet nach denselben Regeln wie das vorherige.

Belastbare Sicherheitszusagen. Die Sicherheitsmaßnahmen sind nicht nur versprochen, sondern extern geprüft. Das vereinfacht die Lieferantenprüfung erheblich — insbesondere für Auftraggeber, die selbst nach ISO 27001 zertifiziert sind und ihre Lieferkette absichern müssen.

Weiterführende Informationen

• ISO 27001 zertifizierte Softwareentwicklung — Unsere Leistungen als zertifizierter IT-Dienstleister
• ISO 27001 in Ausschreibungen — Vergaberecht und Eignungskriterien
• ISO 27001 Zertifizierung: Pflicht oder Kür? — Kosten, Ablauf und Vorteile
• Vergleich zwischen ISO-27001 und IT-Grundschutz
• Maintenance, Wartung und Support Service