Das Audit ist der Ort, an dem man es herausfindet. Der Pull Request ist der Ort, an dem es passiert ist. Irgendwo zwischen diesen beiden Momenten, oft Monate auseinander, hörte eine Kontrolle auf zu funktionieren, die ein Prüfer später stichprobenartig überprüfen würde, und niemand bemerkte es, weil die Änderung, die sie brach, nicht wie eine Compliance-Änderung aussah. Sie sah wie eine Bereinigung aus.
Hier ist das Muster. Die Kontrolle ist ISO 27001:2022 A.8.15, Protokollierung. Die Änderung ist eine gelöschte Zeile.
Die Änderung
Ein Pull Request räumt eine Funktion auf, die die Rolle eines Benutzers aktualisiert. In der Mitte befindet sich ein Log-Aufruf, den der Autor als Störfaktor empfindet. Er wird bei jeder Rollenänderung ausgelöst und überfüllt die Ausgabe, also wird er entfernt. Die Funktion funktioniert weiterhin. Die Tests bestehen weiterhin. Der Diff ist eine Zeile kürzer und, wenn überhaupt, sauberer.
async function updateRole(actor, target, role) { await db.roles.set(target, role)- await audit.log("role.update", { actor, target, role }) return ok()}Diese Zeile war der Audit-Eintrag für eine Änderung der Zugriffsrechte. A.8.15 (Protokollierung) verlangt, dass sicherheitsrelevante Ereignisse, einschließlich Änderungen an Berechtigungen, aufgezeichnet und aufbewahrt werden, und A.8.16 (Überwachung) hängt davon ab, dass dieser Eintrag existiert. Durch das Löschen wird der einzige Nachweis entfernt, dass sich eine Rolle jemals geändert hat.
Warum niemand es bemerkt hat
Ein Reviewer, der diesen Diff betrachtet, sieht eine entfernte Log-Zeile. Um das Problem zu erkennen, müsste er wissen, dass dieser bestimmte Log-Eintrag der Nachweis für eine Kontrolle ist, dass die Kontrolle A.8.15 ist und dass A.8.15 im Geltungsbereich ihrer Zertifizierung liegt. Das sind drei Rahmenwerk-Kenntnisse, die ein Code-Reviewer nicht im Kopf hat, während er eine routinemäßige Refaktorierung genehmigt.
Hier liegt die Lücke. Die Kontrolle ist am richtigen Ort, die Code-Review prüft bereits jede Änderung, absichtlich, bevor sie bereitgestellt wird. Was fehlt, ist das Bewusstsein für das Rahmenwerk, um zu erkennen, dass eine harmlos aussehende Zeile für ein Audit tragend ist.
Was es später kostet
Wird es hier erkannt, ist es eine einzeilige Rücknahme und ein dreißigsekündiges Gespräch. Der Autor hat die gesamte Änderung noch im Kopf. Wird es im Audit erkannt, ist es eine Ausnahme: Die Kontrolle funktionierte nicht über den gesamten Zeitraum, und jetzt muss jemand rekonstruieren, wann die Protokollierung gestoppt wurde, was davon abhing und wie sie sicher wiederhergestellt werden kann, unter Zeitdruck, möglicherweise nachdem der Autor das Unternehmen verlassen hat.
Die Kosten einer Compliance-Lücke werden durch eine Sache bestimmt: wie lange sie unentdeckt blieb. Der Pull Request ist der günstigste Ort, um sie zu bemerken.
Der Kern der Sache
Compliance scheitert in einem fünfzeiligen PR, nicht im Audit. Das Audit ist ein nachlaufender Indikator für eine Entscheidung, die jemand Wochen zuvor in einem Diff getroffen hat. heygrc wurde entwickelt, um diesen Diff gegen die Rahmenwerke zu prüfen, die Sie erfüllen müssen, und die Kontrolle zu benennen, die eine Änderung betrifft, A.8.15, im Pull Request, solange die Korrektur noch günstig ist.