Wyszukując SOC 2 w pull requestach, znajdziesz głównie listy kontrolne procesów: wymagaj recenzji, sprawdzeń statusu i podpisanych commitów. Te ustawienia mają znaczenie. Są dowodem na istnienie procesu zarządzania zmianami. CC8.1 (wspólne kryteria zarządzania zmianami) dotyczy również tego, czy kontrola działała dla danej zmiany: czy została zatwierdzona zgodnie z polityką, czy też hotfix, bot lub ścieżka awaryjna pominęły wymagany krok.
Ten przewodnik skupia się na poziomie pojedynczego PR. Nie wyjaśnia ponownie różnic między Type I a Type II (zob. /guides/how-to-pass-soc-2-as-a-startup) ani nie mapuje całej rodziny CC6 dotyczącej dostępu (zob. /guides/what-soc-2-actually-checks-in-your-repo). Koncentruje się na zarządzaniu zmianami w momencie scalania pull requesta.
Ochrona gałęzi jest konieczna, ale niewystarczająca
Wymaganie jednej recenzji zatwierdzającej i zielonego sprawdzenia CI to zwykle podstawa. Audytorzy sprawdzają, czy ten proces działał w okresie obserwacyjnym. Repozytorium z włączoną ochroną wciąż może generować wyjątki, gdy ktoś scali z uprawnieniami administratora, gdy ścieżka wdrożeniowa omija chronioną gałąź lub gdy konto automatyzacji scali bez ludzkiej zgody, którą polityka uznaje za wymaganą.
Ślady w kodzie nie zawsze znajdują się w źródłach aplikacji. Często są w plikach workflow, CODEOWNERS, skryptach wdrożeniowych lub jednowierszowej zmianie dotyczącej uprawnień do zatwierdzania. Te zmiany wciąż trafiają jako pull requesty.
Przykład praktyczny: ścieżka awaryjna, która pomija wymagane zatwierdzenie
Dyżurny otrzymuje powiadomienie. Inżynier otwiera pull request, który dodaje zadanie workflow_dispatch z continue-on-error i ścieżką wdrażającą produkcję z osobistego forka przy użyciu długoterminowego tokena, udokumentowaną jako "break-glass". Tego samego dnia drugi PR zmienia CODEOWNERS, aby ta ścieżka nie wymagała już zespołu platformowego. Oba PR wyglądają na higienę operacyjną. Kod aplikacji może w ogóle się nie zmienić.
Dla CC8.1 istotne jest, czy zmiany w produkcji wciąż przechodzą przez autoryzowany proces zmian. Ścieżka awaryjna, która trwale osłabia wymagane zatwierdzenia, to zmiana kontroli, a nie tylko udogodnienie. Podczas okna Type II, jeśli audytor pobierze próbki wdrożeń, które używały tej ścieżki bez udokumentowanej zgody, będziesz musiał wyjaśnić wyjątek. Wychwycenie diffów workflow i CODEOWNERS podczas recenzji jest tańsze niż wyjaśnianie ich sześć miesięcy później.
Jak to wiąże się z oknem obserwacyjnym (bez powtarzania zasad audytu)
W przypadku Type II audytor sprawdza, czy kontrole działały w danym okresie. Pojedyncze pominięte zatwierdzenie w tym oknie może stać się wyjątkiem w próbce, nawet jeśli reszta roku była czysta. Dlatego higiena zarządzania zmianami podczas okna obserwacyjnego nie jest biurokracją dla samej siebie; to sposób, aby unikać niespodzianek w opinii, na którą spędziłeś miesiące przygotowań. Szczegóły gotowości, zakresu i wyboru audytora znajdują się w przewodniku SOC 2 dla startupów.
Sprawdzenie zgodności pull requesta, które powołuje się na CC8.1 przy osłabionym punkcie zatwierdzania, nie zatwierdza awaryjnej zmiany. Sprawia, że zmiana procesu staje się widoczna, zanim PR zostanie zamknięty.
Rola heygrc i granice odpowiedzialności
heygrc został zaprojektowany, aby analizować pull requesty w oparciu o wybrane frameworki, w tym SOC 2 (jeśli jest włączony), i identyfikować kryteria takie jak CC8.1, gdy zmiana wydaje się osłabiać zarządzanie zmianami (punkty zatwierdzania, wymagane sprawdzenia, autoryzacja wdrożenia). Nie przeprowadza audytu, nie zbiera dowodów z IdP ani HR ani nie wydaje opinii.
Zachowaj recenzenta jakości kodu. CC8.1 dotyczy integralności procesu w przypadku zmiany, a nie tego, czy hotfix był elegancki.