Die meisten Teams, die Pull Requests ernst nehmen, lassen bereits einen oder zwei Reviewer jeden Change prüfen. Ein Bug-Checker wie Cursor Bugbot oder CodeRabbit liest den Diff und fragt, ob der Code korrekt ist. Ein Sicherheitsagent liest ihn und fragt, ob der Code sicher ist: eine Injektion, eine fehlerhafte Zugriffsprüfung, ein geleaktes Geheimnis. Beide beantworten echte Fragen, und ein ernsthafter Change verdient beide.
Es gibt eine dritte Frage, für die Code Reviews selten einen Verantwortlichen benennen: Erfüllt dieser Change noch die Compliance-Rahmenwerke, auf die Ihr Unternehmen geprüft wird? Nicht 'Ist es ein Bug?' und nicht 'Ist es eine Schwachstelle?', sondern 'Berührt er eine Kontrolle in SOC 2, ISO 27001 oder der GDPR, und ist der Nachweis nach dem Deployment noch gültig?' Es ist eine andere Frage als Korrektheit oder Sicherheit, und genau für diese ist heygrc entwickelt worden. Sie steht neben den anderen beiden, anstatt eine davon zu ersetzen.
Korrekt, sicher und trotzdem ein Befund
Die drei Fragen sind unabhängig. Ein Change kann ein Bug sein, aber keine Schwachstelle. Er kann eine Schwachstelle sein, aber kein Compliance-Problem. Und er kann sauberer, funktionierender Code sein, der dennoch eine Kontrolle berührt, auf die Sie geprüft werden. Dieser letzte Fall hat selten einen Reviewer im Raum.
Hier ist die Art von Change, die wir meinen. Betrachten Sie es als Beispiel: eine Zeile sauberen Codes, die kompiliert und läuft und weder der Bug noch die Schwachstelle im Diff ist.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}Warum die dritte Frage keinen Verantwortlichen hat
Ein Bug-Checker und ein Sicherheitsagent können absichtlich framework-blind sein, und das ist ihre Stärke. Ihre Regeln sind universell: Ein Use-After-Free ist überall ein Use-After-Free, eine nicht parametrisierte Abfrage ist überall eine Injektion. Universelle Regeln sind der Grund, warum diese Tools out-of-the-box funktionieren.
Compliance ist das Gegenteil. Ob ein Change ein Befund ist, hängt davon ab, welche Rahmenwerke Sie gebunden sind, welche Kontrollen Sie dokumentiert haben und worauf Ihr letztes Audit basierte. Derselbe Diff, der für ein Unternehmen irrelevant ist, kann für ein anderes eine SOC 2 CC7.2-Nachweislücke darstellen. Das ist nichts, was eine framework-blinde Regel allein tragen kann, denn das Problem liegt nicht im Code. Es liegt in Ihren Verpflichtungen, und es muss im Kontext dieser gelesen werden.
Kombinieren Sie die Perspektiven, wählen Sie nicht zwischen ihnen
Die Erkenntnis ist nicht 'Fügen Sie ein weiteres Tool hinzu.' Sie ist, dass ein Pull Request am vollständigsten durch drei Perspektiven gelesen wird, nicht nur eine: Ist er korrekt? Ist er sicher? Erfüllt er noch unsere Rahmenwerke? Behalten Sie Ihren Bug-Checker. Behalten Sie Ihren Sicherheitsagenten. Sie sind gut in ihren Fragen, und heygrc versucht nicht, diese zu beantworten. heygrc fügt die dritte Perspektive hinzu und meldet sie auf die einzige Weise, die für einen Compliance-Befund von Wert ist: durch den genauen Verweis auf die berührte Kontrolle.
Das obige Beispiel ist illustrativ, die Art von Change, die die dritte Frage aufwirft, nicht ein spezifischer Vorfall. Aber genau das ist der Punkt: Die Changes, die Ihre Compliance-Position verändern, sind normalerweise nicht die fehlerhaften oder unsicheren. Es sind die sauberen, korrekt aussehenden, die leise eine Kontrolle berühren, und das ist etwas anderes, wonach man suchen muss als nach einem Bug oder einer Schwachstelle.