Większość zespołów, które poważnie traktują pull requesty, już teraz korzysta z jednego lub dwóch recenzentów dla każdej zmiany. Narzędzie do wykrywania błędów, takie jak Cursor Bugbot lub CodeRabbit, czyta diff i sprawdza, czy kod jest poprawny. Agent bezpieczeństwa analizuje go i pyta, czy kod jest bezpieczny: czy nie ma iniekcji, złamanego sprawdzenia dostępu lub wyciekniętego sekretu. Obie odpowiedzi dotyczą realnych pytań, a poważna zmiana zasługuje na obie.
Jest jednak trzecie pytanie, na które rzadko wyznacza się odpowiedzialnego podczas przeglądu kodu: czy ta zmiana nadal spełnia wymogi ram compliance, na podstawie których 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 GDPR, i czy dowody pozostają ważne po wdrożeniu. To inne pytanie niż poprawność czy bezpieczeństwo, i to właśnie na nie został zaprojektowany heygrc. Uzupełnia on pozostałe dwa, zamiast je zastępować.
Poprawne, bezpieczne, a jednak ustalenie
Trzy pytania są niezależne. Zmiana może być błędem, ale nie luką. Może być luką, ale nie problemem zgodności. I może być czystym, działającym kodem, który mimo to wpływa na kontrolę, która zostanie poddana audytowi. Ten ostatni przypadek rzadko ma recenzenta w pokoju.
Oto rodzaj zmiany, o której mowa. Traktuj ją jako ilustracyjną: jedna linia czystego kodu, która kompiluje się i działa, i nie jest ani błędem, ani luką w diff.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}Gałąź to czysty, działający kod: zwraca decyzję i nic w nim nie jest błędem ani luką. Ale podejmuje wyłącznie zautomatyzowaną decyzję dotyczącą osoby, odmawiając jej zwrotu, bez możliwości recenzji przez człowieka. Tam, gdzie taka decyzja wywołuje skutek prawny lub równie istotny, GDPR Art. 22 daje osobie prawo do niepodlegania jej oraz prawo do uzyskania interwencji człowieka. To, co ta zmiana naprawdę wprowadziła, to pytanie dotyczące zgodności do rozwiązania, a nie wada do naprawy.
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, i to jest ich siłą. Ich reguły są uniwersalne: use-after-free to zawsze use-after-free w każdym repozytorium, niezparametryzowane zapytanie to zawsze injection wszędzie. Dzięki uniwersalnym regułom te narzędzia działają od razu.
Compliance działa odwrotnie. Czy zmiana jest ustaleniem, zależy od tego, do jakich frameworków jesteś zobowiązany, jakie kontrole zapisałeś i na czym opierała się Twoja ostatnia audyt. Ten sam diff, który dla jednej firmy nic nie znaczy, dla innej jest luką dowodową SOC 2 CC7.2. To nie jest coś, co może zrobić reguła „ślepa” na framework, ponieważ problem nie leży w kodzie. Leży w Twoich zobowiązaniach i musi być odczytywany w ich kontekście.
Nakładaj soczewki, nie wybieraj między nimi
Wniosek nie brzmi 'dodaj kolejne narzędzie'. Chodzi o to, że pull request jest najpełniej analizowany przez trzy soczewki, a nie jedną: czy jest poprawny, czy jest bezpieczny, czy wciąż spełnia nasze ramy. Zachowaj swój sprawdzacz błędów. Zachowaj swojego agenta bezpieczeństwa. Są dobre w swoich zadaniach, a heygrc nie próbuje na nie odpowiadać. heygrc dodaje trzecią soczewkę i raportuje ją w jedyny sposób, w jaki ustalenie dotyczące zgodności ma jakąkolwiek wartość, cytując dokładną kontrolę, której dotyczy.
Przytoczony przykład jest ilustracyjny, rodzaj zmiany, która podnosi trzecie pytanie, a nie konkretny incydent. Ale istota sprawy jest kluczowa: zmiany, które wpływają na Twoją postawę zgodności, zwykle nie są błędne ani niebezpieczne. To czyste, poprawnie wyglądające zmiany, które cicho dotykają kontroli, co jest inną rzeczą do poszukiwania niż błąd lub luka.