Zoek naar compliance-controles in pull requests en het meeste wat je vindt gaat over de vereiste statuscontroles van GitHub: ervoor zorgen dat de testsuite en de linter groen zijn voordat er wordt gemerged. Dat is een nuttige en echte zaak, maar dat is niet waar deze pagina over gaat. Een compliance-controle is een andere vraag die aan dezelfde pull request wordt gesteld: raakt deze wijziging een controle waar je bedrijf op wordt geauditeerd, in SOC 2, ISO 27001, de GDPR of een ander framework waaraan je gebonden bent.
Die vraag heeft zelden een eigenaar in de code review. Correctheid en beveiliging hebben elk goed gedefinieerde controles; of een wijziging een controle heeft aangeraakt waar je op wordt geauditeerd, is een aparte lezing, en dat is precies wat een compliance-controle op de pull request toevoegt. Het is de moeite waard om precies te zijn over wat die controle wel en niet is.
Wat het is, en wat het niet is
Een compliance-controle leest de diff, niet de testresultaten. Het koppelt de daadwerkelijke wijziging aan de specifieke controle die het beïnvloedt en meldt die controle bij naam, op een niveau dat je kunt verifiëren. Het is geen goed- of afkeuring van je testsuite, geen dekkingsdrempel en geen beleidsdocument dat een auditor eenmaal per jaar steekproefsgewijs controleert. Het is een per-wijziging lezing van of de pull request voor je een controle heeft aangeraakt die je verplicht bent te handhaven.
De uitvoer die het nuttig maakt, is de verwijzing. "Dit ziet er niet-compliant uit" is ruis. "Dit verwijdert het auditlogboek voor een bevoorrechte actie, wat ISO 27001:2022 A.8.15 van je verwacht te behouden" is iets waar een engineer op kan acteren of tegenin kan gaan. Een compliance-controle die de controle niet bij naam kan noemen, is het toevoegen niet waard.
Drie controle-relevante wijzigingen die verborgen zitten in routinematige pull requests
Een verruimd toegangspad. Een pull request verbredt een IAM-rol of opent een nieuwe route naar een resource. De code is correct en kan perfect veilig zijn, maar het vergroot wie toegang heeft tot beschermde gegevens, wat precies is waar SOC 2 CC6.1 (logische toegangcontroles) over gaat. Het kan lezen als een routinematige configuratiewijziging terwijl de controle die het raakt onbenoemd blijft.
Een verzwakt auditlogboek. Een opschoning verwijdert of verkort een logregel die toevallig het record was van een bevoorrechte actie. Niets gaat kapot, en het kan lezen als een onschuldige opschoning, maar het bewijs dat een auditor steekproefsgewijs controleert onder ISO 27001:2022 A.8.15 (logboekregistratie) is nu verdwenen. De wijziging die het veroorzaakte is de goedkoopste plek om het op te merken.
Een nieuwe opslag van persoonsgegevens zonder beperking. Een migratie voegt een tabel toe die begint met het verzamelen van persoonsgegevens zonder bewaartermijn. Het is schone, werkende code, en het zet je stilletjes aan de verkeerde kant van GDPR Art. 5(1)(e) (opslagbeperking), dat vereist dat persoonsgegevens niet langer worden bewaard dan noodzakelijk. Geen van deze drie is een bug of een kwetsbaarheid. Elke is een controle-relevante wijziging die verborgen zit in een routinematige pull request.
Adviserend standaard, blokkerend alleen als je dat kiest
Een compliance-controle die elke merge blokkeert bij elke bevinding leert mensen om er overheen te klikken; een die nooit iets blokkeert, wordt genegeerd. De nuttige standaard is adviserend: de controle plaatst de controle en de clausule als een opmerking en een neutrale status, zodat de bevinding zichtbaar is zonder de merge te onderbreken. De beslissing om te blokkeren hoort bij je branch-beveiligingsbeleid, niet bij de tool.
Als een gemiste controle echt kostbaar is, alles wat toegangcontrole, cryptografie of persoonsgegevens raakt, kun je de controle verplicht stellen via branch-beveiliging op de repositories of beschermde branches waar het het meest telt, en het elders adviserend laten. Het mechanisme moet je de keuze laten voor de houding in plaats van er een op alles af te dwingen.
Hoe je er een toevoegt
Een compliance-controle voert uit op de pull request op dezelfde manier als je andere controles: het wordt geactiveerd wanneer een PR wordt geopend of bijgewerkt, leest de diff af tegen de frameworks die je hebt geselecteerd en de context van je bedrijf, en plaatst de controles die een wijziging raakt met de bijbehorende clausule. Het moeilijke deel is niet opmerken dat er iets is gewijzigd; het is precies benoemen welke controle is gewijzigd, correct, en daarom moeten de frameworks waaraan je gebonden bent en je eigen context de controle voeden.
heygrc is gebouwd om die controle als een GitHub App te zijn: installeer het, vertel het eenmaal je frameworks en context, en het beoordeelt elke pull request op compliance-impact, door een neutrale Checks-status plus inline opmerkingen te plaatsen, zodat het informeert in plaats van blokkeert, tenzij je besluit het verplicht te stellen. De instellingshandleiding dekt de onboarding van drie minuten.