heyGRC Docs

Używaj z recenzentem kodu

Jak heyGRC działa obok Cursor Bugbot, CodeRabbit, Copilot code review, Aevral lub dowolnego innego recenzenta.

heyGRC to recenzent zgodności, a nie recenzent kodu. Analizuje każdy pull request pod kątem frameworków wybranych przez Twoją firmę (ISO 27001, SOC 2, RODO i dziesiątki innych) oraz kontekstu firmy, a gdy zmiana dotyczy kontroli, publikuje identyfikator kontroli, uzasadnienie oraz status sprawdzenia.

Oznacza to, że został zaprojektowany do działania obok tego, co obecnie recenzuje Twój kod: Cursor Bugbot, CodeRabbit, GitHub Copilot code review, recenzent bezpieczeństwa, recenzenci ludzcy. Ten sam pull request, inne pytanie. heyGRC nie ocenia, co te narzędzia wykrywają lub przeoczają; po prostu odpowiada na inne pytanie.

Trzy perspektywy jednego pull requesta

PerspektywaNarzędzieGłówne pytanie
Błędy i jakość koduCursor Bugbot, CodeRabbit, Copilot code reviewCzy kod jest poprawny?
BezpieczeństwoAevralCzy występuje podatność na exploity związane z autoryzacją, IDOR lub błąd logiki biznesowej?
ZgodnośćheyGRCKtórej kontroli dotyczy ta zmiana?

heyGRC cytuje kontrolę; Aevral szuka exploita. Aevral to recenzent bezpieczeństwa stworzony przez ten sam zespół co heyGRC: analizuje pull requesty pod kątem autoryzacji, IDOR oraz błędów kontroli dostępu w logice biznesowej. Recenzenci błędów mogą również zgłaszać problemy związane z bezpieczeństwem; tabela przedstawia główne pytanie każdego narzędzia, a nie pełny zakres jego działania. Aplikacje instaluje się oddzielnie i żadna nie zależy od drugiej.

Jak recenzje współistnieją w PR

  • Każda aplikacja publikuje własną recenzję i własny check. heyGRC publikuje jedną skonsolidowaną recenzję na przebieg (znaleziska inline zebrane w jedną recenzję), plus neutralny status Checks.
  • Żadne narzędzie nie musi wiedzieć o istnieniu drugiego. Nie ma integracji do skonfigurowania ani wymogu dotyczącego kolejności.
  • Znaleziska są kierowane różnie: poprawki kodu są wprowadzane w diff; ustalenia dotyczące zgodności czasami wykraczają poza niego (aktualizacja polityki, zebranie dowodów). Traktuj ustalenia heyGRC jako własną, małą kolejkę.

Utrzymywanie niskiej łącznej liczby zgłoszeń

Ustaw częstotliwość działania heyGRC w konsoli (na poziomie organizacji lub z nadpisaniem na repozytorium); zobacz Konfiguracja z agentem, krok 4:

TrybZachowanie
autoRecenzuje każdy PR przy otwarciu, ponownym otwarciu lub wypchnięciu zmian.
auto_onceRecenzuje tylko przy otwarciu/ponownym otwarciu, nie przy każdym commicie.
mention_onlyDziała w trybie cichym, dopóki ktoś nie skomentuje /heygrc w PR.

Zespoły, które już korzystają z bota do recenzji kodu, zazwyczaj zaczynają od auto_once lub mention_only, a następnie zaostrzają ustawienia, gdy sygnał zyska zaufanie.

Blokowanie vs informowanie

Domyślnie check heyGRC jest neutralny: informuje, a decyzja o scaleniu pozostaje w rękach zespołu. Aby uczynić go blokującym, oznacz check heyGRC jako wymagany w ochronie gałęzi GitHub, dokładnie tak jak każde zadanie CI.

Konfiguracja

Zainstaluj z github.com/apps/heygrc, następnie skonfiguruj frameworki i kontekst firmy za pomocą jednego wywołania API; najszybsza ścieżka to Konfiguracja z agentem.

On this page