ISO 27001 in der Softwareentwicklung: Annex A, Nachweise und Praxis

© TenMedia GmbH

Welche Annex-A-Controls die Softwareentwicklung betreffen

Der Annex A der ISO 27001:2022 enthält 93 Controls, also 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 die Softwareentwicklung nach ISO 27001 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. In der ISO-27001-Softwareentwicklung beginnt deshalb 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. Für die Softwareentwicklung nach ISO 27001 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, die Nutzung aktueller Frameworks und Libraries sowie die regelmäßige Prüfung auf bekannte Verwundbarkeiten in Abhängigkeiten. Dafür eignen sich 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, beschreibt der Abschnitt 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. Jede dieser Änderungen verschiebt zugleich den Bestand, weshalb Control 8.32 im ISO 27001 Asset Management auch die Fortschreibung des Verzeichnisses der Werte auslöst.

Nachweise in der ISO-27001-Softwareentwicklung

ISO 27001 schreibt keinen bestimmten Entwicklungsprozess vor. Die Norm verlangt, dass eine Organisation eigene Regeln für die sichere Softwareentwicklung festlegt und belegen kann, dass sie in jedem Projekt eingehalten wurden. Für die ISO-27001-Softwareentwicklung zählt im Audit deshalb weniger die Methode als die Spur, die sie in jeder Phase hinterlässt:

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

• Architektur und Design
  Bevor Code geschrieben wird, wird die Architektur auf potenzielle Angriffsvektoren bewertet. Welche Schnittstellen sind öffentlich erreichbar? Wo werden Daten gespeichert, wie werden sie übertragen? Ist eine Web Application Firewall nötig? 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 laufen gezielte Sicherheitstests: 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.

Seit September 2026 zertifiziert das BSI den Entwicklungsprozess zusätzlich nach der Technischen Richtlinie TR-03185.

Kontrollierte Änderungen: Code Reviews und getrennte Umgebungen

ISO 27001 macht Code Reviews faktisch verpflichtend, nicht durch ein einzelnes Control, sondern durch das Zusammenspiel mehrerer Anforderungen: Secure Coding (8.28), Change Management (8.32) und die übergeordnete Forderung nach Kontrolle und Nachvollziehbarkeit. Auch der IT-Grundschutz des BSI formuliert mit dem Baustein CON.8 Software-Entwicklung vergleichbare Anforderungen an einen kontrollierten Entwicklungsprozess.

Code Reviews und Vier-Augen-Prinzip

In der Praxis 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, also die Anonymisierung oder Pseudonymisierung von Testdaten, ist in ISO 27001:2022 erstmals als eigenes Control (8.11) verankert. In der Praxis kommen anonymisierte Datensätze oder synthetische Testdaten zum Einsatz, 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 über Entwicklung und Staging/Test bis in die Produktion, auch bei dringenden Korrekturen.

Was das für Auftraggeber bedeutet

Bei einem zertifizierten Dienstleister sind die beschriebenen Maßnahmen keine internen Regeln, die bei Zeitdruck aufgeweicht werden. Sie sind Bestandteil des ISMS und werden jährlich von der Zertifizierungsstelle 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. Wie sich das in Vergabeunterlagen abbilden lässt, behandelt ISO 27001 in Ausschreibungen, die Abgrenzung zum BSI-Standard der Vergleich zwischen ISO 27001 und IT-Grundschutz. Das vereinfacht die Lieferantenprüfung erheblich, insbesondere für Auftraggeber, die selbst nach ISO 27001 zertifiziert sind und ihre Lieferkette absichern müssen.

TenMedia ist nach ISO/IEC 27001 durch den TÜV SÜD zertifiziert und wendet die hier beschriebene ISO-27001-Softwareentwicklung in jedem Kundenprojekt an. Für den Betrieb nach der Abnahme gelten dieselben Regeln, gebündelt im Maintenance, Wartung und Support Service.