Keine Bugs. Änderungen, die in einer Prüfung auffallen würden. Neun Kategorien, zugeordnet zu ISO 27001:2022 und SOC 2. Die Liste ist die Granularität der Prüfung, nicht die 93 Zeilen von Anhang A.
Eine compliance-relevante Änderung ist ein Diff, der in einer Prüfung von Bedeutung wäre: Er ändert, wer auf was zugreifen kann, was protokolliert wird, wie lange ein Protokoll aufbewahrt wird, wie ein Secret gespeichert wird oder ob eine Kontrolle noch Belege hat. In der Regel handelt es sich nicht um einen Bug. Tests können grün bleiben. Der Code kann kürzer sein. Die Verpflichtung ist nach dem Merge schwächer als vorher.
heygrc führt kein festes Regelpaket aus. Es liest den Pull Request gegen die von Ihnen ausgewählten Frameworks (ISO 27001:2022 Anhang A, SOC 2 TSC, GDPR, NIS 2 und den Rest des Katalogs) sowie den von Ihnen angegebenen Unternehmenskontext. Die folgenden Kategorien sind die Muster, nach denen die Prüfung sucht. Sie decken nicht alle Kontrollen in Anhang A ab und es gibt keine Garantie, dass jede Zeile in jedem Repository ausgelöst wird.
Änderungs-Kategorien und die Klauseln, auf die sie sich in der Regel beziehen
| Änderungs-Kategorie | ISO 27001:2022 | SOC 2 |
|---|---|---|
| Zugriffskontrolle und Autorisierung | A.5.15 bis A.5.18, A.8.2 bis A.8.5 | CC6 |
| Authentifizierung | A.8.5 | CC6 |
| Logging, Monitoring und wie lange Protokolle aufbewahrt werden | A.8.15, A.8.16 | CC7 |
| Datenverarbeitung: neue PII-Felder, Exporte, Maskierung, Löschung | A.8.10 bis A.8.12 | CC6 |
| Verschlüsselung bei Übertragung und im Ruhezustand, Schlüsselverwaltung | A.8.24 | CC6 |
| Secrets und Anmeldeinformationen im Code oder in der Konfiguration | A.8.24 | CC6 |
| Anbieter und Dritte: SDKs, Unterauftragsverarbeiter, ausgehende Datenflüsse | A.5.19 bis A.5.23 | CC9 |
| Aufbewahrungs- und Löschregeln | A.8.10, A.5.33 | CC6 |
| Prüfbelege: Genehmigungen, CI-Gates, Migrationen | A.8.32, A.5.33 | CC8 |
Die neun Kategorien
Zugriffskontrolle und Autorisierung: Rollen, Berechtigungen, zeilenbasierte Sicherheit, Admin-Pfade. Eine erweiterte IAM-Rolle oder eine neue nicht authentifizierte Route fällt in diese Kategorie. ISO 27001:2022 A.5.15 bis A.5.18 und A.8.2 bis A.8.5. SOC 2 CC6.
Authentifizierung: MFA, Sitzungen, Anmeldeinformationsverwaltung. Eine privilegierte Route, die früher einen zweiten Faktor erforderte und jetzt nur noch eine Sitzung benötigt, fällt in diese Kategorie. A.8.5. SOC 2 CC6.
Logging, Monitoring und Prüfprotokolle, einschließlich der Dauer ihrer Aufbewahrung. Beispiel: Die Verkürzung der Aufbewahrungsdauer von Prüfprotokollen von 365 Tagen auf 30 Tage betrifft A.8.15 und SOC 2 CC7.2. Monitoring fällt unter A.8.16.
Datenverarbeitung: ein neues PII-Feld, ein Export, entfernte Maskierung, ein Löschpfad, der einen Speicher überspringt. A.8.10 bis A.8.12. SOC 2 CC6, wenn die Änderung betrifft, wer auf die Daten zugreifen kann.
Verschlüsselung bei Übertragung und im Ruhezustand sowie Schlüsselverwaltung. A.8.24. SOC 2 CC6.
Secrets und Anmeldeinformationen im Code oder in der Konfiguration. Ein in den Quellcode eingefügter Schlüssel ist ein freigelegtes Secret. A.8.24. SOC 2 CC6.
Anbieter und Dritte: ein neues SDK, ein Unterauftragsverarbeiter, ein ausgehender Datenfluss, der gestern noch nicht existierte. A.5.19 bis A.5.23. SOC 2 CC9, wenn die Änderung eine Lieferantenbeziehung ist, die im Code ausgedrückt wird.
Aufbewahrungs- und Löschregeln. Eine neue Tabelle mit identifizierten Ereignissen ohne Bereinigungsauftrag. A.8.10 und A.5.33. SOC 2 CC6.
Prüfbelege: Genehmigungen, CI-Gates, Migrationen, die eine erforderliche Prüfung entfernen. A.8.32 und A.5.33. SOC 2 CC8. Eine CODEOWNERS-Bearbeitung, die einen Domain-Besitzer entfernt, fällt in diese Kategorie.
Wie dies im Zusammenhang mit dem ISO-in-Repo-Leitfaden steht
Die meisten dieser Kategorien fallen unter das Thema A.8 von Anhang A, die technischen Kontrollen. Dies ist derselbe Bereich wie im ISO 27001-in-Repo-Leitfaden: Logging, Authentifizierung, Zugriffsbeschränkung, Kryptographie, Change Management. Einige Kategorien verweisen auch auf A.5, wenn die Änderung betrifft, wie Zugriff gewährt, ein Anbieter hinzugefügt oder Aufzeichnungen verwaltet werden. Die Liste mit 93 Kontrollen in Anhang A ist dennoch die falsche Granularität. Sie implementieren nicht 93 Punkte als Code-Checkliste. Die Erklärung zur Anwendbarkeit ist der Ort, an dem diese Entscheidungen dokumentiert werden.
GDPR, NIS 2, HIPAA, CCPA und der Rest des Katalogs verwenden dieselben Änderungen-Kategorien und verweisen auf ihre eigenen Klauseln. Die Spalten für ISO und SOC 2 in der Tabelle sind die üblichen Zuordnungen. Sie sind nicht die einzigen Zuordnungen.
Schweregrad und eine Änderung, die eine Kontrolle verbessert
Der Schweregrad ist das Compliance-Risiko, das entsteht, wenn der Pull Request so wie er ist gemergt wird. Ein Befund benennt die Kontrolle, damit das Team bewusst entscheiden kann. Ein Pull Request, der MFA wiederherstellt, die Aufbewahrungsdauer verlängert oder einen hartcodierten Schlüssel entfernt, ist kein Befund. Diese Änderung erhält einen Hinweis in der Zusammenfassung.
heygrc erstellt standardmäßig einen neutralen GitHub-Check. Es zertifiziert Sie nicht, schreibt nicht die Erklärung zur Anwendbarkeit und ersetzt keinen Prüfer. Es ist als GitHub-App verfügbar. Verwenden Sie es als Reviewer der Änderung.