Compliance gehört in den Pull Request.
Wir nennen die Praxis Compliance Review für Pull Requests: Jede Änderung wird gegen die Frameworks geprüft, die dein Unternehmen erfüllen muss – direkt im Diff, nicht Monate später im Audit. Diese Essays sind die Argumente hinter dieser Kategorie. Kurz, meinungsstark und für die Menschen geschrieben, die das System tatsächlich verändern: Ingenieure und Sicherheitsingenieure.
- 00
Compliance-Prüfung für Pull Requests.
Code-Review teilt sich in Perspektiven auf: Korrektheit, Sicherheit und nun Compliance. Dieser Essay benennt die dritte Perspektive als Kategorie und erklärt, warum sie jetzt entsteht.
- 01
Erkennen Sie es im PR, nicht im Audit.
Eine Compliance-Lücke ist am günstigsten zu beheben, wenn sie geschrieben wird, und am teuersten, wenn ein Prüfer sie findet.
- 02
Compliance ist ein CI-Check, kein vierteljährlicher Feueralarm.
Compliance als Ereignis zu behandeln, das man zweimal im Jahr überlebt, ist der Grund, warum es sich wie ein Feueralarm anfühlt. Behandle es als Check, der bei jeder Änderung ausgeführt wird, und es wird langweilig – und das ist das Ziel.
- 03
Dein Linter ist framework-blind.
Linter und Scanner erkennen Fehler und Schwachstellenklassen. Eine Änderung kann fehlerfreier Code sein und trotzdem eine Compliance-Verpflichtung verletzen, denn die Verpflichtung ist keine Eigenschaft des Codes, sondern eine Eigenschaft des Frameworks.
- 04
Kontrollen leben in Diffs, nicht in Word-Dokumenten.
Eine in einem Richtliniendokument beschriebene Kontrolle ist eine Absicht. Die Kontrolle ist erst real, wo das laufende System sie durchsetzt, und das laufende System ändert sich mit jedem Diff.
- 05
Das Audit ist ein nachlaufender Indikator.
Ein Audit sagt Ihnen, was vor Monaten wahr war. Wenn das das einzige Signal ist, das Sie haben, steuern Sie ein System, indem Sie in den Rückspiegel schauen.