Compliance vangen in code review.
Praktische guides in developer-register: wat elk framework echt in je repo checkt, hoe je veelvoorkomende issues in review vangt, en hoe je het in je bestaande pipeline hangt.
- Primer
Compliance as code: een praktische inleiding
Wat het betekent om compliance te behandelen als de rest van je engineering: gedefinieerd, gecontroleerd bij elke wijziging en gebaseerd op een specifieke maatregel in plaats van een kwartaalrapport.
- Uitleg
Wat SOC 2 daadwerkelijk in je repository controleert
Het grootste deel van SOC 2 draait om processen en bewijs. Het deel dat in je codebase leeft, bevindt zich in de CC6-familie voor logische toegang, en is kleiner en concreter dan de meeste mensen denken.
- Walkthrough
Een GDPR-bewaartermijnfout opsporen tijdens code review
Een stapsgewijze uitleg van het meest voorkomende GDPR-probleem dat via een normale pull request wordt doorgevoerd: persoonsgegevens die langer worden bewaard dan noodzakelijk, en hoe je dit in de diff kunt opsporen.
- Playbook
Shift-left compliance voor een klein team
Als je met een handvol engineers je eerste audit ingaat, heb je geen GRC-afdeling nodig. Je hebt een paar gewoontes nodig die voorkomen dat compliance een kwartaalcrisis wordt.
- How-to
Maak compliance een verplichte check, op jouw voorwaarden
Een compliance-review is het meest nuttig als deze op dezelfde plek staat als je andere checks. Hier leggen we uit hoe je kunt kiezen tussen blokkeren of adviseren, zonder dat je pipeline een knelpunt wordt.
- Walkthrough
heygrc instellen: installeren, configureren als code, beoordelen
Onboarding is één klik plus één API-aanroep die je codeeragent kan uitvoeren. Hier is de volledige flow, wat elke stap doet en waarom heygrc een merge nooit op eigen kracht blokkeert.
- Uitleg
Compliance-controles in pull requests: wat ze zijn en hoe je er een toevoegt
Een compliance-controle op een pull request is niet het groene vinkje dat aangeeft dat je tests zijn geslaagd. Het leest de wijziging af tegen de frameworks waar je op wordt geauditeerd en noemt de controle die het raakt. Hier is hoe dat eruitziet en hoe je er een toevoegt zonder je pipeline tot een knelpunt te maken.
- Map
Compliance-automatiseringstools voor engineeringteams
De meeste overzichten van compliance-automatisering noemen één categorie: platforms die het programma beheren en bewijs verzamelen. Engineeringteams raken ook een tweede laag aan: de pull request, waar controles daadwerkelijk worden toegepast. Hier is een neutrale kaart van beide lagen.
- Field guide
Compliancecontroles voor door AI gegenereerde code
Een AI-agent kan code schrijven die correct, veilig en passend gelicenseerd is, en toch een controle verplaatsen waar je op wordt geaudit. Bug-, kwetsbaarheids- en licentiescanners zijn niet ontworpen om dat te lezen. Hier staat wat een compliancecontrole voor door AI gegenereerde code daadwerkelijk leest, met een uitgewerkt voorbeeld.
- How-to
Voer heygrc uit naast Cursor Bugbot
Bugbot beoordeelt je pull requests op waarschijnlijke bugs en codekwaliteit. heygrc leest dezelfde diff voor de compliance-controle die het raakt. Hoe je het duo instelt, het commentaarvolume beheersbaar houdt en beslist wat een merge blokkeert.
- How-to
Voer heygrc parallel uit met CodeRabbit
CodeRabbit beoordeelt pull requests op bugs, kwaliteit en best practices en vat samen wat er is gewijzigd. heygrc voegt de ontbrekende verwijzing toe: de compliance-control die een wijziging raakt. Hoe je beide kunt uitvoeren zonder de ruis te verdubbelen.
- Field guide
EU AI Act voor ontwikkelaars: Artikel 50 is actief, high-risk komt later
Vanaf 2 augustus 2026 gelden de transparantieverplichtingen van Artikel 50. De Digital Omnibus (Verordening (EU) 2026/1744) heeft de meeste high-risk-verplichtingen uit Hoofdstuk III uitgesteld tot december 2027 en augustus 2028. Wat deze kalender betekent in een pull request, met een voorbeeld van een onjuiste verwijdering van een openbaarmaking.
- Uitleg
DORA-naleving voor ontwikkelaars: wat in een pull request terechtkomt
DORA is wetgeving voor operationele veerkracht voor EU-financiële entiteiten en voor aangewezen kritieke ICT-derdepartijaanbieders onder direct toezicht. Het grootste deel betreft governance en testen. Het deel dat in code wordt weerspiegeld, is klein, concreet en eenvoudig te verwerken via een normale review. Welke artikelen relevant zijn in een diff, een uitgewerkt voorbeeld van een derde partij en wat een code review daadwerkelijk kan opsporen.
- Uitleg
NIS 2 software-eisen: wat in een pull request terechtkomt
NIS 2 stelt cybersecurityrisicobeheerplichten vast voor essentiële en belangrijke entiteiten in de EU, en de meeste dekking behandelt het als beleid en proces. Één maatregel, veilige ontwikkeling en kwetsbaarheidsbeheer onder Art. 21(2)(e), wordt bepaald door wat daadwerkelijk wordt geleverd. Welke wijzigingen deze triggeren, een uitgewerkt voorbeeld los van de framework-hub, en wat een review kan en niet kan detecteren.
- Playbook
Hoe je als startup SOC 2 doorstaat
SOC 2 heeft geen geslaagd/gezakt-beoordeling en geen certificaat. Een auditor schrijft een oordeel na te hebben gecontroleerd of je beheersmaatregelen goed zijn ontworpen en, voor een Type II-rapport, of ze daadwerkelijk hebben gefunctioneerd over een periode van maanden. Type I versus Type II, wat je in scope neemt, de realistische tijdlijn en waar een pull-request-check in past.
- Uitleg
Wat een compliance-bot voor GitHub daadwerkelijk doet
Zoek naar een "compliance bot voor GitHub" en je krijgt chatbots, score dashboards en bewijsmateriaalverzamelaars. Geen van deze biedt een op frameworks gebaseerde analyse van de pull request. Hier vind je de productvorm die dat wel doet, hoe deze wordt geïnstalleerd en hoe deze verschilt van een abstracte compliance-check.
- Uitleg
GDPR-codecontroles: welke verplichtingen verschijnen in een pull request
De meeste zoekresultaten voor "GDPR code review" zijn cookie-scanners of algemene essays over veilig coderen. Dit is de PR-gerichte kaart: Art. 5(1)(c) en (e), Art. 17, Art. 25, Art. 32 en Art. 44 zoals ze in een diff verschijnen, met een uitgewerkt voorbeeld dat geen bewartermijnfout is.
- Uitleg
SOC 2 wijzigingsbeheer in pull requests (CC8.1)
SOC 2 in pull requests wordt vaak gereduceerd tot "branch protection inschakelen." CC8.1 gaat ook over de vraag of een wijziging daadwerkelijk door de goedkeuringen en processen is gegaan die je hebt beschreven. Hoe een overgeslagen goedkeuring eruitziet in een diff, en hoe dit samenhangt met een Type II observatievenster.
- Field guide
Cyber Resilience Act voor ontwikkelaars: wat kan veranderen in een pull request
CRA is een productcybersecuritywet voor producten met digitale elementen: SBOM, kwetsbaarheidsbeheer, secure-by-design. Meldingsverplichtingen beginnen op 11 september 2026; hoofdverplichtingen op 11 december 2027. Wat een code review daadwerkelijk kan detecteren, en wat niet.