Kierownik twierdzi, że recenzja kodu to przeszłość. Jego zespół się z tym nie zgadza. Ktoś zadaje pytanie, które faktycznie rozstrzyga sprawę: jeśli podlegasz SOC 2, jak scalasz zmiany bez zatwierdzenia przez człowieka? Praktyk ds. zgodności odpowiada słusznie, że ramy nie określają, w jaki sposób ma nastąpić zatwierdzenie, tylko że należy przestrzegać udokumentowanego procesu. Ta odpowiedź jest poprawna, a to właśnie tam zaczyna się najciekawsza część, ponieważ proces, który zespół musiałby opisać, jest węższy i bardziej specyficzny, niż zakłada którakolwiek ze stron sporu.
Narzędzia dostępne do tego celu są realne i dostępne już dzisiaj: Greptile, GitHub Copilot code review, Claude Code – każde z nich recenzuje pull requesty na bieżąco. Więc przydatne pytanie nie brzmi: czy AI może zatwierdzać zmiany? Ale: czego tak naprawdę wymaga SOC 2 od tego zatwierdzenia i co sygnalizuje recenzja kodu, a czego zatwierdzenie zgodności nadal musi ustalić samodzielnie.
Czego tak naprawdę wymaga CC8.1
Zarządzanie zmianami w SOC 2 reguluje jedno kryterium: CC8.1. W prostych słowach wymaga, aby zmiana była autoryzowana, zbudowana, skonfigurowana, udokumentowana, przetestowana, zatwierdzona i zaimplementowana zgodnie z zdefiniowanym procesem, tak aby zmiany trafiały do produkcji celowo, a nie przypadkowo. Określa etapy, przez które powinna przejść zmiana, i oczekuje, że zmiany faktycznie je przechodzą.
Słowo, które niesie cały ciężar argumentacji, to 'zatwierdzona'. Kryterium określa etap. Nie określa jednak, kto lub co ma go wykonać. Kryteria SOC 2 są sformułowane w oparciu o zasady i neutralność technologiczną: to ty definiujesz kontrolę, która spełnia kryterium, a auditor testuje kontrolę, którą zdefiniowałeś, tak jak została zapisana, w danym okresie. Nic w CC8.1 nie mówi, że zatwierdzający musi być człowiekiem. Polityka, która autoryzuje automatyczne zatwierdzenie dla zdefiniowanej klasy zmian, może spełnić to kryterium, jeśli kontrola jest zdefiniowana, udokumentowana, działa zgodnie z opisem, a auditor ją zaakceptuje.
To nie jest hipoteza. Zespoły już teraz przepisują polityki zarządzania zmianami, aby niskoryzykowne zmiany mogły być zatwierdzane automatycznie, zastrzegając zatwierdzenie przez człowieka dla zmian powyżej zdefiniowanego poziomu ryzyka. To jest uzasadnione stanowisko w zakresie CC8.1, jeśli można je udokumentować. To polityka, która jest stosowana i testowana, a nie jej brak.
Trzy rzeczy, które 'AI to zatwierdziło' pomija
Po pierwsze, podział obowiązków. Zatwierdzenie ma wartość tylko wtedy, gdy zatwierdzający jest niezależny od autora. To najstarsze oczekiwanie w zarządzaniu zmianami: osoba, która wprowadziła zmianę, nie jest jedyną, która ją zatwierdza, aby żaden pojedynczy aktor nie mógł wprowadzać do produkcji czegokolwiek. 'AI to zatwierdziło' wprost napotyka ten problem. Jeśli ten sam agent tworzy diff i zatwierdza go, albo dwa automaty robią to bez niezależnej weryfikacji między nimi, to autor i zatwierdzający zostają zjednoczeni. To jest ta część, na którą auditor zwróci uwagę, a nie słowo 'AI'.
Po drugie, polityka musi to wyraźnie określać. Auditor nie testuje twoich intencji, tylko udokumentowany proces w odniesieniu do tego, co się wydarzyło. 'Bot recenzujący był zadowolony' nie jest kontrolą, chyba że twoja polityka zarządzania zmianami definiuje tego recenzenta: czym jest, które zmiany może zatwierdzać, co sprawdza i kiedy wciąż wymagany jest człowiek. Bez tego automatyczne zatwierdzenie nie jest kontrolą działającą zgodnie z projektem. To po prostu scalenie z dołączonym komentarzem bota.
Po trzecie, ślad dowodowy jest taki sam w obu przypadkach. To, co auditor próbkuje, nie zmienia się, ponieważ zatwierdził to bot: chcą zobaczyć, że zmiana została autoryzowana, przetestowana, kto lub co ją zatwierdził i że wszystko to jest powiązane ze zmianą i zarejestrowane. Automatyczne zatwierdzenie spełnia CC8.1, jeśli generuje taki ślad dla każdej zmiany, której dotyczy. Jeśli nie pozostawia zapisu, to nie zastąpiło kontroli, tylko ją pominęło.
Szczegół techniczny, którego wątek pomija: komentarz to nie zatwierdzenie
Pod spodem filozofii kryje się szczegół techniczny, który decyduje więcej niż sama filozofia. W modelu samego GitHuba AI recenzent pozostawiający informację zwrotną i AI recenzent rzucający zatwierdzającą akcję to dwie różne rzeczy, a narzędzia, które ludzie wymieniają, nie wszystkie robią to drugie.
GitHub Copilot code review, ogólnie dostępny od 2025 roku, publikuje swoją informację zwrotną jako recenzję w formie komentarza – z założeń projektowych. Zgodnie z opisem samego GitHuba nie liczy się to do wymaganych zatwierdzeń i nie blokuje ani nie zezwala na scalenie. Więc 'niech Copilot zatwierdzi' nie jest, mechanicznie rzecz biorąc, czymś, co Copilot robi: wymagany człowiek lub reguła automatycznego scalania, którą skonfigurowałeś, wciąż rzuca zatwierdzającą akcję. Działanie Claude Code w pull requestach czyta zmiany i, w zależności od tego, jak je skonfigurowałeś, publikuje informację zwrotną jako komentarze lub jako formalne zdarzenie recenzji, więc to, co przesyła, i czy może zaspokoić regułę ochrony gałęzi, to coś, co konfigurujesz i weryfikujesz. Greptile czyta każdy pull request pod kątem błędów i jakości, korzystając z kontekstu całej bazy kodu, i sygnalizuje problemy w zmianie.
Więc 'AI może zatwierdzać' to decyzja konfiguracyjna równie mocno, co polityczna. Które narzędzie rzuca jaki sygnał, co ten sygnał może blokować, i gdzie ląduje jego zapis, to rzeczy, które ustawiasz celowo w regułach repozytorium i ochrony gałęzi, a nie coś, co wynika z tweeta. Ustaw je świadomie, ponieważ ta konfiguracja to kontrola, którą auditor faktycznie przetestuje.
Zielona recenzja to nie recenzja zgodności
Nawet gdy mechanika jest poprawna, wątek cicho zakłada, że pewne trudniejsze pytanie nie istnieje. Każde z tych narzędzi zostało zaprojektowane, aby odpowiedzieć na pytania, które zawsze zadawała recenzja kodu: czy to jest poprawne i czy jest bezpieczne. To są dobre pytania do zadawania przy diffie i dobre do automatyzacji. Czy zmiana wciąż spełnia ramy, pod którymi jesteś audytowany, to zupełnie inne pytanie.
To drugie pytanie zależy od tego, jakie kontrole zdefiniowałeś i na czym opierał się twój ostatni audyt, i nie jest to cecha kodu, którą recenzent błędów odczytuje z diffa. Zmiana może być poprawna, bezpieczna, przejść wszystkie automatyczne sprawdzenia, a mimo to wpłynąć na kontrolę, która zostanie poddana próbkowaniu. Oto jak to wygląda.
export const auditLog = {- retentionDays: 365,+ retentionDays: 30, // trim storage cost}Czyste, poprawne i tańsze: nic tutaj nie jest błędem ani luką. SOC 2 nie określa liczby dni retencji, ale twoja własna kontrola dotycząca logowania i monitorowania to robi, i zależy od istnienia tych logów przez czas, na jaki zobowiązałeś się je przechowywać. Jeśli twoja kontrola lub dowody audytu zakładają dłuższy okres, zdarzenia starsze niż nowy nie mogą być już sprawdzane, a audyt, który próbkuje ten okres, stwierdzi, że logi już go nie obejmują. Ustal okres retencji na podstawie tego, czego wymagają twoja kontrola i dowody, a nie tylko rachunku za przechowywanie.
Gdzie mieści się heygrc
Ta zmiana retencji jest czysta i poprawna pod względem własnych założeń, co dokładnie wyjaśnia, dlaczego pytanie o zgodność może pozostać otwarte, nawet jeśli wszystkie sygnały recenzji kodu dla niej są zielone. Więc gdy polityka mówi, że zmiana została 'zatwierdzona środkami automatycznymi', uczciwe pytanie uzupełniające brzmi: zatwierdzona jako poprawna, czy zatwierdzona jako zgodna? To są dwa różne zatwierdzenia, a w tym wątku na stole było tylko jedno z nich.
heygrc zostało zaprojektowane do drugiego. Analizuje każdy pull request pod kątem ram, które musisz spełnić, i precyzyjnie wskazuje, którą konkretną kontrolę dotyczy zmiana, na poziomie diffa, niezależnie od tego, czy wprowadził ją człowiek, czy agent. Nie próbuje być sprawdzaczem błędów: zachowaj Greptile, Copilot lub Claude Code do sprawdzania poprawności i bezpieczeństwa, do ról, do których zostały zaprojektowane, i użyj heygrc do oddzielnej oceny zgodności, raportowanej w jedyny sposób, w jaki znalezisko dotyczące zgodności ma jakąkolwiek wartość: poprzez powołanie się na klauzulę.
Jeśli zamierzasz pozwolić na automatyczne zatwierdzanie scalenia niskoryzykownych zmian zgodnie z CC8.1, to jest to rozsądny kierunek. Automatyczna ocena zgodności to brakujące sprawdzenie, które pomaga określić, które zmiany są naprawdę niskoryzykowne. Przytoczone tutaj przykłady są ilustracyjne, rodzaju zmian, które podnoszą pytanie, a nie telemetrii, którą twierdzimy. Ale sam punkt pozostaje ważny: SOC 2 nigdy nie wymagał, aby człowiek zatwierdzał twoje pull requesty. Wymagał, aby ktoś lub coś zatwierdzało je na piśmie, niezależnie, zgodnie z procesem, który został udokumentowany. Zadowolenie recenzenta kodu nie jest tym samym, co uruchomienie tego procesu.