Zusammen mit deinem Code-Reviewer verwenden
Wie heyGRC neben Cursor Bugbot, CodeRabbit, Copilot Code Review oder jedem anderen Reviewer läuft.
heyGRC ist ein Compliance-Reviewer, kein Code-Reviewer. Es prüft jeden Pull Request anhand der von deinem Unternehmen ausgewählten Frameworks (ISO 27001, SOC 2, DSGVO und Dutzende mehr) sowie des Unternehmenskontexts. Wenn eine Änderung eine Kontrolle betrifft, postet es die Kontroll-ID, die Begründung und einen Prüfstatus.
Das bedeutet, dass es dafür konzipiert ist, neben dem zu laufen, was heute deinen Code prüft: Cursor Bugbot, CodeRabbit, GitHub Copilot Code Review, ein Sicherheitsscanner oder menschliche Reviewer. Derselbe Pull Request, eine andere Frage. heyGRC macht keine Aussagen darüber, was diese Tools erkennen oder übersehen; es beantwortet einfach eine andere Frage.
Wie die beiden Reviews in einem PR koexistieren
- Jede App postet ihr eigenes Review und ihren eigenen Check. heyGRC postet ein konsolidiertes Review pro Durchlauf (Inline-Funde in einem einzigen Review gebündelt) sowie einen neutralen Checks-Status.
- Kein Tool muss wissen, dass das andere existiert. Es gibt keine Integration, die konfiguriert werden muss, und keine Reihenfolgeanforderung.
- Funde werden unterschiedlich behandelt: Code-Funde werden im Diff behoben; Compliance-Funde gehen manchmal darüber hinaus (eine Richtlinie, die aktualisiert werden muss, Nachweise, die erfasst werden müssen). Behandle heyGRCs Funde als eigene kleine Warteschlange.
Das kombinierte Volumen gering halten
Lege den Rhythmus von heyGRC in der Konsole fest (pro Organisation oder überschreibe pro Repository); siehe Einrichten mit deinem Agenten, Schritt 4:
| Modus | Verhalten |
|---|---|
auto | Prüft jeden PR, wenn er geöffnet, wieder geöffnet oder gepusht wird. |
auto_once | Prüft nur bei Öffnen/Wiederöffnen, nicht bei jedem Commit. |
mention_only | Bleibt stumm, bis jemand /heygrc im PR kommentiert. |
Teams, die bereits einen Code-Review-Bot verwenden, starten meist mit auto_once oder mention_only
und verschärfen die Einstellungen, sobald das Signal Vertrauen gewonnen hat.
Blockierend vs. informierend
Standardmäßig ist der heyGRC-Check neutral: Er informiert, und die Merge-Entscheidung bleibt bei deinem Team. Um ihn blockierend zu machen, markiere den heyGRC-Check als erforderlich in den GitHub-Branch-Schutzregeln, genau wie jeden CI-Job.
Einrichtung
Installiere es von github.com/apps/heygrc, dann konfiguriere Frameworks und Unternehmenskontext mit einem API-Aufruf; der schnellste Weg ist Einrichten mit deinem Agenten.
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.
Blockiert heyGRC Merges?
heyGRC blockiert Merges standardmäßig nicht. Wie GitHub-Regeln zur Gesprächsauflösung dennoch die Behebung von Inline-Findings erfordern können.