Compliance im Code Review finden.
Praktische Guides im Entwickler-Register: was jedes Framework im Repo prüft, wie man typische Issues im Review fängt und wie man es in die bestehende Pipeline einhängt.
- Primer
Compliance as Code: Eine praktische Einführung
Was es bedeutet, Compliance wie den Rest Ihrer Ingenieursarbeit zu behandeln: definiert, bei jeder Änderung geprüft und auf eine spezifische Kontrolle statt auf ein vierteljährliches Dokument gestützt.
- Explainer
Was SOC 2 tatsächlich in deinem Repository prüft
Der Großteil von SOC 2 betrifft Prozesse und Nachweise. Der Teil, der in deinem Codebase liegt, konzentriert sich auf die CC6-Familie für logischen Zugriff und ist kleiner und konkreter, als viele erwarten.
- Walkthrough
Ein GDPR-Speicherfehler im Code-Review erkennen
Eine Anleitung zum häufigsten GDPR-Problem, das durch einen normalen Pull Request durchrutscht: personenbezogene Daten, die ihren Zweck überdauern, und wie man sie im Diff erkennt.
- Playbook
Shift-left-Compliance für ein kleines Team
Wenn Sie ein kleines Team von Entwicklern sind, das sich auf das erste Audit vorbereitet, brauchen Sie keine GRC-Abteilung. Sie brauchen ein paar Gewohnheiten, die verhindern, dass Compliance zu einem vierteljährlichen Notfall wird.
- How-to
Compliance-Prüfungen als Pflicht-Check einrichten – nach Ihren Regeln
Eine Compliance-Prüfung ist am nützlichsten, wenn sie dort stattfindet, wo auch Ihre anderen Checks laufen. Hier erfahren Sie, wie Sie zwischen blockierenden und beratenden Prüfungen unterscheiden können, ohne Ihre Pipeline zum Flaschenhals zu machen.
- Walkthrough
heygrc einrichten: Installation, Konfiguration als Code, Review
Das Onboarding erfolgt mit einem Klick und einem einzigen API-Aufruf, den dein Coding-Agent ausführen kann. Hier ist der gesamte Ablauf, was jeder Schritt bewirkt und warum heygrc einen Merge nie eigenständig blockiert.
- Explainer
Compliance-Checks in Pull Requests: Was sie sind und wie man sie hinzufügt
Ein Compliance-Check in einem Pull Request ist nicht das grüne Häkchen, das anzeigt, dass Ihre Tests erfolgreich waren. Er liest die Änderung im Hinblick auf die Rahmenwerke, die Sie prüfen lassen, und benennt die Kontrolle, die betroffen ist. Hier sehen Sie, wie das aussieht, und wie Sie einen hinzufügen, ohne Ihre Pipeline zu einem Engpass zu machen.
- Map
Compliance-Automatisierungstools für Engineering-Teams
Die meisten Übersichten zu Compliance-Automatisierung listen eine Kategorie auf: Plattformen, die das Programm verwalten und Beweise sammeln. Engineering-Teams berühren jedoch eine zweite Ebene: den Pull Request, in dem Kontrollen tatsächlich umgesetzt werden. Hier ist eine neutrale Übersicht beider Ebenen.
- Field guide
Compliance-Prüfungen für KI-generierten Code
Ein KI-Agent kann Code schreiben, der korrekt, sicher und korrekt lizenziert ist, und trotzdem eine Kontrolle verschieben, die geprüft wird. Bug-, Schwachstellen- und Lizenzscanner sind nicht dafür ausgelegt, das zu erkennen. Hier steht, was eine Compliance-Prüfung für KI-generierten Code tatsächlich prüft, mit einem praktischen Beispiel.
- How-to
heygrc parallel zu Cursor Bugbot ausführen
Bugbot überprüft Ihre Pull Requests auf wahrscheinliche Fehler und Codequalität. heygrc liest denselben Diff auf die Compliance-Kontrollen, die betroffen sind. So richten Sie das Duo ein, halten das Kommentarvolumen überschaubar und entscheiden, was einen Merge blockiert.
- How-to
heygrc parallel zu CodeRabbit ausführen
CodeRabbit überprüft Pull Requests auf Fehler, Qualität und Best Practices und fasst zusammen, was sich geändert hat. heygrc fügt die fehlende Zitierung hinzu: die Compliance-Kontrolle, die eine Änderung betrifft. So lassen sich beide Tools ohne doppelte Benachrichtigungen nutzen.
- Field guide
EU AI Act für Entwickler: Artikel 50 ist aktiv, Hochrisiko kommt später
Ab dem 2. August 2026 gelten die Transparenzpflichten nach Artikel 50. Das Digital Omnibus (Verordnung (EU) 2026/1744) hat die meisten Hochrisiko-Pflichten aus Kapitel III auf Dezember 2027 und August 2028 verschoben. Was dieser Zeitplan für einen Pull Request bedeutet, mit einem praktischen Beispiel zur versehentlichen Entfernung von Offenlegungspflichten.
- Explainer
DORA-Compliance für Entwickler: Was in einem Pull Request landet
DORA ist ein Gesetz zur operativen Resilienz für Finanzinstitute der EU sowie für bestimmte kritische ICT-Drittanbieter unter direkter Aufsicht. Der Großteil betrifft Governance und Tests. Der Teil, der sich im Code niederschlägt, ist klein, konkret und lässt sich problemlos über eine normale Code-Review durchsetzen. Welche Artikel in einem Diff relevant sind, ein durchgearbeitetes Drittanbieter-Beispiel und was eine Code-Review tatsächlich erkennen kann.
- Explainer
NIS 2 Software-Anforderungen: Was in einem Pull Request landet
NIS 2 legt Pflichten zum Cybersecurity-Risikomanagement für wesentliche und wichtige EU-Einrichtungen fest, wobei die meisten Darstellungen dies als Politik und Prozess behandeln. Eine Maßnahme, die sichere Entwicklung und Schwachstellenbehandlung nach Art. 21(2)(e), wird jedoch durch das tatsächlich ausgelieferte Produkt bestimmt. Welche Änderungen diese auslösen, ein praktisches Beispiel, das sich von der Framework-Zentrale unterscheidet, und was eine Überprüfung erfassen kann und was nicht.
- Playbook
Wie man SOC 2 als Startup besteht
SOC 2 hat keine Bestehens- oder Nicht-Bestehens-Bewertung und kein Zertifikat. Ein Prüfer verfasst nach der Überprüfung, ob Ihre Kontrollen gut gestaltet sind und – bei einem Type-II-Bericht – ob sie tatsächlich über einen Zeitraum von mehreren Monaten angewendet wurden, eine Stellungnahme. Type I versus Type II, was in den Scope fällt, der realistische Zeitplan und wo eine Pull-Request-Prüfung ins Spiel kommt.
- Explainer
Was ein Compliance-Bot für GitHub tatsächlich tut
Suche nach einem "Compliance-Bot für GitHub" und du findest Chat-Bots, Score-Dashboards und Beweismittel-Sammler. Keines davon ist eine frameworkbasierte Prüfung des Pull Requests. Hier ist die Produktform, die das leistet, wie sie installiert wird und wie sie sich von einer abstrakten Compliance-Prüfung unterscheidet.
- Explainer
GDPR-Code-Review-Prüfungen: Welche Pflichten tauchen in einem Pull Request auf
Die meisten Suchergebnisse zu "GDPR Code Review" sind Cookie-Scanner oder allgemeine Artikel zu sicherem Programmieren. Hier ist die PR-Ebene: Art. 5(1)(c) und (e), Art. 17, Art. 25, Art. 32 und Art. 44, wie sie in einem Diff erscheinen, mit einem praktischen Beispiel, das kein Speicherungs-Fehler ist.
- Explainer
SOC 2 Change Management in Pull Requests (CC8.1)
SOC 2 in Pull Requests wird oft auf "Branch Protection aktivieren" reduziert. CC8.1 betrifft auch, ob eine Änderung tatsächlich die Genehmigungen und Prozesse durchlaufen hat, die Sie beschrieben haben. Wie eine übersprungene Genehmigung in einem Diff aussieht und wie dies mit einem Typ-II-Beobachtungszeitraum zusammenhängt.
- Field guide
Cyber Resilience Act für Entwickler: Was in einem Pull Request auffallen kann
Das CRA ist ein Produkt-Cybersicherheitsgesetz für Produkte mit digitalen Elementen: SBOM, Schwachstellenmanagement, Secure-by-Design. Meldepflichten beginnen am 11. September 2026; Hauptpflichten am 11. Dezember 2027. Was ein Code-Review tatsächlich erkennen kann und was nicht.