Większość zespołów, które poważnie podchodzą do pull requestów, już teraz korzysta z jednego lub dwóch recenzentów dla każdej zmiany. Narzędzie do sprawdzania błędów, takie jak Cursor Bugbot lub CodeRabbit, analizuje diff i pyta, czy kod jest poprawny. Agent bezpieczeństwa sprawdza, czy kod jest bezpieczny: czy nie ma wstrzyknięcia, złamanego sprawdzenia dostępu lub wyciekniętego sekretu. Obie odpowiedzi dotyczą realnych pytań, a poważna zmiana zasługuje na obie.
Istnieje trzecie pytanie, któremu rzadko przypisuje się właściciela podczas przeglądu kodu: czy ta zmiana wciąż spełnia ramy compliance, na podstawie których Twoja firma jest audytowana? Nie chodzi o to, czy to błąd, ani czy to luka, ale czy dotyczy kontroli w SOC 2, ISO 27001 lub RODO, i czy dowody pozostają prawdziwe po wdrożeniu. To inne pytanie niż poprawność czy bezpieczeństwo, i właśnie do tego został stworzony heygrc. Uzupełnia ono pozostałe dwa, a nie zastępuje żadnego z nich.
Poprawny, bezpieczny, a mimo to ustalenie
Te trzy pytania są od siebie niezależne. Zmiana może być błędem, ale nie luką. Może być luką, ale nie problemem compliance. Może też być czystym, działającym kodem, który wciąż wpływa na kontrolę, której dotyczy audyt. Ten ostatni przypadek to ten, któremu rzadko przypisuje się recenzenta w zespole.
Oto rodzaj zmiany, o której mowa. Traktuj ją jako ilustrację: jedna linijka czystego kodu, która kompiluje się i działa, i nie jest ani błędem, ani luką w diffie.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}Ta gałąź to czysty, działający kod: zwraca decyzję, a nic w niej nie jest błędem ani luką. Ale podejmuje wyłącznie zautomatyzowaną decyzję dotyczącą osoby, odmawiając zwrotu, bez możliwości weryfikacji przez człowieka. Tam, gdzie taka decyzja powoduje skutki prawne lub równie istotne, RODO Art. 22 przyznaje osobie prawo do niepodlegania jej oraz prawo do uzyskania interwencji człowieka. To, co ta zmiana naprawdę wprowadza, to pytanie dotyczące compliance, które należy rozstrzygnąć, a nie wadę do naprawienia.
Dlaczego trzecie pytanie nie ma właściciela
Narzędzie do sprawdzania błędów i agent bezpieczeństwa mogą być celowo „ślepe” na ramy compliance, i to jest ich zaletą. Ich reguły są uniwersalne: użycie po zwolnieniu to użycie po zwolnieniu w każdym repozytorium, nieparametryzowane zapytanie to wstrzyknięcie wszędzie. Uniwersalne reguły to powód, dla którego te narzędzia działają od razu.
Compliance jest przeciwieństwem. Czy zmiana jest ustaleniem, zależy od tego, jakie ramy Cię obowiązują, jakie kontrole zdefiniowałeś i na czym opierał się Twój ostatni audyt. Ten sam diff, który dla jednej firmy nie ma znaczenia, dla innej stanowi lukę w dowodach SOC 2 CC7.2. To nie jest coś, z czym reguła „ślepa” na ramy może poradzić sobie samodzielnie, ponieważ problem nie dotyczy samej treści kodu. Dotyczy Twoich zobowiązań i musi być odczytywany w ich kontekście.
Połącz perspektywy, nie wybieraj między nimi
Wniosek nie brzmi: „dodaj kolejne narzędzie”. Chodzi o to, że pull request jest najpełniej analizowany przez trzy perspektywy, a nie jedną: czy jest poprawny, czy jest bezpieczny, czy wciąż spełnia nasze ramy. Zachowaj swoje narzędzie do sprawdzania błędów. Zachowaj swojego agenta bezpieczeństwa. Są dobre w swoich dziedzinach, a heygrc nie próbuje na nie odpowiadać. heygrc dodaje trzecią perspektywę i raportuje ją w jedyny sposób, w jaki ustalenie dotyczące compliance ma jakąkolwiek wartość: poprzez wskazanie dokładnej kontroli, której dotyczy.
Przytoczony przykład jest ilustracyjny, to rodzaj zmiany, która podnosi trzecie pytanie, a nie konkretny incydent. Ale właśnie o to chodzi: zmiany, które wpływają na Twoją postawę compliance, zwykle nie są błędne ani niebezpieczne. To czysty, poprawnie wyglądający kod, który cicho dotyka kontroli, a to zupełnie inna rzecz, której należy szukać niż błędu lub luki.