ISO 27001:2022, A.8.25 bis A.8.28: Die vier Entwicklungs-Controls und womit man jedes belegt
Sicherer Entwicklungslebenszyklus, Anforderungen an Anwendungssicherheit, sichere Architektur, sichere Codierung: Was die vier Controls des Anhangs A verlangen, welche davon ein laufender Code-Scan datiert belegt, welche nicht, und wo A.8.8 quer dazu liegt.
Warum die 2022er Fassung hier genauer ist
In der Vorgängerfassung lagen die Anforderungen an sichere Entwicklung verstreut in einem breiteren Abschnitt. Die Revision 2022 hat sie im Anhang A unter dem Thema Technologie neu sortiert und ihnen eigene Nummern gegeben. Für den Mittelstand hat das eine praktische Folge: Ein Auditor arbeitet die Nummern einzeln ab, und für jede will er einen eigenen Nachweis sehen. Eine allgemeine Aussage, man entwickle sicher, deckt keine der vier.
Auf unserer Seite zu Code-Sicherheit und Compliance steht die Zuordnung in Kurzform. Hier folgt sie Control für Control, mit der ehrlichen Angabe, was ein Scan beisteuert und was nicht.
A.8.25: Sicherer Entwicklungslebenszyklus
Das Control verlangt, dass Regeln für die sichere Entwicklung von Software und Systemen festgelegt und angewendet werden. Der zweite Teil ist der schwierigere. Regeln stehen schnell in einem Dokument; dass sie angewendet werden, muss man zeigen. Ein Scan, der bei jedem Commit läuft und jede Änderung im Zusammenhang der Codebasis bewertet, bevor der Code weiterläuft, ist ein Beleg für genau diesen zweiten Teil: Die Regel greift im Prozess, nicht erst im Jahresbericht.
Was der Scan nicht ersetzt, ist die Regel selbst. Das Dokument, das festlegt, wie entwickelt wird, muss es geben. Der Scan belegt seine Anwendung, nicht seine Existenz.
A.8.26: Anforderungen an die Anwendungssicherheit
Hier geht es darum, dass Sicherheitsanforderungen beim Entwickeln oder Beschaffen einer Anwendung ermittelt, spezifiziert und genehmigt werden. Das passiert vor der ersten Zeile Code, in Lastenheften, Tickets und Freigaben. Ein Scanner sieht davon nichts. Er kann prüfen, ob eine Eingabe validiert wird, aber nicht, ob jemand vorher festgelegt hat, dass sie validiert werden muss.
Der Beleg für A.8.26 ist deshalb ein Dokument: die spezifizierten Anforderungen und ihre Genehmigung. Wer hier einen Scan-Bericht vorlegt, belegt das falsche Control.
A.8.27: Sichere Systemarchitektur und Entwicklungsgrundsätze
Dieses Control verlangt, dass Grundsätze für sichere Architektur festgelegt, dokumentiert und in jeder Entwicklung angewendet werden. Auch das ist eine Designfrage. Wie Dienste voneinander getrennt sind, wo Vertrauensgrenzen liegen, welche Daten wo verarbeitet werden: Das steht in Architekturdokumenten und Reviews, nicht im Quelltext. Ein Scanner findet ein hartkodiertes Passwort, aber er findet nicht, dass eine Komponente aus Designgründen nie hätte direkt am Netz hängen dürfen.
Für A.8.27 sind Architektur-Reviews der Beleg. Ein Penetrationstest kann sie ergänzen, weil er das laufende System als Ganzes aus Angreifersicht prüft.
A.8.28: Sichere Codierung
Das Control verlangt, dass Grundsätze der sicheren Codierung angewendet werden. Hier ist der Scan zu Hause. Ungeprüfte Eingaben, gefährliche Systemaufrufe, fehlende Zugriffskontrollen, hartkodierte Zugangsdaten: Das sind Verstöße gegen Codierungsgrundsätze, die ein Muster haben, und ein Scan bei jedem Commit erkennt sie, sobald sie entstehen. Jeder Fund, seine Einordnung, die Behebung und das Datum bilden zusammen den Beleg, dass die Grundsätze nicht nur beschlossen, sondern durchgesetzt werden.
Zwei Einschränkungen gehören dazu. Erstens findet kein Scanner alle Verstöße; Geschäftslogik-Fehler haben kein Muster. Zweitens meldet jeder Scanner auch Funde, die im konkreten Fall nicht ausnutzbar sind. Deshalb ordnet bei uns ein Mensch jeden Fund ein, bevor er in die Dokumentation wandert.
A.8.8: Management technischer Schwachstellen, quer dazu
A.8.8 ist kein Entwicklungs-Control, aber es liegt über allen vieren: Informationen über technische Schwachstellen der genutzten Systeme sind zu beschaffen, die Exposition ist zu bewerten, und es sind Maßnahmen zu ergreifen. Für den eigenen Code heißt das vor allem: die Open-Source-Abhängigkeiten. Der Scan gleicht sie laufend gegen bekannte Schwachstellen ab, und wenn eine Bibliothek aktualisiert wird, stehen Fund, Maßnahme und Datum in der Akte. Das ist der einfachste Beleg der ganzen Liste, und der, der am häufigsten fehlt.
Der Einstieg dafür ist die kostenlose Code-Analyse: Anbindung, Bestandsscan über Secrets, Abhängigkeiten und unsichere Muster, priorisierter Befund.
Häufig gestellte Fragen
Belegt ein Code-Scan alle vier Entwicklungs-Controls?
Nein. A.8.28 und den Anwendungsteil von A.8.25 belegt er direkt und datiert. A.8.26 und A.8.27 betreffen Anforderungen und Architektur, also Entscheidungen vor dem Code, und dafür braucht es Dokumente und Reviews.
Ersetzt der Scan das ISMS oder die Zertifizierung?
Nein, und die Reihenfolge ist umgekehrt: Das ISMS entscheidet, welche Controls für Euch gelten, die Risikobewertung, wie weit, und die Zertifizierung prüft beides. Der Scan liefert lediglich die datierten Funde für zwei dieser Controls und für A.8.8. Er ist ein Zulieferer der Akte, nicht die Akte.
Wir haben die Norm noch nicht eingeführt. Lohnt sich der Scan trotzdem?
Ja, weil dieselben Funde auch nach § 30 BSIG zählen, wenn Ihr unter NIS2 fallt, und weil Belege, die heute datiert entstehen, später nicht nachgesammelt werden müssen. Der Scan ist das Werkzeug, das Ihr zuerst habt, nicht das letzte.