Zarządzanie zmianami w potoku.
CC8.1 to kryterium SOC 2 dotyczące zarządzania zmianami: zmiany w infrastrukturze, danych i oprogramowaniu powinny być autoryzowane, zaprojektowane, opracowane, przetestowane i zatwierdzone przed wdrożeniem. Wiele z tych procesów odbywa się w potoku CI/CD i ochronie gałęzi, co oznacza, że pull request może cicho usunąć same kontrole, które regulują, jak zmiany są wdrażane.
The shapes the same control failure takes.
CC8.1 słabnie, gdy zmiana osłabia proces, który ma ją regulować. Powtarzające się wzorce:
Usunięto wymagane zatwierdzenie
Wymagana recenzja lub zatwierdzenie przed wdrożeniem produkcyjnym zostaje usunięte z konfiguracji CI lub ochrony gałęzi, dzięki czemu zmiany mogą trafić do produkcji bez akceptacji.
Migracja pomija recenzję
Migracja bazy danych lub zmiana danych jest skonfigurowana do uruchomienia podczas wdrożenia bez oddzielnej recenzji lub zatwierdzenia zmiany, która modyfikuje dane produkcyjne.
Testy przestają blokować merge
Wymagana sprawdzanie statusu (np. zestaw testów, skan bezpieczeństwa) zostaje ustawione jako nieblokujące lub usunięte, dzięki czemu niezweryfikowane zmiany mogą zostać scalone.
Dodano ścieżkę omijającą
Dodano awaryjną lub administracyjną ścieżkę, która pozwala na wdrożenie zmiany do produkcji poza normalnym potokiem, bez równoważnych kontroli.
Usunięto cofnięcie
Bezpieczna ścieżka cofnięcia lub migracji w dół zostaje usunięta, dzięki czemu zmiana może zostać wdrożona bez możliwości czystego wycofania w przypadku problemów.
Wymagane zatwierdzenie wdrożenia, usunięte.
Wymagane ręczne zatwierdzenie przed wdrożeniami produkcyjnymi spowalniało wydania, więc zmiana usuwa regułę ochrony. Wdrożenia stają się szybsze, a teraz każde scalenie do głównej gałęzi trafia do produkcji bez akceptacji zmiany.
jobs: deploy:- environment:- name: production # requires a reviewer approval steps:Usunięcie wymaganego zatwierdzenia dla środowiska produkcyjnego oznacza, że zmiany trafiają do produkcji bez akceptacji. CC8.1 wymaga, aby zmiany były autoryzowane i zatwierdzone przed wdrożeniem. Jeśli zatwierdzenia są zbyt wolne, zawęź krąg osób lub elementów, które ich wymagają, lub zautomatyzuj sprawdzanie, ale zachowaj krok zatwierdzenia zamiast go usuwać.
Zarządzanie zmianami jest weryfikowane na podstawie rzeczywistych zmian.
Auditor sprawdza próbkę zmian, które trafiły do produkcji, i szuka dowodów na to, że każda z nich została zrecenzowana, przetestowana i zatwierdzona, zwykle na podstawie pull request, jego zatwierdzeń i zaliczonych sprawdzeń. Zmiana, która usunęła wymagane zatwierdzenie lub uczyniła test nieblokującym, to luka za tymi dowodami, i jest widoczna w diffie konfiguracji potoku lub ochrony gałęzi.
Recenzja, nie Twój proces wydania.
heygrc sygnalizuje zmiany, które dotyczą CC8.1, i cytuje kryterium, aby naprawa nastąpiła w pull request. Nie uruchamia wdrożeń ani nie zarządza ochroną gałęzi. Wychwytuje moment, w którym zmiana osłabia proces regulujący zmiany, na poziomie diffu.