Compliance as code is het idee dat een compliance-verplichting moet worden uitgedrukt en gecontroleerd waar het systeem daadwerkelijk leeft: in de repository en de pipeline, in plaats van alleen in een beleidsdocument dat een auditor één keer per jaar beoordeelt. Het neemt de aanpak over die werkte voor testen en infrastructuur: neem iets dat voorheen handmatig en periodiek was, en maak het gedefinieerd en continu.
De drie dingen die het echt vereist
Ten eerste moet de verplichting worden benaderd op een niveau dat controleerbaar is. "Verbeter onze beveiligingshouding" is niet controleerbaar; "een wijziging in een bevoorrechte rol moet worden geregistreerd, volgens ISO 27001:2022 A.8.15" wel. Ten tweede moet de controle worden uitgevoerd waar wijzigingen plaatsvinden, op de pull request, niet in een apart hulpmiddel dat niemand opent. Ten derde, als het iets signaleert, moet het aangeven welke maatregel en waarom, zodat de engineer kan handelen zonder een compliance-expert te worden.
De meeste teams hebben de eerste twee ingrediënten al: de eerste in hun frameworks en de tweede in hun CI. Wat meestal ontbreekt, is de vertaallaag die een concrete codewijziging koppelt aan de specifieke maatregel die het raakt.
Waarom de diff de juiste eenheid is
Een maatregel degradeert niet volgens een schema. Het degradeert op het moment dat iemand een rol uitbreidt, een encryptie-instelling verlaagt of een logregel verwijdert. Elk van die acties is een diff. Als je compliance controleert op de diff, vang je de degradatie op het moment dat deze wordt geïntroduceerd, terwijl de auteur nog de context heeft om het goedkoop op te lossen.
Dit is dezelfde reden waarom tests bij elke wijziging worden uitgevoerd in plaats van één keer per kwartaal: de kosten van een regressie nemen toe met de tijd tussen het moment van introductie en het moment van ontdekking.
Waar heygrc past
heygrc is gebouwd om die vertaallaag te zijn: om elke pull request te lezen tegen de frameworks die je bedrijf heeft geselecteerd en de specifieke maatregel te benoemen die een wijziging raakt, als een review-opmerking met de clausule erbij. Het is niet bedoeld om je framework, je auditor of je engineeringoordeel te vervangen; het doel is om de maatregel zichtbaar te maken op de diff, zodat de beslissing geïnformeerd is.