De meeste teams die pull requests serieus nemen, laten al een of twee reviewers naar elke wijziging kijken. Een bugchecker zoals Cursor Bugbot of CodeRabbit leest de diff en vraagt of de code correct is. Een beveiligingsagent leest deze en vraagt of de code veilig is: een injectie, een gebroken toegangcontrole, een gelekte geheim. Beide beantwoorden echte vragen, en een serieuze wijziging verdient beide.
Er is een derde vraag waar code review zelden een eigenaar voor aanwijst: voldoet deze wijziging nog aan de compliance frameworks waar je bedrijf op wordt geaudit? Niet 'is het een bug' en niet 'is het een kwetsbaarheid', maar 'raakt het een control in SOC 2, ISO 27001 of de GDPR, en is het bewijs na implementatie nog geldig?' Het is een andere vraag dan correctheid en beveiliging, en het is de vraag waar heygrc voor is gebouwd. Het sluit aan bij de andere twee in plaats van een van beide te vervangen.
Correct, veilig en toch een bevinding
De drie vragen zijn onafhankelijk. Een wijziging kan een bug zijn en geen kwetsbaarheid. Het kan een kwetsbaarheid zijn en geen compliance-probleem. En het kan schone, werkende code zijn die toch een controle beïnvloedt waar je op wordt geaudit. Dat laatste geval is degene waar zelden een reviewer bij is.
Dit is het soort wijziging dat we bedoelen. Beschouw het als illustratief: één regel schone code die compileert en draait, en die noch de bug noch de kwetsbaarheid in de diff is.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}De branch is schone, werkende code: deze retourneert een beslissing en er is niets aan dat een bug of kwetsbaarheid is. Maar het neemt een volledig geautomatiseerde beslissing over een persoon, waarbij een terugbetaling wordt geweigerd, zonder mogelijkheid tot menselijke beoordeling. Waar een dergelijke beslissing een juridisch of anderszins significant effect heeft, geeft GDPR Art. 22 de persoon het recht om niet aan deze beslissing te worden onderworpen en het recht op menselijke tussenkomst. Wat deze wijziging eigenlijk heeft geïntroduceerd, is een compliance-vraag om te beantwoorden, geen defect om op te lossen.
Waarom de derde vraag geen eigenaar heeft
Een bugchecker en een beveiligingsagent kunnen bewust framework-blind zijn, en dat is hun kracht. Hun regels zijn universeel: een use-after-free is overal een use-after-free in elke repository, een niet-geparameteriseerde query is overal een injectie. Universele regels zijn de reden dat die tools direct werken.
Compliance is het tegenovergestelde. Of een wijziging een bevinding is, hangt af van welke frameworks u gebonden bent, welke controls u heeft vastgelegd en waar uw laatste audit op vertrouwde. Dezelfde diff die voor het ene bedrijf niets betekent, is voor het volgende een SOC 2 CC7.2 bewijsleemte. Dat is niet iets wat een framework-blinde regel zelfstandig kan dragen, want het probleem zit niet in de code. Het zit in uw verplichtingen, en die moeten ertegen worden afgewogen.
Combineer de lenzen, kies niet tussen hen
De boodschap is niet 'voeg nog een tool toe.' Het is dat een pull request het meest volledig wordt beoordeeld via drie lenzen, niet één: is het correct, is het veilig, voldoet het nog aan onze frameworks. Houd je bugchecker. Houd je security agent. Ze zijn goed in hun vragen, en heygrc probeert die niet te beantwoorden. heygrc voegt de derde lens toe en rapporteert deze op de enige manier die een compliance-bevinding waardevol maakt: door de exacte control te citeren die het raakt.
Het bovenstaande voorbeeld is illustratief, het soort wijziging dat de derde vraag oproept, niet een specifiek incident. Maar de vorm is het hele punt: de wijzigingen die je compliance-positie beïnvloeden, zijn meestal niet de buggy of onveilige. Het zijn de schone, correct ogende wijzigingen die stilletjes een control aanraken, en dat is iets anders om naar te zoeken dan een bug of een kwetsbaarheid.