Ingenieure, die sich erstmals mit ISO 27001 beschäftigen, stellen sich oft eine riesige Code-Audit oder ein Zertifikat vor, das man wie einen Test-Suite besteht. Es ist weder das eine noch das andere. ISO/IEC 27001:2022 ist ein Standard für Managementsysteme. Sie bauen ein Informationssicherheits-Managementsystem (Richtlinien, Risikobehandlung, Rollen, Lieferanten, Vorfälle und der Rest). Ein akkreditierter Zertifizierungsstelle auditiert dieses System und stellt, wenn es den Anforderungen entspricht, ein Zertifikat aus. Das GitHub-Repository ist nicht das zertifizierte Objekt.
Diese Seite behandelt den kleinen Teil, der tatsächlich im Repository lebt: die technologischen Kontrollen aus Annex A, die ein Pull Request unbemerkt schwächen können. Es ist der ISO 27001-Gegenpart zu den SOC 2- und HIPAA-Führern "Was es tatsächlich überprüft". Es ist nicht der Kontrollkatalog (das ist der Framework-Hub) und es ist nicht die Frage "Gibt es eine GitHub-App" (das hat seine eigene Antwort).
Das Zertifikat ist kein Repository-Scan
Ein SOC 2 Type II-Bericht ist die Meinung einer unabhängigen Wirtschaftsprüfungsgesellschaft darüber, ob Ihre Kontrollen, wie Sie sie beschrieben haben, in einem bestimmten Zeitraum geeignet gestaltet waren und wirksam betrieben wurden. Ein Type I-Bericht bezieht sich nur auf das Design zu einem bestimmten Zeitpunkt. Ein akkreditiertes ISO 27001-Zertifikat ist anders: Eine akkreditierte Zertifizierungsstelle bestätigt, dass Ihr Managementsystem den Standard erfüllt. Keines davon ist eine statische Quellcode-Scan. Keines davon wird von einer GitHub-App ausgegeben. Wenn ein Anbieter impliziert, dass die Installation eines Reviewers "ISO 27001" für Sie erreicht, beschreibt er ein anderes Produkt als den Standard.
Anhang A der ISO/IEC 27001:2022 listet 93 Kontrollen in vier Themenbereichen (organisatorisch, personenbezogen, physisch, technologisch) auf. Sie implementieren nicht alle 93 als Code-Checkliste. Die Erklärung der Anwendbarkeit (Statement of Applicability) dokumentiert die Kontrollen, die Sie für notwendig erachtet haben, warum sie enthalten sind, ob sie implementiert sind und warum eine Kontrolle aus Anhang A ausgeschlossen ist. Anhang A ist ein Referenzset, gegen das Sie diese Entscheidungen überprüfen, kein Menü mit 93 Punkten, die als Code implementiert werden müssen. Die meisten der 93 tauchen nie in einem Diff auf: Lieferantenverträge, physische Büros, HR-Screening, Risikobehandlungsdokumentation. Die Behandlung der 93 als Repo-Audit ist die falsche Granularität.
Der Annex A-Teil, der im Code lebt
Das technologische Thema (A.8) enthält 34 Kontrollen. Selbst dort tauchen nur wenige regelmäßig in einem Pull Request auf: Protokollierung (A.8.15), Überwachung (A.8.16), Kryptographie und Schlüsselverwaltung (A.8.24), Zugriffsbeschränkung (A.8.3), Authentifizierungsstärke (A.8.5), Konfiguration, die mit einer Baseline übereinstimmt (A.8.9), sichere Programmierung (A.8.28), Änderungsmanagement (A.8.32) und Datensicherung (A.8.13). Wenn Sie begründen können, wer auf was zugreifen kann, wie sie sich ausweisen, was protokolliert wird, wie Geheimnisse gehalten werden und ob eine Änderung noch durch den von Ihnen beschriebenen Prozess gegangen ist, dann begründen Sie den größten Teil der codebezogenen Oberfläche.
Der Rest von A.8 (Netzwerke, Kapazität, Malware, Uhren und dergleichen) ist real, aber wird in der Regel in der Architektur und im Betrieb entschieden, nicht in einem zweizeiligen Anwendungs-PR. Der Framework-Hub listet die Auslöser auf. Diese Seite ist das mentale Modell: ISO 27001 in einem Repository sind diese A.8-Formen, nicht das Zertifikat und nicht die gesamte Annex A-Liste.
Ein privilegierter Pfad, der einen zweiten Faktor stillschweigend entfernt
Ein Support-Team kann während eines Vorfalls keinen API-Token erstellen, weil der Admin-Pfad MFA erfordert und das Bereitschaftstelefon in einem Schrank ist. Ein Pull Request entfernt die Zweifaktor-Prüfung und lässt das Sitzungs-Cookie als einziges Tor zurück. Die Tests bleiben grün. Der Code ist kürzer. Die Review-Kommentare drehen sich darum, den Vorfall zu entschärfen. Nach dem Merge kann jeder, der ein gültiges Sitzungs-Cookie erhalten kann, einen privilegierten Token ohne den zusätzlichen Faktor erstellen, den der Pfad früher verlangte.
ISO 27001:2022 A.8.5 befasst sich mit der Authentifizierungsstärke. Eine privilegierte Aktion, die früher einen zweiten Faktor erforderte und nun nur noch ein Sitzungs-Cookie benötigt, ist nach dem Merge schwächer. Ob dies akzeptabel ist (eine dokumentierte, zeitlich begrenzte Vorfallsausnahme im Vergleich zu einem dauerhaften Loch) ist eine Risikobewertung für das Team. Die Aufgabe des Reviews besteht darin, die Kontrolle zu benennen, damit die Entscheidung bewusst getroffen wird. A.8.3 (Zugriffsbeschränkung) kann daneben stehen, wenn der Token die Art und Weise ist, wie der Zugriff gewährt wird.
Die umgekehrte Änderung, requireMfa wieder auf der Route zu aktivieren oder den Token-Minting-Prozess für Vorfälle über einen Break-Glass-Pfad zu leiten, der protokolliert wird und abläuft, ist günstig im PR. Die schwächere Variante ist teuer: Sechs Monate später kann ein Prüfer der Zertifizierungsstelle fragen, wie privilegierte Aktionen authentifiziert werden, und der Kontext ist verloren.
Wo heygrc passt und die Ehrlichkeitsgrenze
heygrc ist eine GitHub-App, die jeden Pull Request auf die von Ihnen ausgewählten Frameworks überprüft und die Annex A-Kontrolle zitiert, die eine Änderung betrifft, z. B. A.8.5 beim MFA-Skip oben oder A.8.15, wenn eine privilegierte Aktion nicht mehr protokolliert wird. Es zertifiziert Sie nicht. Es führt Ihr ISMS nicht aus. Es schreibt die Erklärung der Anwendbarkeit nicht, wählt die Zertifizierungsstelle nicht aus oder stellt ein Zertifikat aus. Weder heygrc noch ISMS Copilot besitzt eine ISO 27001-Zertifizierung. Verwenden Sie es als Reviewer der Änderung, nicht als Managementsystem.
Wenn die Frage, die Sie tatsächlich gestellt haben, "Gibt es eine GitHub-App für ISO 27001" war, lautet die kurze Antwort ja, und sie lebt auf ihrer eigenen Seite. Diese Anleitung ist die andere Hälfte: Worauf diese App überhaupt achten würde und warum die meisten Teile von ISO 27001 nie im Diff auftauchen werden.