Compliance hoort thuis in de pull request.
We noemen de praktijk compliance review voor pull requests: elke wijziging toetsen aan de frameworks die je bedrijf moet naleven, bij de diff, niet maanden later in een audit. Deze essays zijn de argumenten achter die categorie. Kort, uitgesproken en geschreven voor de mensen die het systeem daadwerkelijk veranderen: engineers en security engineers.
- 00
Compliance-review voor pull requests.
Code review splitst zich in lenzen: correctheid, beveiliging en nu compliance. Dit essay benoemt de derde lens als categorie en legt uit waarom deze nu bestaat.
- 01
Vang het bij de PR, niet bij de audit.
Een compliance-leemte is het goedkoopst om op te lossen op het moment dat deze wordt geschreven, en het duurst op de dag dat een auditor deze vindt.
- 02
Compliance is een CI-check, geen kwartaalbrandweeroefening.
Compliance als een gebeurtenis behandelen die je twee keer per jaar overleeft, is de reden waarom het als een brandweeroefening voelt. Behandel het als een check die bij elke wijziging wordt uitgevoerd, en het wordt saai, wat juist het doel is.
- 03
Jouw linter is framework-blind.
Linters en scanners detecteren defecten en kwetsbaarheidsklassen. Een wijziging kan perfecte code zijn en toch een compliance-verplichting schenden, omdat de verplichting geen eigenschap van de code is, maar van het framework.
- 04
Controls leven in diffs, niet in Word-documenten.
Een control beschreven in een beleidsdocument is een intentie. De control is pas echt waar het draaiende systeem deze afdwingt, en het draaiende systeem verandert één diff tegelijk.
- 05
De audit is een achterlopende indicator.
Een audit vertelt je wat maanden geleden waar was. Als dat de enige signalen zijn die je hebt, bestuur je een systeem door in de achteruitkijkspiegel te kijken.