Wyszukując sprawdzenia zgodności w pull requestach, większość wyników dotyczy wymaganych sprawdzeń statusu GitHub: upewnienia się, że testy i linter zakończyły się sukcesem przed merge. To rzeczywiście przydatna funkcja, ale nie o to chodzi na tej stronie. Sprawdzenie zgodności to inne pytanie zadawane temu samemu pull request: czy ta zmiana dotyczy kontroli, na podstawie której Twoja firma jest audytowana, np. w SOC 2, ISO 27001, RODO lub innej ramie, której jesteś podległy.
To pytanie rzadko ma właściciela w procesie code review. Poprawność i bezpieczeństwo mają dobrze zdefiniowane sprawdzenia, ale czy zmiana wpłynęła na kontrolę, na podstawie której jesteś audytowany, to oddzielna analiza. I to właśnie dodaje sprawdzenie zgodności w pull request. Warto precyzyjnie określić, czym jest i czym nie jest to sprawdzenie.
Czym jest, a czym nie jest
Sprawdzenie zgodności analizuje diff, a nie wyniki testów. Mapuje rzeczywistą zmianę na konkretną kontrolę, której dotyczy, i raportuje tę kontrolę z nazwą, na poziomie, który można zweryfikować. Nie jest to ocena zdania/niezdania testów, nie jest to próg pokrycia kodu, ani nie jest to dokument polityki, który auditor sprawdza raz w roku. To analiza na poziomie pojedynczej zmiany, czy pull request przed Tobą wpłynął na coś, co jesteś zobowiązany zachować.
Przydatność sprawdzenia wynika z precyzyjnego odwołania. "To wygląda na niezgodne" to szum. "To usuwa log audytu dla uprzywilejowanej akcji, której ISO 27001:2022 A.8.15 wymaga zachowania" to coś, na co inżynier może zareagować lub podyskutować. Sprawdzenie zgodności, które nie może nazwać kontroli, nie warto dodawać.
Trzy zmiany wpływające na kontrole, które ukrywają się w rutynowych pull requestach
Poszerzony dostęp. Pull request rozszerza rolę IAM lub otwiera nową ścieżkę do zasobu. Kod jest poprawny i może być całkowicie bezpieczny, ale powiększa grupę osób, które mogą uzyskać dostęp do chronionych danych, co jest dokładnie tym, czego dotyczy SOC 2 CC6.1 (kontrole dostępu logicznego). Może wyglądać jak rutynowa zmiana konfiguracji, podczas gdy kontrola, której dotyczy, pozostaje nienazwana.
Osłabiony log audytu. Czyszczenie usuwa lub skraca linię logu, która akurat była zapisem uprzywilejowanej akcji. Nic nie przestaje działać, a może wyglądać jak nieszkodliwe sprzątanie, ale dowód, który auditor sprawdza na podstawie ISO 27001:2022 A.8.15 (logowanie), teraz zniknął. Zmiana, która to spowodowała, jest najtańszym miejscem, aby to złapać.
Nowe przechowywanie danych osobowych bez ograniczeń. Migracja dodaje tabelę, która zaczyna zbierać dane osobowe bez limitu retencji. To czysty, działający kod, który cicho stawia Cię po niewłaściwej stronie RODO Art. 5(1)(e) (ograniczenie przechowywania), który wymaga, aby dane osobowe były przechowywane nie dłużej niż to konieczne. Żadna z tych trzech zmian nie jest błędem ani luką. Każda z nich to zmiana wpływająca na kontrolę, ukryta w rutynowym pull request.
Doradczy domyślnie, blokujący tylko jeśli zdecydujesz
Sprawdzenie zgodności, które blokuje każdy merge przy każdym znalezisku, uczy ludzi, aby je ignorować. Z kolei takie, które nigdy niczego nie blokuje, zostanie zignorowane. Przydatnym domyślnym ustawieniem jest tryb doradczy: sprawdzenie publikuje kontrolę i klauzulę jako komentarz oraz neutralny status, dzięki czemu znalezisko jest widoczne, ale nie przerywa merge. Decyzja o blokowaniu należy do polityki ochrony gałęzi, a nie do narzędzia.
Jeśli pominięcie kontroli jest naprawdę kosztowne, np. w przypadku zmian dotyczących kontroli dostępu, kryptografii lub danych osobowych, możesz wymagać sprawdzenia poprzez ochronę gałęzi w repozytoriach lub chronionych gałęziach, gdzie ma to największe znaczenie, i pozostawić je w trybie doradczym w pozostałych miejscach. Mechanizm powinien pozwalać na wybór postawy, a nie narzucać ją we wszystkim.
Jak dodać jedno
Sprawdzenie zgodności działa na pull request tak samo jak inne sprawdzenia: uruchamia się, gdy PR jest otwierany lub aktualizowany, analizuje diff w oparciu o wybrane ramy i kontekst firmy, a następnie publikuje kontrole, których dotyczy zmiana, wraz z dołączoną klauzulą. Trudne nie jest zauważenie, że coś się zmieniło, ale precyzyjne określenie, która kontrola została zmieniona, i to poprawnie. Dlatego ramy, których jesteś podległy, oraz Twój własny kontekst muszą zasilać sprawdzenie.
heygrc został zaprojektowany jako takie sprawdzenie w formie aplikacji GitHub: zainstaluj go, poinformuj o swoich ramach i kontekście raz, a następnie będzie recenzować każdy pull request pod kątem wpływu na zgodność, publikując neutralny status Checks oraz komentarze w linii, aby informować, a nie blokować, chyba że zdecydujesz, że ma być wymagany. Przewodnik konfiguracji obejmuje trzy minutowe wdrożenie.