"Compliance-Bot für GitHub" ist eine Suchanfrage, die Nutzer eingeben, wenn sie etwas suchen, das in ihren Repositories sitzt und Compliance-Probleme markiert, ohne dass sie eine separate GRC-Konsole öffnen müssen. Die Ergebnisse sind eine unübersichtliche Mischung aus Tools, die das Wort "Compliance" teilen, aber kaum etwas anderes: Bots, die Statuskommentare posten, Tools, die GitHubs eigene Compliance-Berichte herunterladen, Beweismittel-Sammler, die prüfen, ob Branch-Protection aktiviert ist, und Chat-Apps, die nichts mit Code-Reviews zu tun haben. Dieser Leitfaden benennt die Produktform, die die eigentliche Absicht erfüllt: ein Bot, der jeden Pull Request gegen die ausgewählten Frameworks prüft und eine Kontrolle am Diff zitiert.
Dies ist bewusst nicht dieselbe Seite wie der Hauptleitfaden zu Compliance-Prüfungen in Pull Requests. Dieser Leitfaden erklärt, was eine Compliance-Prüfung ist (das Konzept: Beratungsstatus, Kontrollzitat, Branch-Protection-Option). Dieser hier erklärt, was ein Compliance-Bot als Produkt ist (die installierbare Komponente, die Ereignisschleife, die Berechtigungen und was es nicht ist).
Vier Dinge, die Leute mit "Compliance-Bot" meinen (nur eines ist das Produkt)
Erstens: ein Chat- oder Ticket-Bot, der Richtlinienfragen in Slack beantwortet. Nützlich für Personen, nicht für Pull Requests. Zweitens: ein Berichtsconnector, der GitHub-Audit- oder Compliance-Berichte für einen Prüfer exportiert. Das ist Beweismittel-Export, keine Prüfung einer Änderung. Drittens: ein Beweismittel-Sammler oder eine GRC-Plattform, die prüft, ob die erforderlichen Repository-Einstellungen (Branch-Protection, erforderliche Reviews, signierte Commits) konfiguriert sind. Das ist Prozessbeweis für die Programmebene. Viertens: eine GitHub-App, die bei jedem Pull-Request-Ereignis den Diff gegen benannte Framework-Kontrollen prüft und eine Review sowie optional einen Check-Status postet. Nur das vierte ist ein frameworkbasierter Compliance-Bot für Pull Requests.
Wenn deine Suchergebnisse voller der ersten drei Varianten sind, liegst du mit dem Bedarf nicht falsch. Die Kategoriebezeichnung für das vierte ist noch neu: Compliance-Prüfung für Pull Requests. Ein Bot ist nur die Art und Weise, wie diese Prüfung auf GitHub bereitgestellt wird.
Was der Bot bei einem echten Pull Request tut
Nach der Installation verbindet sich der Bot mit den von dir ausgewählten Repositories. Wenn ein Pull Request geöffnet, aktualisiert oder erneut geöffnet wird (abhängig vom von dir konfigurierten Ausführungsmodus), liest er die Änderung, vergleicht sie mit den von deiner Organisation ausgewählten Frameworks und postet, falls eine Kontrolle betroffen ist, einen Review-Kommentar, der die Klausel nennt (z. B. SOC 2 CC6.1 bei einer erweiterten IAM-Rolle oder GDPR Art. 5(1)(c) bei einem Log, das einen vollständigen Identitätsdatensatz erfasst). Er kann auch einen GitHub Check mit einem neutralen Status posten, sodass das Ergebnis sichtbar ist, ohne standardmäßig den Merge zu blockieren.
Die sinnvolle Standardeinstellung für einen Compliance-Bot ist beratend: die Kontrolle anzeigen und die Merge-Entscheidung deiner Branch-Protection-Richtlinie überlassen. Ein Bot, der jede Feststellung hart blockiert, führt dazu, dass Nutzer ihn stummschalten. Ein Bot, der nie im Review-Thread erscheint, wird ignoriert. Neutraler Status plus ein klares Zitat ist das Design, das das Signal beibehält, ohne zur Inszenierung zu werden.
Was es nicht ist (damit du nicht das falsche Produkt kaufst)
Es ist nicht dein Prüfer, deine SOC 2-Stellungnahme oder ein Zertifikat. Es ist keine GRC-Plattform, die Beweismittel über Identität, HR und Cloud für den gesamten Beobachtungszeitraum sammelt. Es ist kein Secret-Scanner, SAST-Tool oder Dependency-Advisor, auch wenn diese Tools oft denselben Pull-Request-Thread nutzen und weiterlaufen sollten. Es ist kein Ersatz für Bugbot, CodeRabbit oder einen Code-Qualitäts-Reviewer: Diese prüfen, ob der Code korrekt und sicher ist; der Compliance-Bot prüft, ob die Änderung eine Kontrolle betrifft, die du bewertet bekommst.
Wenn du Automatisierung von Beweismitteln auf Programmebene benötigst, kaufe oder behalte eine GRC-Plattform. Wenn du Schwachstellenfindungen benötigst, behalte deine Sicherheits-Scanner. Die Aufgabe des Compliance-Bots ist die dritte Frage im selben Pull Request: Berührt dieser Diff eine Kontrolle, und wenn ja, welche?
Wie heygrc diese Form umsetzt
heygrc ist eine GitHub-App, die Compliance-Prüfungen für Pull Requests durchführt: Installiere sie in den Repositories, die dir wichtig sind, wähle Frameworks aus, und sie postet kontrollzitierte Feststellungen am Diff. Öffentliche Repositories sind kostenlos; private Repositories beginnen mit einem kostenlosen monatlichen Kontingent und einer kurzen unbegrenzten Testphase, wenn du die Installation in der Konsole beanspruchst. Standardmäßig blockiert sie keine Merges. Du kannst den Check in der Branch-Protection selbst erfordern, falls deine Richtlinie eine Sperre benötigt.
Ein lebendes Beispiel findest du im öffentlichen Demo-Repository, wo vorbereitete Pull Requests echte Reviews gegen SOC 2-, ISO 27001- und GDPR-Kontrollen an sauberem synthetischem Code zeigen. Für das Konzept der Prüfung selbst lies den Hauptleitfaden. Für die Einrichtung lies die anwendungsorientierte Installationsanleitung.