Sucht man nach Compliance-Checks in Pull Requests, findet man meist Informationen zu GitHubs erforderlichen Status-Checks: sicherstellen, dass die Testsuite und der Linter grün sind, bevor ein Merge erfolgt. Das ist eine echte und nützliche Sache, aber nicht das Thema dieser Seite. Ein Compliance-Check stellt eine andere Frage an denselben Pull Request: Betrifft diese Änderung eine Kontrolle, für die Ihr Unternehmen in SOC 2, ISO 27001, der DSGVO oder einem anderen Rahmenwerk, an das Sie gebunden sind, geprüft wird?
Diese Frage hat selten einen Verantwortlichen im Code-Review. Korrektheit und Sicherheit haben jeweils gut definierte Checks; ob eine Änderung eine Kontrolle betrifft, für die Sie geprüft werden, ist eine separate Betrachtung, und genau diese fügt ein Compliance-Check im Pull Request hinzu. Es lohnt sich, präzise zu sein, was dieser Check ist und was nicht.
Was es ist und was nicht
Ein Compliance-Check liest den Diff, nicht die Testergebnisse. Er ordnet die tatsächliche Änderung der spezifischen Kontrolle zu, die sie betrifft, und gibt diese Kontrolle mit Namen an, in einer Granularität, die überprüfbar ist. Es ist kein Bestanden oder Durchfallen Ihrer Testsuite, keine Abdeckungsschwelle und kein Richtliniendokument, das ein Prüfer einmal im Jahr stichprobenartig überprüft. Es ist eine pro-Änderung-Betrachtung, ob der Pull Request vor Ihnen etwas betrifft, das Sie verpflichtet sind zu erhalten.
Das Ergebnis, das es nützlich macht, ist die Angabe der Quelle. "Das sieht nicht konform aus" ist nur Lärm. "Dies entfernt das Audit-Log für eine privilegierte Aktion, das ISO 27001:2022 A.8.15 von Ihnen erwartet, zu behalten" ist etwas, auf das ein Entwickler reagieren oder darüber diskutieren kann. Ein Compliance-Check, der die Kontrolle nicht benennen kann, ist es nicht wert, hinzugefügt zu werden.
Drei kontrollrelevante Änderungen, die sich in Routine-Pull-Requests verstecken
Ein erweiterter Zugriffspfad. Ein Pull Request erweitert eine IAM-Rolle oder öffnet eine neue Route zu einer Ressource. Der Code ist korrekt und möglicherweise völlig sicher, aber er erweitert, wer auf geschützte Daten zugreifen kann, und genau darum geht es bei SOC 2 CC6.1 (logische Zugriffskontrollen). Es kann wie eine Routine-Konfigurationsänderung aussehen, während die betroffene Kontrolle ungenannt bleibt.
Ein geschwächtes Audit-Log. Eine Bereinigung entfernt oder kürzt eine Log-Zeile, die zufällig die Aufzeichnung einer privilegierten Aktion war. Nichts bricht, und es kann wie eine harmlose Bereinigung aussehen, aber die Beweismittel, die ein Prüfer unter ISO 27001:2022 A.8.15 (Protokollierung) stichprobenartig überprüft, sind jetzt verschwunden. Die Änderung, die dies verursacht hat, ist der günstigste mögliche Ort, um es zu erkennen.
Ein neuer Speicher für personenbezogene Daten ohne Begrenzung. Eine Migration fügt eine Tabelle hinzu, die beginnt, personenbezogene Daten ohne Aufbewahrungsfrist zu sammeln. Es ist sauberer, funktionierender Code, und er bringt Sie stillschweigend auf die falsche Seite von DSGVO Art. 5(1)(e) (Speicherbegrenzung), der verlangt, dass personenbezogene Daten nicht länger als notwendig aufbewahrt werden. Keine dieser drei Änderungen ist ein Fehler oder eine Schwachstelle. Jede ist eine kontrollrelevante Änderung, die sich in einem Routine-Pull-Request versteckt.
Standardmäßig beraten, nur blockierend, wenn Sie es wählen
Ein Compliance-Check, der jeden Merge bei jedem Befund blockiert, trainiert die Leute, ihn zu übergehen; einer, der nie etwas blockiert, wird ignoriert. Die nützliche Standardeinstellung ist beraten: Der Check postet die Kontrolle und die Klausel als Kommentar und einen neutralen Status, sodass der Befund sichtbar ist, ohne den Merge zu unterbrechen. Die Entscheidung, ihn zu erzwingen, gehört zu Ihrer Branch-Schutzrichtlinie, nicht zum Tool.
Wenn eine übersehene Kontrolle tatsächlich kostspielig ist, z. B. alles, was Zugriffskontrolle, Kryptographie oder personenbezogene Daten betrifft, können Sie den Check über den Branch-Schutz für die Repositorys oder geschützten Branches erzwingen, bei denen es am wichtigsten ist, und ihn überall sonst als beraten belassen. Der Mechanismus sollte Ihnen die Wahl der Haltung ermöglichen, anstatt eine für alles zu erzwingen.
Wie man einen hinzufügt
Ein Compliance-Check wird für den Pull Request ausgeführt, genau wie Ihre anderen Checks: Er wird ausgelöst, wenn ein PR geöffnet oder aktualisiert wird, liest den Diff im Hinblick auf die von Ihnen ausgewählten Rahmenwerke und Ihren Unternehmenskontext und postet die Kontrollen, die eine Änderung betrifft, mit der angehängten Klausel. Der schwierige Teil ist nicht zu erkennen, dass sich etwas geändert hat; es ist, genau zu benennen, welche Kontrolle betroffen ist, und zwar korrekt. Deshalb müssen die Rahmenwerke, an die Sie gebunden sind, und Ihr eigener Kontext den Check speisen.
heygrc ist als GitHub App konzipiert, um dieser Check zu sein: Installieren Sie es, teilen Sie ihm Ihre Rahmenwerke und Ihren Kontext einmal mit, und es überprüft jeden Pull Request auf Compliance-Auswirkungen, postet einen neutralen Checks-Status sowie Inline-Kommentare, sodass es informiert, anstatt zu blockieren, es sei denn, Sie entscheiden sich, es zu erfordern. Die Einrichtungsanleitung behandelt die dreiminütige Onboarding-Prozedur.