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
| Perspektywa | Narzędzie | Główne pytanie |
|---|---|---|
| Błędy i jakość kodu | Cursor Bugbot, CodeRabbit, Copilot code review | Czy kod jest poprawny? |
| Bezpieczeństwo | Aevral | Czy występuje podatność na exploity związane z autoryzacją, IDOR lub błąd logiki biznesowej? |
| Zgodność | heyGRC | Któ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:
| Tryb | Zachowanie |
|---|---|
auto | Recenzuje każdy PR przy otwarciu, ponownym otwarciu lub wypchnięciu zmian. |
auto_once | Recenzuje tylko przy otwarciu/ponownym otwarciu, nie przy każdym commicie. |
mention_only | Dział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.
EU inference
Optional org setting that sends heyGRC compliance reviews to Mistral on the EU regional endpoint, with no silent fallback to the default global path.
Czy heyGRC blokuje mergowanie?
heyGRC domyślnie nie blokuje mergowania. Jak reguły rozwiązywania konwersacji w GitHub mogą wymagać rozwiązania wątków inline.