Jak zespoły inżynierskie mogą wykrywać naruszenia zgodności podczas przeglądu kodu zamiast podczas audytu?
zespół heygrc
Audyt jest wskaźnikiem opóźnionym: sprawdza to, co zostało wdrożone miesiące temu, gdy naruszenie jest już w produkcji i generuje koszty. Przegląd kodu to wskaźnik wyprzedzający, ostatni moment, w którym naruszenie jest jednym kliknięciem od nieistnienia. Aby je tam złapać: wiedz, które z Twoich kontroli faktycznie dotyczą kodu, uczyn z pytania o zgodność część czytania każdego diffa, uzasadniaj każdą flagę konkretnym przepisem i zachowuj ślad, aby sam przegląd stał się dowodem audytowym.
Mapuj swoje kontrole na powierzchnie kodu
Większość kontroli ramowych dotyczy organizacji, ale spora mniejszość dotyczy kodu: rejestrowanie działań (ISO 27001 A.8.15, SOC 2 CC7.2), kontrola dostępu (CC6.1), kryptografia (A.8.24), minimalizacja danych (GDPR Art. 5(1)(c)) i ograniczenie przechowywania (Art. 5(1)(e)), kopie zapasowe oraz zmiany zależności. To kontrole, które dryfują z każdym commitem, dlatego sporządź ich listę raz i umieść ją tam, gdzie recenzenci ją zobaczą.
Zadawaj pytanie o zgodność przy każdym diffie
Poprawność i styl mają już swoje miejsce w przeglądzie; zgodność też powinna je mieć. Może to być lista kontrolna do przeglądu lub automatyczny recenzent, który sprawdza każdy pull request pod kątem Twoich ram. Automatyzacja jest tutaj ważna, ponieważ pytanie musi być zadawane za każdym razem, aby działało: to właśnie niesprawdzony diff powoduje, że naruszenie zostaje wdrożone. Neutralna sprawdzanie statusu zapobiega spowalnianiu merge’ów.
Uzasadniaj każdą flagę konkretnym przepisem
Flaga, która wskazuje, że ISO 27001 A.8.15 jest zagrożone, jest dyskusyjna, naprawialna i później możliwa do sprawdzenia; flaga, która mówi „bądź ostrożny z logami”, nie spełnia żadnego z tych warunków. Uzasadnienie sprawia też, że fałszywe alarmy są akceptowalne, ponieważ inżynier może zweryfikować twierdzenie na podstawie kontroli, zamiast zgadywać.
Zachowuj ślad
Odczyt zgodności dołączony do każdego pull requestu jest dowodem, że przegląd został przeprowadzony przy każdej zmianie, dokładnie taki ślad, jaki audytor sprawdza. Oznacza to również, że audyt przestaje być momentem odkrycia, ponieważ odkrycie już nastąpiło podczas przeglądu.
track("report.exported", {- email: user.email,+ userId: user.id, reportId: report.id,})Zdarzenie zachowuje swoją wartość analityczną dzięki wewnętrznemu identyfikatorowi zamiast adresu e-mail. Wykryte podczas przeglądu, to jedna linijka do naprawy; znalezione podczas audytu, to miesiące eksportowanych zdarzeń do naprawy.
Powiązane