Ayoub Fandis neues GRC Engineer Issue behandelt Change-Management-Kontrollen, die weiterhin einen PR-Genehmigungs-Screenshot speichern, während die Genehmigung selbst weniger aussagt. Die Ausgabemenge der Agenten ist gestiegen. Die Prüfzeit nicht. Der grüne Haken sieht immer noch aus wie 2020. Was er bescheinigt, tut er nicht mehr.
Er hat recht. Wir würden hinzufügen: Der Schritt, den die meisten Teams gehen werden, ist, einen Menschen zurück in den PR zu setzen. Das erzeugt immer noch denselben Screenshot. Es sagt nicht, was der Mensch prüfen musste. Und die schriftliche Regel, die festlegt, wer Rechnungen, Zahlungen oder alles mit großer Reichweite prüfen muss, kann selbst in einem Hotfix kommentiert werden, den alle gerne mergen.
Der Screenshot kann die beiden Jahre nicht unterscheiden
Eine Genehmigung in einem Pull Request dokumentiert, dass der Workflow vor dem Merge einen Genehmigungsschritt erreicht hat. Der Screenshot dokumentiert nicht, was der Prüfer untersucht hat, wie viel Aufmerksamkeit er darauf verwendet hat oder welche schriftlichen Regeln er überprüft hat. Das ist immer noch das Artefakt, das die meisten Change-Management-Kontrollen von einem Prüfer als Stichprobe verlangen, weil es das Artefakt ist, das die Kontrolldefinition immer noch nennt.
Ayoub beschreibt den Verfall aus der eigenen Berichterstattung der Ingenieure: mehr Ausgabe, größere PRs, die Prüfung als neuer Engpass. Er verweist auf einen GitHub-Blog-Artikel, der eine externe Studie zusammenfasst: Von Agenten erstellte Änderungen zeigten mehr Redundanz und technische Schulden, während die Stimmung der Prüfer neutraler oder positiver war. Der Screenshot, den dein Katalog immer noch sammelt, kann diese beiden Jahre nicht unterscheiden. Der Haken ist immer noch grün. Die Aufmerksamkeit dahinter ist nicht dieselbe.
Einen Menschen zurückzusetzen speichert immer noch dieselben Beweise
Die verlockende Überarbeitung ist, die Zeit zurückzukaufen: eine Person verlangen, den Diff verkleinern, einen weiteren Genehmiger hinzufügen. Für manche Änderungen ist das der richtige Ansatz. Es ist auch die Überarbeitung, die die Kontrolldefinition unberührt lässt. Du sammelst immer noch einen Screenshot einer Genehmigung. Du hast immer noch nicht schriftlich festgehalten, was diese Genehmigung bescheinigen darf.
Verbleibende Prüfzeit, wenn du sie bekommst, geht an Fragen, die die Codeprüfung bereits kennt. Ist der Hotfix korrekt? Ist er sicher? Das sind echte Fragen. Aber sie sind nicht die Frage: 'Hat diese Änderung gerade die Regel gelöscht, dass ein Billing-PR einen Domain-Owner benötigt?' Ein Prüfer, der Rechnungsmathematik betrachtet, wird die CODEOWNERS-Änderung als Rauschen genehmigen.
Die Art der Änderung
Betrachte dies als illustrierend: die Art von Änderung, die die Frage aufwirft, nicht ein Kunden-Vorfall. Der Hotfix im Rest des PR kann sauber sein. Diese Zeile ist die Change-Management-Regel, die falsch wird.
# domain owners/infra/ @platform-owners-/billing/ @billing-owners+# /billing/ @billing-owners # unblocking the invoice hotfix/docs/ @docs-ownersKein Bug und keine Schwachstelle. CC8.1 betrifft Change Management: Änderungen müssen autorisiert, geprüft und über den von dir festgelegten Prozess genehmigt werden. Diese Zeile war die unabhängige Prüfung für Billing. Sie auszukommentieren bedeutet, dass der nächste Billing-PR mit einer generischen Genehmigung gemergt werden kann. Der Screenshot wird weiterhin existieren. Die schriftliche Regel, dass Billing-Änderungen einen Domain-Owner benötigen, wird nicht mehr existieren.
Überarbeite die Kontrolle, nicht nur die Personenzahl
Ayoubs Issue ist eine Warnung, den PR-Ritus nicht nur deshalb stärker zu verteidigen, weil der Screenshot immer noch offiziell aussieht. Wir stimmen zu. Das zusätzliche Problem ist, dass die Überarbeitung, die die meisten Teams in diesem Quartal ausliefern, immer noch diesen Screenshot verlangt und die Regel, die die Prüfung definiert, in einem PR gelöscht werden kann, den niemand als Kontrolländerung gelesen hat.
Wenn du Change Management für die Geschwindigkeit von Agenten überarbeitest, schreibe auf, was 'geprüft' bescheinigen darf, und behandle Änderungen an dieser Definition als im Geltungsbereich derselben Kontrolle. Ein CODEOWNERS-Pfad, eine erforderliche Prüfung, eine CODEOWNERS-Ausnahme, ein Überspringen im Branch-Schutz: Das sind die Kontrolle. Sie sind keine Nebenkommentare in einem Hotfix.
Wo heygrc steht
heygrc ist nicht der Newsletter, der Workshop oder ein Ersatz für die bereits laufenden Bug- und Sicherheitsreviews. Es ist die Ebene, die jeden Pull Request anhand der von dir ausgewählten Frameworks und des von dir bereitgestellten Kontexts liest. Wenn eine Änderung eine Change-Management- oder Review-Pfad-Regel schwer verteidigbar machen würde, sagt heygrc das im Diff. Es mergt nichts. Es stellt die Frage im Pull Request, bevor das Audit einen Screenshot als Stichprobe zieht, der nicht mehr das bedeutet, was die Kontrolle vorgibt.
Lies Ayoubs Issue. Der Verfall des Screenshots ist sein Thema. Die zusätzliche Frage ist, was passiert, wenn du die Kontrolle überarbeitest und immer noch nur den Screenshot sammelst.