Compliance as Code ist die Idee, dass eine Compliance-Verpflichtung dort ausgedrückt und geprüft werden sollte, wo das System tatsächlich existiert – im Repository und in der Pipeline – und nicht nur in einem Richtliniendokument, das ein Prüfer einmal im Jahr stichprobenartig überprüft. Es übernimmt den Ansatz, der sich bei Tests und Infrastruktur bewährt hat: Etwas, das früher manuell und periodisch war, wird definiert und kontinuierlich gemacht.
Die drei Dinge, die tatsächlich erforderlich sind
Erstens muss die Verpflichtung in einer Granularität benannt werden, die überprüfbar ist. "Verbessern Sie unsere Sicherheitslage" ist nicht überprüfbar; "eine Änderung einer privilegierten Rolle muss protokolliert werden, gemäß ISO 27001:2022 A.8.15" schon. Zweitens muss die Prüfung dort durchgeführt werden, wo Änderungen stattfinden, also im Pull Request, und nicht in einem separaten Tool, das niemand öffnet. Drittens muss sie, wenn sie etwas markiert, angeben, welche Kontrolle betroffen ist und warum, damit der Entwickler handeln kann, ohne zum Compliance-Experten zu werden.
Die meisten Teams haben die ersten beiden Zutaten bereits in ihren Frameworks und ihrer CI. Was normalerweise fehlt, ist die Übersetzungsschicht, die eine konkrete Codeänderung mit der spezifischen Kontrolle verbindet, die sie betrifft.
Warum der Diff die richtige Einheit ist
Eine Kontrolle verschlechtert sich nicht nach einem Zeitplan. Sie verschlechtert sich in dem Moment, in dem jemand eine Rolle erweitert, eine Verschlüsselungseinstellung herabsetzt oder eine Protokollzeile entfernt. Jede dieser Änderungen ist ein Diff. Wenn Sie die Compliance im Diff prüfen, erkennen Sie die Verschlechterung im Moment ihrer Einführung, während der Autor noch den Kontext hat, um sie kostengünstig zu beheben.
Das ist der gleiche Grund, warum Tests bei jeder Änderung und nicht einmal pro Quartal ausgeführt werden: Die Kosten einer Regression steigen mit der Zeit zwischen Einführung und Entdeckung.
Wo heygrc ins Spiel kommt
heygrc ist so konzipiert, dass es diese Übersetzungsschicht darstellt: Es liest jeden Pull Request gegen die von Ihrem Unternehmen ausgewählten Frameworks und benennt die spezifische Kontrolle, die eine Änderung betrifft, als Review-Kommentar mit der angehängten Klausel. Es soll Ihr Framework, Ihren Prüfer oder Ihr technisches Urteilsvermögen nicht ersetzen; das Ziel ist es, die Kontrolle im Diff sichtbar zu machen, damit die Entscheidung fundiert getroffen werden kann.