Jak udowodnić zarządzanie zmianami z GitHub dla SOC 2 lub ISO 27001?
zespół heygrc
W większości tak, jeśli ustawienia są poprawne. Przepływ pracy z pull requestami rejestruje, co zostało zmienione (diff), kto to zrecenzował i zatwierdził, co uruchomiono przed merge (sprawdzenia) oraz kiedy nastąpił merge (commit merge). SOC 2 CC8.1 i ISO 27001 A.8.32 wymagają, aby zmiany były autoryzowane, testowane, zatwierdzone i śledzone, a dobrze prowadzone repozytorium dostarcza większości tych dowodów bez dodatkowych narzędzi. Czego nie dostajesz za darmo, to historia egzekwowania zasad (dowód, że zatwierdzeń nie można było pominąć) oraz mapowanie każdej zmiany do kontroli, której dotyczy. To musisz dodać.
Pozwól, by ochrona gałęzi przejęła część autoryzacji
Zarządzanie zmianami sprowadza się do dwóch pytań: czy każda zmiana była autoryzowana i czy można to udowodnić. Pull request pokazuje konkretny przypadek, a ochrona gałęzi pokazuje regułę. Wymagaj pull requestów z co najmniej jednym zatwierdzeniem (dwoma tam, gdzie ważna jest segregacja obowiązków), wymagaj sprawdzeń, którym ufasz, oraz recenzji od właścicieli kodu na istotnych ścieżkach. Auditor sprawdzający CC8.1 lub A.8.32 zapyta, jak wiesz, że niezrecenzowana zmiana nie może trafić do main: ustawienia ochrony gałęzi pokazują regułę taką, jaka obowiązuje dzisiaj, każde zatwierdzenie jest dowodem jej przestrzegania, a jeśli reguła została zmieniona w okresie audytu, dziennik audytu repozytorium (zmiany reguł i ochrony) to miejsce, w którym to udowodnisz.
Spraw, by każdy pull request stanowił zapis zmiany
Treść PR wyjaśnia dlaczego, diff pokazuje co, uruchomione sprawdzenia potwierdzają, że zostało przetestowane, zatwierdzenie oznacza, że druga osoba je zaakceptowała, a commit merge informuje, kiedy zmiana została scalona. Kiedy zmiana została faktycznie wdrożona, to już kwestia rekordu wdrożenia (release, środowisko, uruchomienie wdrożenia), które zarządzanie zmianami traktuje jako osobny krok, nie coś, czego dowodzi merge. Trzymaj pull requesty na tyle małe, by recenzja była rzeczywistą recenzją, dołącz link do zgłoszenia lub issue z uzasadnieniem biznesowym i nie pushuj bezpośrednio do chronionej gałęzi, nawet jeśli masz taką możliwość, ponieważ to omija recenzję, której wymagasz od innych. Czysta historia to nie fanaberia: to populacja, którą auditor próbkuje.
Wiedz, czego GitHub nie udowadnia
Trzy luki. Force-push może przepisać historię na referencjach, które nie są chronione, a administratorzy mogą ominąć niektóre ochrony, więc historia egzekwowania zasad ma słabe punkty; przedstaw je uczciwie, zamiast przesadzać. Retencja też ma ograniczenia: usunięcie repozytorium powoduje usunięcie rekordów pull requestów, a same logi GitHub (dziennik audytu organizacji, logi Actions) wygasają po ograniczonym, zależnym od planu okresie, więc wyeksportuj to, czego potrzebuje Twój okres audytu, zanim to zniknie. I nic w samym rekordzie pull requestu nie mapuje zmiany do ram: CC8.1 nie etykietuje diffa, a A.8.32 nie komentuje pull requestu. To mapowanie to coś, co dodaje recenzja zgodności dla każdego PR (heygrc publikuje znaleziska, które nazywają klauzulę), budując ścieżkę kontrola-zmiana w tym samym miejscu, w którym już istnieje zmiana.
# Domyślni recenzenci dla całego repozytorium* @acme/devs+ /security/ @acme/securityPrzy ochronie gałęzi wymagającej recenzji od właścicieli kodu, zmiany w /security/ są kierowane do zespołu bezpieczeństwa w celu zatwierdzenia. Chronić plik CODEOWNERS w ten sam sposób, w przeciwnym razie reguła może zostać osłabiona w zwykłym pull request. Autoryzacja dla ryzykownych ścieżek, zapisana w pliku, który auditor może przeczytać.
Powiązane