Każda istotna praktyka inżynierska ostatecznie zyskuje swoją nazwę. Ta to przegląd zgodności dla pull requestów: sprawdzanie każdej zmiany pod kątem ram zgodności, których firma musi przestrzegać, oraz identyfikowanie konkretnej kontroli, której dotyczy, na poziomie diffa, zanim zostanie zmergowany. heygrc to nasz produkt w tej kategorii, ale kategoria jest szersza niż jakikolwiek produkt i zasługuje na własne uzasadnienie.
Kategorie się rozdzielają, a przegląd kodu dzieli się teraz
Praktyki nie łączą się w jedno narzędzie, które robi wszystko; rozdzielają się na specjalistów. Przegląd kodu już się raz podzielił: przegląd poprawności (czy ta zmiana działa) i przegląd bezpieczeństwa (czy ta zmiana jest bezpieczna) to różne pytania, na które odpowiadają różni recenzenci z różną wiedzą, w tym samym pull requeście. Nikt nie oczekuje, że linter znajdzie ataki wstrzykiwania, a nikt nie oczekuje, że skaner bezpieczeństwa wykryje błąd off-by-one.
Zgodność to trzecia perspektywa. Czy zmiana wpływa na kontrolę, której dotyczy audyt, to nie pytanie o poprawność ani o bezpieczeństwo: zmiana może być poprawna, bezpieczna, a jednocześnie poszerzać ścieżkę dostępu, którą SOC 2 CC6.1 uwzględnia, lub skracać log, którego istnienie przewiduje ISO 27001:2022 A.8.15. To inne pytanie, inna wiedza, ten sam diff. Kiedy pytanie jest zadawane wystarczająco często na własnych zasadach, staje się kategorią.
Dlaczego kategoria powstała teraz, a nie pięć lat temu
Dwie krzywe się przecięły. Pierwsza: wsparcie AI zwiększa ilość kodu, jaką zespoły produkują, a uwaga człowieka na zmianę nie nadąża za tym wzrostem. Zespoły korzystające z agentów merge’ują więcej zmian, szybciej, z mniejszym zaangażowaniem człowieka na linię kodu niż zakładała dotychczasowa praktyka.
Druga: powierzchnia zgodności tych samych baz kodu rośnie. Więcej firm dąży do SOC 2 i ISO 27001 wcześniej; do GDPR dołączyły DORA, NIS 2 i EU AI Act; a zobowiązania coraz częściej znajdują się w kodzie, w granicach retencji, ścieżkach dostępu, logach i zachowaniu modeli. Więcej zmian, mniej uwagi człowieka, więcej zobowiązań na zmianę: przegląd zgodności wymaga automatyzacji na poziomie diffa, jeśli ma być wykonywany spójnie.
Czym jest kategoria i czym nie jest
Recenzent zgodności dla pull requestów sprawdza zmianę pod kątem ram wybranych przez firmę i uzasadnia każde znalezisko konkretną kontrolą, którą dotyczy, na poziomie, który można zweryfikować lub zakwestionować. Działa tam, gdzie już odbywa się przegląd kodu, i informuje, a nie blokuje: znaleziska to komentarze do przeglądu i status sprawdzenia, a nie zablokowane merge.
To nie jest platforma GRC (nie prowadzi programu zgodności ani nie zbiera dowodów), to nie jest audyt (to wskaźnik wyprzedzający dla tych samych zobowiązań, które mierzy audyt), i to nie jest certyfikacja (przegląd to odczyt, a nie odznaka). Te narzędzia zachowują swoje role. Ta kategoria istnieje dla jednej roli, której żadne z nich nie pełni: pytania o zgodność, zadawanego dla każdego diffa, gdy zmiana jest jeszcze tania do naprawy.