Word gematcht

Code review

Processen

Analyse van de broncode van een programma. Het doel is onder meer om zwakke plekken te vinden. Men zoekt voor een groot deel handmatig en niet aan de hand van een uitputtende lijst van kwetsbaarheden. De aanpak berust meer op expertise van de uitvoerder.

Code review is het systematisch beoordelen van broncode door een of meerdere ontwikkelaars om fouten, kwetsbaarheden en kwaliteitsproblemen op te sporen voordat software in productie gaat. In de cybersecurity speelt code review een cruciale rol: het is een van de meest effectieve manieren om beveiligingslekken vroeg in het ontwikkelproces te identificeren. Waar geautomatiseerde tools zoals SAST patronen herkennen, brengt een menselijke reviewer contextbegrip mee dat machines missen. Denk aan logicafouten in authenticatiestromen of onveilige dataverwerking die alleen opvalt als je de bedrijfslogica begrijpt. Het OWASP Code Review Guide beschrijft meer dan 120 individuele beveiligingscontroles die een grondige code review moet dekken, van inputvalidatie en outputcodering tot secrets management en afhankelijkheidsbeheer.

De praktijk van code review bestaat al sinds de jaren zeventig, maar de focus op beveiliging is de afgelopen tien jaar sterk toegenomen. Met de opkomst van DevSecOps is beveiligingsreview een integraal onderdeel geworden van het softwareontwikkelproces. Organisaties die code review structureel toepassen, ontdekken gemiddeld 60 procent meer kwetsbaarheden dan organisaties die uitsluitend op geautomatiseerde scanning vertrouwen. Het principe is eenvoudig: vier ogen zien meer dan twee, en een ervaren beveiligingsreviewer herkent patronen die zelfs een geschikte scanners missen.

Hoe werkt code review? Stappen

Een gestructureerde code review volgt een vast proces in drie fasen: voorbereiding, uitvoering en rapportage. In de voorbereidingsfase bepaal je de scope: welke bestanden, modules of pull requests worden beoordeeld. Je stelt reviewcriteria op die minimaal inputvalidatie, authenticatie, autorisatie, foutafhandeling en cryptografische implementaties dekken. De reviewer bestudeert vooraf de architectuurdocumentatie en het dreigingsmodel van de applicatie om de context te begrijpen waarin de code functioneert.

Tijdens de uitvoeringsfase doorloopt de reviewer de code methodisch, regel voor regel. De reviewer let op afwijkingen van secure coding standaarden en controleert of bekende kwetsbaarheden uit de OWASP Top 10 zijn afgedekt. Bevindingen worden gedocumenteerd met een ernst-classificatie: kritiek, hoog, medium of laag. Kritieke bevindingen blokkeren deployment, lagere bevindingen worden opgenomen in de technische schuld-backlog. De OWASP Top 10:2025 voegt Software Supply Chain Failures toe als nieuwe categorie, wat review van externe afhankelijkheden extra urgent maakt.

Na de review volgt de rapportagefase met een overleg tussen reviewer en ontwikkelaar. Bevindingen worden besproken, oplossingsrichtingen afgestemd en prioriteiten bepaald. De ontwikkelaar past de code aan en dient een nieuwe versie in voor hercontrole. Best practice is om code reviews te integreren in je CI/CD-pipeline, zodat elke pull request automatisch een reviewstap doorloopt voordat merge naar de hoofdbranch mogelijk is. Pre-commit hooks, feature completion reviews en sprint reviews zijn gangbare integratiepunten die samen een doorlopend beveiligingsnet vormen.

Wanneer voer je code review uit?

Code review is geen eenmalige activiteit maar een doorlopend proces dat je inbedt in de dagelijkse ontwikkelworkflow. Je voert reviews uit bij elke significante codewijziging, bij het toevoegen van nieuwe functionaliteit en bij wijzigingen in beveiligingskritieke componenten zoals authenticatie, autorisatie en betalingsverwerking. Onder DORA en NIS2 zijn organisaties in de financiele en vitale sector verplicht om aantoonbare beveiligingsmaatregelen te treffen in hun softwareontwikkelproces, en code review is daar een bewezen onderdeel van.

Trigger-momenten voor een extra intensieve review zijn: het verwerken van persoonsgegevens (AVG-relevant), het implementeren van cryptografie, het bouwen van API-endpoints die extern bereikbaar zijn en het integreren van third-party bibliotheken. Daarnaast is het verstandig om periodiek bestaande code opnieuw te reviewen, zeker na het ontdekken van nieuwe kwetsbaarheden die vergelijkbare patronen in je eigen codebase kunnen raken. Een risicogestuurde planning zorgt ervoor dat de meest kritieke componenten het vaakst worden gereviewd zonder dat het team overbelast raakt.

Naast reguliere reviews zijn er specifieke momenten waarop een diepgaandere beveiligingsreview noodzakelijk is. Bij het lanceren van een nieuw product, bij grote architectuurwijzigingen, na een beveiligingsincident of bij het overstappen naar een nieuwe technologiestack is een uitgebreide review essentieel. In de financiele sector eisen toezichthouders vaak dat code reviews worden uitgevoerd door onafhankelijke partijen die geen betrokkenheid hebben bij de ontwikkeling van de te reviewen software, om belangenverstrengeling te voorkomen.

Wat kost code review?

De kosten van code review varieren sterk afhankelijk van scope en complexiteit. Een interne code review door eigen ontwikkelaars kost je vooral tijd: reken op 15 tot 30 minuten per 200 regels code. Voor een middelgrote applicatie met 50.000 regels code betekent dat 40 tot 80 uur reviewtijd. Externe secure code reviews door gespecialiseerde beveiligingsbedrijven kosten tussen de 5.000 en 25.000 euro voor een gemiddelde applicatie, afhankelijk van de complexiteit en het aantal technologieen dat wordt gebruikt.

Geautomatiseerde code audit tools verlagen de handmatige inspanning aanzienlijk maar vervangen menselijke review niet volledig. De investering verdient zich terug doordat het oplossen van een kwetsbaarheid tijdens code review gemiddeld 10 tot 100 keer goedkoper is dan wanneer dezelfde kwetsbaarheid in productie wordt ontdekt en misbruikt. Factoren die de prijs beinvloeden zijn de programmeertaal, het aantal frameworks, de aanwezigheid van legacy code en de vereiste diepgang van de beveiligingsanalyse. Organisaties die structureel investeren in code review zien op termijn lagere incidentkosten en snellere releasecycli door minder last-minute fixes en minder kwetsbaarheden die de productieomgeving bereiken.

Veelgestelde vragen over code review

Wat is het verschil tussen code review en een penetratietest?

Code review analyseert de broncode op kwetsbaarheden zonder de applicatie te draaien. Een penetratietest test de draaiende applicatie van buitenaf op runtime-kwetsbaarheden. Beide zijn complementair: code review vindt fouten in de logica, pentesting vindt configuratiefouten en runtime-problemen. Samen dekken ze een breder aanvalsoppervlak af.

Hoe lang duurt een secure code review?

Een handmatige secure code review duurt gemiddeld twee tot vier weken voor een middelgrote applicatie. De doorlooptijd hangt af van de omvang van de codebase, de complexiteit van de bedrijfslogica en de beschikbaarheid van architectuurdocumentatie. Bij urgentie kan een risico-gebaseerde review op kritieke modules in enkele dagen worden uitgevoerd.

Kun je code review volledig automatiseren?

Deels. SAST-tools automatiseren patroonherkenning voor veelvoorkomende kwetsbaarheden zoals SQL injection en cross-site scripting. Logicafouten, onveilige business flows en contextafhankelijke kwetsbaarheden vereisen menselijke beoordeling. een geschikte aanpak combineert geautomatiseerde scanning met handmatige review voor optimale dekking.

Is code review verplicht onder NIS2?

NIS2 schrijft geen specifieke maatregelen voor maar eist wel dat organisaties passende technische maatregelen treffen voor de beveiliging van netwerk- en informatiesystemen. Code review is een erkende best practice die bijdraagt aan het aantonen van die zorgplicht, vooral voor organisaties die eigen software ontwikkelen of laten ontwikkelen.

Welke programmeertalen zijn het moeilijkst te reviewen?

Talen met veel dynamisch gedrag zoals PHP, JavaScript en Python vereisen extra aandacht vanwege type coercion en runtime evaluatie. Talen met een sterk typesysteem zoals Rust en Go vangen meer fouten compile-time op, wat de reviewlast verlaagt maar de complexiteit van concurrency-reviews verhoogt.

Wat is peer review versus expert review?

Bij peer review beoordeelt een collega-ontwikkelaar de code als onderdeel van het dagelijkse ontwikkelproces. Bij expert review beoordeelt een gespecialiseerde beveiligingsexpert de code met focus op security-specifieke patronen en kwetsbaarheden. Peer review is continu en laagdrempelig, expert review is periodiek en diepgaander.

Zoek een specialist voor code review via DevSecOps / Secure SDLC aanbieders op IBgidsNL.