In het afgelopen decennium is veel beveiligingswerk van de jaarlijkse planning verdwenen. De penetratietest is niet verdwenen, maar het dagelijkse werk is naar links verschoven: naar de editor, de pull request, de CI-pipeline, waar een probleem goedkoop op te lossen is omdat de persoon die het heeft veroorzaakt er nog naar kijkt. Het pas aan het einde ontdekken begon er duur uit te zien.
Het meeste compliance-werk heeft die verschuiving niet meegemaakt. Voor de meeste teams is het nog steeds gekoppeld aan de audit: een review die lang na de feiten plaatsvindt, tegen een venster dat al gesloten is, waarbij een afgedwaalde controle pas dan opduikt, als die al opduikt. De wijziging die de afwijking veroorzaakte, is al in een pull request gemerged die niemand voor compliance heeft beoordeeld. heygrc bestaat om die beoordeling te verplaatsen naar waar beveiliging al is: de diff.
De audit is een achterlopende indicator
Een audit vertelt je wat waar was over een periode die al voorbij is. Dat is nuttig, maar door de aard ervan komt het te laat. Tegen de tijd dat een afgedwaalde controle opduikt, is de wijziging die het veroorzaakte al weken of maanden eerder gemerged, is het bewijs voor de tussentijd al verdwenen, en is wat een opmerking van één regel had kunnen zijn, nu een uitzondering om te documenteren en een herstelactie om in te plannen.
De kosten van een compliance-leemte groeien met de afstand tussen de wijziging die het veroorzaakte en het moment waarop iemand het opmerkt. Een jaarlijkse frequentie vergroot die afstand per ontwerp.
Compliance drijft af, één commit tegelijk
Controles breken zelden in één zichtbaar incident. Ze slijten door individueel redelijke wijzigingen: een bewaartermijn verlengd, een logregel ingekort, een opslagregio gewijzigd, een standaardinstelling versoepeld om een partner te ontblokkeren. Elke wijziging is op zich verdedigbaar, en geen ervan meldt zich als een compliance-wijziging. Wat later opduikt, is de opgetelde staat, niet de context van de individuele wijziging die de controle verplaatste.
Als de afwijking één commit tegelijk gebeurt, is de enige plek om het goedkoop op te vangen de commit zelf. Overal later en je moet reconstructeren, aan de hand van logs en geheugen, welke wijziging de controle verplaatste en wanneer.
Een voorspellende indicator bij de diff
Compliance naar links verschuiven betekent dat elke pull request op het moment zelf wordt beoordeeld en dat de controle die een wijziging raakt, wordt benoemd, inclusief de clausule, terwijl de beslissing nog goedkoop te wijzigen is. Het is dezelfde stap die beveiliging heeft gezet: niet om de audit te vervangen, maar om te verminderen wat de audit moet vinden, door controle-relevante wijzigingen in de review op te vangen in plaats van ze te laten opstapelen tot uitzonderingen.
Dit is het doel, niet een gemeten resultaat, omdat we nog geen productie-telemetrie gebruiken: een voorspellende indicator voor dezelfde verplichtingen die de audit meet, op het moment waarop een bevinding een opmerking kost in plaats van een kwartaal. De jaarlijkse audit vindt nog steeds plaats. Die zou alleen minder moeten ontdekken.