Zusammen mit deinem Code-Reviewer verwenden

Wie heyGRC neben Cursor Bugbot, CodeRabbit, Copilot Code Review, Aevral 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 dem Unternehmenskontext. 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 Sicherheits-Reviewer oder menschliche Reviewer. Derselbe Pull Request, eine andere Frage. heyGRC macht keine Aussagen darüber, was diese Tools melden oder übersehen; es beantwortet einfach eine andere Frage.

Drei Perspektiven auf einen Pull Request

Perspektive	Tool	Hauptfrage
Fehler und Code-Qualität	Cursor Bugbot, CodeRabbit, Copilot Code Review	Ist der Code korrekt?
Sicherheit	Aevral	Gibt es eine ausnutzbare Autorisierungslücke, IDOR oder einen Fehler in der Geschäftslogik?
Compliance	heyGRC	Welche Kontrolle wird durch diese Änderung berührt?

heyGRC zitiert die Kontrolle; Aevral sucht nach der Sicherheitslücke. Aevral ist ein Sicherheits-Reviewer, der vom selben Team wie heyGRC entwickelt wurde: Es prüft Pull Requests auf Autorisierungslücken, IDOR und Fehler in der Geschäftslogik bei der Zugriffskontrolle. Bug-Reviewer können ebenfalls Sicherheitsbefunde melden; die Tabelle zeigt die Hauptfrage jedes Tools, nicht dessen vollständige Abdeckung. Die Apps werden separat installiert und sind voneinander unabhängig.

Wie die Reviews in einem PR koexistieren

Jede App postet ihre eigene Review und ihren eigenen Check. heyGRC postet eine konsolidierte Review pro Durchgang (Inline-Befunde werden in einer einzigen Review gebündelt), plus einen neutralen Checks-Status.
Kein Tool muss wissen, dass das andere existiert. Es gibt keine Integration, die konfiguriert werden muss, und keine Reihenfolgeanforderung.
Befunde werden unterschiedlich weitergeleitet: Code-Befunde werden im Diff behoben; Compliance-Befunde gehen manchmal darüber hinaus (eine Richtlinie, die aktualisiert werden muss, Nachweise, die erfasst werden müssen). Behandle die Befunde von heyGRC 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.

Blockieren vs. Informieren

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.