W zespole, który korzysta z agentów programistycznych, to one otwierają większość pull requestów, które są wdrażane, i często dobrze radzą sobie z widocznym zadaniem: funkcjonalność działa, testy przechodzą, zależności są aktualne. Agent może nie mieć powodu, aby brać pod uwagę, czy wprowadzona zmiana wpłynęła na kontrolę, pod kątem której Twoja firma jest audytowana, ponieważ ten obowiązek wynika z przyjętych ram i kontekstu firmy, a nie z diffa, który agent miał wygenerować. Ta luka to właśnie cel kontroli zgodności dla kodu generowanego przez AI.
Istniejące zestawienia narzędzi do kontroli zgodności kodu AI zwykle odnoszą się do jednego z trzech zagadnień: statyczna analiza błędów, skanowanie zależności i licencji lub wykrywanie tajemnic. To ważne i warto je stosować. Żadne z nich nie jest jednak zaprojektowane do porównywania zmian z ramami takimi jak SOC 2, ISO 27001 czy GDPR na poziomie konkretnej kontroli, co jest innym pytaniem zadawanym temu samemu pull requestowi.
Co oznacza zgodność na poziomie kontroli
Zgodność dla kodu generowanego przez AI nie polega na sprawdzaniu nagłówków licencji ani ocenie wyników skanowania luk. Chodzi o pytanie, czy wprowadzona zmiana dotknęła kontroli, którą jesteś zobowiązany utrzymywać: granicy logicznego dostępu, rekordu dziennika audytu, minimalnego poziomu szyfrowania, limitu retencji. Te obowiązki są zdefiniowane w przyjętych przez Twoją firmę ramach, na poziomie, który można zweryfikować, np. ISO 27001:2022 A.8.15 dla logowania lub GDPR Art. 5(1)(c) dla minimalizacji danych.
Powodem, dla którego jest to odrębna analiza, jest to, że zmiana istotna dla kontroli zwykle jest poprawnym kodem. Zazwyczaj kompiluje się, jest bezpieczna, odpowiednio licencjonowana i robi to, o co poproszono agenta. Problem nie leży w samej zmianie, ale w tym, że cicho modyfikuje ona coś, co audytor może później zbadać. Narzędzie, które szuka jedynie błędów, nie jest zaprojektowane do sygnalizowania takich przypadków.
Przykład praktyczny: agent wzbogaca profil o dane, których nie potrzebuje
Załóżmy, że agent został poproszony o dodanie odznaki lojalnościowej na stronie konta. Aby obliczyć poziom, dodaje pamięć podręczną user_profile i wypełnia ją danymi z usługi tożsamości. Najprostszy sposób, a zarazem taki, na który mógłby się zdecydować agent optymalizujący zadanie, to skopiowanie całego rekordu tożsamości do nowego magazynu: data urodzenia, numer identyfikacyjny, adres zamieszkania i telefon, obok poziomu oraz nazwy wyświetlanej, których odznaka faktycznie używa.
Migracja przebiega sprawnie, a funkcjonalność działa od pierwszego podejścia. Nowy magazyn zawiera jednak cztery kategorie danych osobowych, których odznaka lojalnościowa nie potrzebuje. To naruszenie zasady minimalizacji danych, GDPR Art. 5(1)(c): dane osobowe muszą być odpowiednie, istotne i ograniczone do tego, co niezbędne do realizacji celu. Rozwiązanie to jedna linijka intencji: wypełnienie pamięci podręcznej jedynie poziomem i nazwą wyświetlaną. Najłatwiej jest to zrobić w pull request, który wprowadził magazyn, gdy autor wciąż ma kontekst. Jeśli nie zostanie to naprawione, nowy magazyn będzie zawierał niepotrzebne dane osobowe, które zostaną odkryte dopiero po kilku miesiącach.
Dlaczego skanery błędów, luk i licencji nie wychwytują takich przypadków
Powyższa zmiana nie jest typem problemu, który te skanery są zaprojektowane do wykrywania: kod jest poprawny, więc skaner błędów ją akceptuje; nie pojawiła się nowa zależność, więc skaner licencji ją akceptuje; a skaner luk nie jest zaprojektowany do interpretowania poszerzonego zakresu danych osobowych jako znaleziska. Zatem narzędzia te działają zgodnie z przeznaczeniem, akceptując taką zmianę, ponieważ istotna dla kontroli zmiana, która w innych aspektach jest poprawna, nie jest tym, co mają wykrywać. To nie jest krytyka tych narzędzi: wykrywanie błędów, luk i nieprawidłowości licencyjnych jest naprawdę wartościowe, a wyjście agenta wymaga wszystkich tych sprawdzeń.
Oznacza to jednak, że analiza zgodności to odrębna warstwa, a nie wzmocniona wersja tego samego skanowania. Porównuje ona diff z przyjętymi ramami i identyfikuje kontrolę, której dotyczy zmiana, co jest informacją, której inne narzędzia nie są w stanie dostarczyć. Rozsądne podejście to uruchamianie obu: skanerów jakości kodu i bezpieczeństwa w celu wykrywania błędów oraz kontroli zgodności w celu wykrywania dryfu kontroli, na tym samym pull request.
Zmiana, która sprawia, że to staje się pilne
Dwie rzeczy ulegają zmianie, gdy agenci piszą dużą część kodu. Skala: agent otwiera więcej pull requestów, niż ludzka kontrola zgodności jest w stanie nadążyć, więc albo staje się ona wąskim gardłem, albo zostaje pominięta. Charakter awarii: agent optymalizuje pod kątem widocznego zadania, więc kod kontroli, który postrzegany jest jako opór (np. linijka logu, sprawdzenie uprawnień, limit retencji), to dokładnie rodzaj rzeczy, którą diff może skrócić lub poszerzyć, nie zwracając na to uwagi.
Niezależnie od tego, kto wprowadził zmianę, audytor nadal ocenia, czy kontrola działała, więc kod napisany przez AI podlega tym samym wymaganiom co kod napisany przez człowieka. To, co musi ulec zmianie, to fakt, że analiza zgodności musi teraz działać w tempie maszynowym, aby nadążyć, co oznacza zautomatyzowanie pierwszego etapu i zarezerwowanie ludzkiej oceny dla przypadków z flagami.
Jak dodać kontrolę
Kontrola zgodności dla kodu generowanego przez AI działa na pull request w taki sam sposób jak inne kontrole: uruchamia się, gdy PR jest otwierany lub aktualizowany, porównuje diff z wybranymi ramami i kontekstem firmy, a następnie publikuje kontrole, których dotyczy zmiana, z dołączonym klauzulą, jako komentarz oraz neutralny status. Gdy agent otwiera PR, kontrola spotyka się z kodem tam, gdzie agent go już umieścił, bez dodatkowych kroków dla osoby, która musi go zaakceptować.
heygrc jest zaprojektowany jako taka kontrola w postaci aplikacji GitHub: zainstaluj ją, skonfiguruj swoje ramy i kontekst raz (pojedyncze wywołanie REST, które Twój agent programistyczny może wykonać za Ciebie), a następnie będzie ona recenzować każdy pull request pod kątem wpływu na zgodność i cytować kontrolę w diff. Publikuje neutralny status Checks oraz komentarze w linii, aby informować, a nie blokować, chyba że zdecydujesz się go wymagać. Używaj go obok skanerów błędów i bezpieczeństwa, a nie zamiast nich.