Jede bewährte Praxis im Engineering bekommt irgendwann einen Namen. Diese hier ist die Compliance-Prüfung für Pull Requests: Jede Änderung wird gegen die Compliance-Frameworks geprüft, die Ihr Unternehmen erfüllen muss, und die spezifische Kontrolle, die betroffen ist, wird direkt im Diff benannt, bevor der Merge erfolgt. heygrc ist unser Beitrag in dieser Kategorie, aber die Kategorie ist größer als jedes Produkt und verdient eine eigene Begründung.
Kategorien teilen sich auf, und Code-Review teilt sich jetzt
Praktiken konvergieren nicht zu einem All-in-One-Tool, sie divergieren zu Spezialisten. Code-Review hat sich bereits einmal aufgeteilt: Die Prüfung der Korrektheit (funktioniert diese Änderung?) und die Sicherheitsprüfung (ist diese Änderung sicher?) sind unterschiedliche Fragen, die von verschiedenen Reviewern mit unterschiedlichem Wissen auf demselben Pull Request beantwortet werden. Niemand erwartet von einem Linter, dass er eine Injektion findet, und niemand erwartet von einem Security-Scanner, dass er einen Off-by-One-Fehler erkennt.
Compliance ist die dritte Aufteilung. Ob eine Änderung eine Kontrolle betrifft, die geprüft wird, ist weder eine Frage der Korrektheit noch der Sicherheit: Eine Änderung kann korrekt und sicher sein und trotzdem einen Zugriffspfad erweitern, den SOC 2 CC6.1 betrifft, oder ein Log kürzen, das ISO 27001:2022 A.8.15 erwartet. Eine andere Frage, anderes Wissen, derselben Diff. Wenn eine Frage häufig genug in ihren eigenen Begriffen gestellt wird, wird sie zu einer Kategorie.
Warum die Kategorie jetzt existiert und nicht vor fünf Jahren
Zwei Kurven haben sich gekreuzt. Die erste: KI-Unterstützung erhöht die Menge an Code, die Teams produzieren, und die menschliche Prüfungszeit pro Änderung hat damit nicht Schritt gehalten. Teams, die mit Agenten ausliefern, mergen mehr Änderungen, schneller und mit weniger menschlicher Prüfung pro Zeile, als die Praxis ursprünglich vorsah.
Die zweite: Die Compliance-Oberfläche derselben Codebasen wächst. Mehr Unternehmen streben SOC 2 und ISO 27001 früher an; zur DSGVO sind DORA, NIS 2 und der EU AI Act hinzugekommen; und die Verpflichtungen leben zunehmend im Code, in Aufbewahrungsfristen, Zugriffspfaden, Logs und Modellverhalten. Mehr Änderungen, weniger menschliche Prüfung, mehr Verpflichtungen pro Änderung: Die Compliance-Prüfung benötigt Automatisierung im Diff, wenn sie konsequent erfolgen soll.
Was die Kategorie ist und was nicht
Ein Compliance-Reviewer für Pull Requests prüft die Änderung gegen die von Ihrem Unternehmen ausgewählten Frameworks und verankert jedes Ergebnis in der spezifischen Kontrolle, die betroffen ist, in einer Granularität, die überprüfbar oder anfechtbar ist. Er läuft dort, wo Code-Review bereits stattfindet, und informiert, statt zu blockieren: Ergebnisse sind Review-Kommentare und ein Prüfstatus, kein blockierter Merge.
Es ist keine GRC-Plattform (es verwaltet nicht Ihr Compliance-Programm oder sammelt Ihre Nachweise), keine Prüfung (es ist ein Frühindikator für dieselben Verpflichtungen, die die Prüfung misst), und keine Zertifizierung (ein Review ist eine Prüfung, kein Siegel). Diese Tools behalten ihre Aufgaben. Diese Kategorie existiert für die eine Aufgabe, die keines von ihnen übernimmt: die Compliance-Frage, die für jeden Diff gestellt wird, während die Änderung noch günstig zu beheben ist.