Compliance należy do pull request.
Nazywamy tę praktykę compliance review dla pull requestów: sprawdzanie każdej zmiany pod kątem frameworków, które Twoja firma musi spełnić, na etapie diff, a nie miesiące później podczas audytu. Te eseje to argumenty stojące za tą kategorią. Krótkie, subiektywne i napisane dla osób, które rzeczywiście zmieniają system: inżynierów i inżynierów bezpieczeństwa.
- 00
Przegląd zgodności dla pull requestów.
Przegląd kodu dzieli się na perspektywy: poprawność, bezpieczeństwo, a teraz zgodność. Ten esej określa trzecią perspektywę jako kategorię i wyjaśnia, dlaczego powstała właśnie teraz.
- 01
Złap to w PR, a nie w audycie.
Luka w zgodności jest najtańsza do naprawy w momencie jej powstania, a najdroższa w dniu, w którym znajdzie ją auditor.
- 02
Compliance to sprawdzenie CI, a nie ćwiczenia przeciwpożarowe co kwartał.
Traktowanie compliance jak wydarzenia, które przeżywa się dwa razy do roku, sprawia, że wygląda to jak ćwiczenia przeciwpożarowe. Traktuj je jak sprawdzenie, które uruchamia się przy każdej zmianie, a stanie się nudne – a to jest celem.
- 03
Twój linter jest ślepy na frameworki.
Lintery i skanery wykrywają defekty i klasy podatności. Zmiana może być idealnym kodem, a mimo to naruszać obowiązek compliance, ponieważ obowiązek nie jest właściwością kodu, lecz właściwością frameworka.
- 04
Kontrole istnieją w diffach, nie w dokumentach Word.
Kontrola zapisana w dokumencie polityki to zamiar. Kontrola jest realna dopiero tam, gdzie działający system ją egzekwuje, a działający system zmienia się za każdym razem o jeden diff.
- 05
Audyt to wskaźnik opóźniony.
Audyt informuje, co było prawdą kilka miesięcy temu. Jeśli to jedyny sygnał, jaki posiadasz, sterujesz systemem, patrząc w lusterko wsteczne.