Een review van een AI-gebouwd product is zo bruikbaar als het code audit-rapport waarmee de review eindigt. Op dat rapport baseert een founder zijn beslissing, het rapport gaat door naar het securityteam van een zakelijke klant en het belandt bij wie de code herstelt. Een rapport dat die drie taken niet aankan, laat de review onaf.
Dit artikel laat zien wat een goed code audit-rapport voor een AI-product bevat: de acht secties, de negen velden van één bevinding, hoe de ernst wordt bepaald en hoe u een beslisklaar rapport onderscheidt van een scannerexport. Voor de bredere route van prototype naar live product leest u de founder-gids over AI-gegenereerde code in productie.
TL;DR
Een code audit-rapport is het schriftelijke resultaat van een onafhankelijke review van de broncode, configuratie en technische opzet van een product: elke bevinding met bewijs en ernst, gerangschikt in een herstelvolgorde, met een overdracht waarmee een engineer aan de slag kan. Bij een AI-gebouwd product laat het rapport ook zien welke code niemand in het team kan uitleggen en wat het product naar AI-modellen stuurt.
- Acht secties vormen een volledig code audit-rapport: samenvatting en oordeel, scope en grenzen, product- en architectuuroverzicht, bevindingen, risico-overzicht, afhankelijkheden en licenties, geprioriteerd actieplan, en technische overdracht met bewijs.
- Negen velden beschrijven elke bevinding: ID, titel in gewone taal, ernst met reden, categorie, locatie, bewijs, zakelijke impact, oplossing met inspanning, en status.
- Vijf ernstniveaus rangschikken de bevindingen, van Critical (herstellen vóór de lancering) via High, Medium en Low tot Informational; securitykwetsbaarheden kunnen met CVSS v4.0 worden gescoord als dat framework van toepassing is, andere bevindingen krijgen een onderbouwde inschatting van waarschijnlijkheid en impact.
- Drie signalen onderscheiden een beslisklaar rapport van een scannerexport: gereproduceerd bewijs per bevinding, zakelijke impact in gewone taal, en een herstelvolgorde die is afgestemd op uw lancerings- of contractdatum.
Wat is een code audit-rapport?
Een code audit-rapport is het document dat een onafhankelijke reviewer oplevert na het lezen van de broncode, configuratie en deployment-opzet van een product. Het rapport noemt elke bevinding met bewijs, rangschikt de bevindingen op ernst, legt een herstelvolgorde vast en geeft engineers genoeg detail om te beginnen. Wat de reviewer controleert en hoe de opdracht verloopt, staat in AI code audit.
Drie lezers gebruiken hetzelfde rapport voor verschillende beslissingen. De founder of COO leest de samenvatting en het oordeel om te besluiten over lanceren, een klant tekenen of financiering ophalen. De technisch lead of freelancer leest de bevindingen en de overdracht om het herstelwerk te plannen. Een zakelijke klant of investeerder ziet meestal de samenvatting, de scope en de status van het herstel, niet elke bevinding.
Een code audit-rapport is geen certificaat en geen stempel “goedgekeurd” of “afgekeurd”. Het rapport beschrijft de staat van de code op een genoemde datum en commit, binnen een genoemde scope. Wat buiten die scope valt, is niet beoordeeld, en dus ook niet goedgekeurd.
Wat een code audit-rapport voor een AI-product bevat: acht secties
Een code audit-rapport voor een AI-product bevat acht secties, en elke sectie beantwoordt een andere vraag voor een andere lezer. Secties 4 en 5 bevatten de bevindingen, sectie 7 maakt er een geprioriteerd actieplan van en sectie 8 is de technische overdracht: de drie onderdelen die een review belooft, in de volgorde waarin een lezer ze nodig heeft.
| # | Sectie | Vraag die de sectie beantwoordt | Gelezen door |
|---|---|---|---|
| 1 | Samenvatting en oordeel | Kunnen we lanceren, verkopen of overdragen, en wat moet eerst gebeuren? | Beslisser |
| 2 | Scope, methode en grenzen | Wat is beoordeeld (repositories, commit, omgevingen, tools), en wat niet? | Beslisser, klant |
| 3 | Product- en architectuuroverzicht | Hoe is het product gebouwd: modules, datastromen, externe diensten, AI-tools en AI-modellen? | Technisch lead |
| 4 | Bevindingen | Wat is er mis, waar, hoe weten we dat, en hoe ernstig is het? | Technisch lead |
| 5 | Risico-overzicht | Hoeveel bevindingen per ernstniveau en per gebied, en waar clusteren ze? | Beslisser |
| 6 | Afhankelijkheden en licenties | Welke externe pakketten hebben bekende kwetsbaarheden, onderhouds- of licentierisico? | Technisch lead, juridisch |
| 7 | Geprioriteerd actieplan | Wat herstellen we nu, wat vóór de lancering, en wat later? | Beide |
| 8 | Technische overdracht en bewijsbijlage | Wat heeft een engineer of AI-codingtool nodig om elke bevinding te herstellen, en hoe wordt herstel bevestigd? | Engineer |
Sectie 2 slaan founders vaak over, terwijl die sectie het zwaarst weegt als er later iets misgaat. Een rapport zonder lijst van wat buiten de scope viel, laat niet-beoordeelde delen van het product veilig lijken. Wij raden aan een code audit-rapport zonder grenzenparagraaf te weigeren, omdat de grenzen bepalen wat u een klant eerlijk over de review kunt vertellen.
Het oordeel in sectie 1 is waar rapporten het meest verschillen. Een lanceringsoordeel hoort de voorwaarden te noemen waaraan eerst moet worden voldaan, en een checklist voor productiegereedheid laat zien wat die voorwaarden meestal omvatten; een structurele beslissing om te behouden, te refactoren of opnieuw te bouwen volgt refactor or rewrite. Het rapport hoort te vermelden op welke van de twee beslissingen het oordeel antwoordt.
Secties 2 en 4 beantwoorden ook de leveranciersvragenlijsten van zakelijke klanten, die vaak vragen hoe code wordt getoetst aan secure coding: de maatregel die ISO/IEC 27001:2022 noemt als Annex A 8.28.
Wat AI-gebouwde producten aan het rapport toevoegen
Een AI-gebouwd product heeft vier rapportonderdelen nodig die een klassieke code audit vaak overslaat: de AI-tool-voetafdruk, de kwaliteit van gegenereerde tests, controle van afhankelijkheden en licenties, en de risico’s van modelaanroepen wanneer het product tijdens gebruik een AI-model aanroept. Die onderdelen bestaan omdat AI-codingtools veranderen waar problemen zich verstoppen, niet omdat de tools slecht zijn.
AI-tool-voetafdruk en code die niemand kan uitleggen
Waar ontwikkelgegevens beschikbaar zijn, kan het rapport aangeven welke code met AI-hulp is geschreven of ingrijpend is gewijzigd. Belangrijker is dat het rapport modules markeert met onduidelijk eigenaarschap, dubbele logica, onvoldoende tests of ongedocumenteerd gedrag. Code uit losse prompts herhaalt vaak dezelfde regel net iets anders, zoals twee prijsberekeningen, en een latere wijziging herstelt één kopie en mist de andere.
Als de herkomst van een module niet is vast te stellen, legt het rapport die beperking vast in plaats van te raden welke tool de code heeft gemaakt. Eigenaarschap, tests en documentatie bepalen hoe riskant de volgende wijziging is; de naam van de tool doet dat niet.
Tests die slagen maar niets testen
Het aantal tests en het dekkingspercentage zijn zwak bewijs in een AI-gebouwd product, omdat dezelfde AI-tool vaak zowel de code als de tests heeft geschreven. Een goed rapport vermeldt per kritieke flow, zoals aanmelden, betalen en rechten, of er een test bestaat die faalt als het gedrag verkeerd is. Een test die alleen controleert dát een functie is aangeroepen, blijft groen terwijl de uitkomst fout is.
Afhankelijkheden en licenties
AI-codingtools voegen snel externe pakketten toe, ook pakketten die niet meer worden onderhouden, kwetsbaar zijn of een licentie hebben die botst met hoe het product wordt verkocht. OWASP Top 10:2025 noemt Software Supply Chain Failures als categorie A03. De sectie afhankelijkheden hoort externe componenten, versies, licenties en relevante relaties in de toeleveringsketen te benoemen.
Een software bill of materials (SBOM) geeft een gestructureerde inventaris van die componenten, terwijl een afhankelijkheidsanalyse bekende kwetsbaarheden, onderhoudsstatus en aanbevolen acties toevoegt. De 2026 Minimum Elements for a Software Bill of Materials, gepubliceerd door CISA en partnerinstanties, is een referentie voor de inventarisgegevens, geen vervanging van een securitybeoordeling.
Producten die tijdens gebruik een AI-model aanroepen
Een product met AI-functies, zoals een supportassistent, zoeken in documenten of gegenereerde samenvattingen, heeft een rapportsectie over zijn modelaanroepen nodig. De term “AI-product” dekt zowel een app die met AI-tools is gebouwd als een app met AI-functies; het verschil en het effect op de kosten staan in kosten van AI-appontwikkeling.
Drie controles horen in die sectie. Prompt injection, als LLM01:2025 opgenomen in de OWASP Top 10 for LLM Applications, gaat over tekst van gebruikers of documenten die verandert wat het model doet. Unbounded consumption, LLM10:2025, gaat over modelaanroepen zonder limiet die uitlopen op storingen of een onbeheerste modelrekening.
De datastroomcontrole legt vast welke persoonsgegevens de modelaanbieder bereiken, voor welk doel en onder welke contractuele afspraken. Treedt de aanbieder op als verwerker namens u, dan vereist de AVG artikel 28 een passende verwerkersovereenkomst, en artikel 32 vereist beveiligingsmaatregelen die passen bij het risico. Het rapport hoort ontbrekende maatregelen of afspraken te benoemen, in plaats van aan te nemen dat elke modelaanbieder dezelfde rol voor gegevensbescherming heeft.
Voor AI-systemen die bedoeld zijn om rechtstreeks met mensen te communiceren, vereist artikel 50, lid 1, van de EU AI-verordening in de regel dat gebruikers worden geïnformeerd dat zij met AI communiceren, tenzij dat al duidelijk is uit de context. De transparantieverplichtingen gelden sinds 2 augustus 2026. Een rapport hoort te controleren of de interface van het product aan de toepasselijke eis voldoet, in plaats van aan te nemen dat elke AI-functie dezelfde melding nodig heeft.
Anatomie van één bevinding: negen velden
Eén bevinding in een code audit-rapport hoort negen velden te hebben, zodat een founder kan beslissen en een engineer kan handelen zonder extra overleg. De bevinding, niet het aantal pagina’s, is wat het rapport waardevol maakt.
| Veld | Inhoud | Waarom de founder het nodig heeft |
|---|---|---|
| ID | Een unieke referentie, bijvoorbeeld F-07 | Herstel volgen en bespreken in de toelichting |
| Titel | Eén zin in gewone taal: wat kan er misgaan | De bevinding begrijpen zonder code te lezen |
| Ernst | Critical, High, Medium, Low of Informational, met een reden in één regel | Zien wat de lancering blokkeert |
| Categorie | OWASP Top 10:2025- of OWASP LLM 2025-ID voor security; anders “engineeringkwaliteit” | De bevinding koppelen aan vragenlijsten van klanten |
| Locatie | Bestand, endpoint, configuratie of dienst | De engineer kan direct beginnen |
| Bewijs | Reproductiestappen of een testresultaat | Toont aan dat het probleem echt is, geen gok van een scanner |
| Zakelijke impact | Effect op gebruikers, persoonsgegevens, geld of contracten | De bevinding afwegen tegen de lanceringsdatum |
| Oplossing en inspanning | De aanbevolen wijziging, ingeschat als S, M of L | Plannen wie het werk doet en wanneer |
| Status | Open, hersteld, deels hersteld of geaccepteerd risico, met een hertestdatum | Voortgang tonen aan klanten en investeerders |
Geautomatiseerde scannerexports kunnen ernst, status en algemene impactbeschrijvingen bevatten. Een beslisklaar rapport voegt gevalideerd bewijs toe, legt het effect uit op de echte gebruikers en workflows van het product, en bepaalt een herstelvolgorde ten opzichte van zakelijke mijlpalen.
Voorbeeldbevinding 1: security (illustratief, geen klantgegevens)
| Veld | Inhoud |
|---|---|
| ID | F-03 |
| Titel | Iedereen met een gratis account kan de AI-supportassistent onbeperkt gebruiken |
| Ernst | High (illustratieve ernstinschatting, geen berekende CVSS-score) — eenvoudig uit te lokken met een simpel script; impact op kosten en beschikbaarheid; geen blootstelling van gegevens vastgesteld |
| Categorie | OWASP LLM10:2025 Unbounded Consumption |
| Locatie | POST /api/assistant/chat; de model-API wordt vanaf de server aangeroepen zonder quotum per gebruiker |
| Bewijs | Een script, ingelogd als gratis testgebruiker, verstuurde 500 verzoeken in tien minuten. Elk verzoek werd beantwoord, en er sloeg geen rate limit, quotum of kostenalarm aan. |
| Zakelijke impact | De modelaanbieder rekent per token af, dus één misbruikt account bepaalt de hoogte van de maandrekening. Bereikt de aanbieder zijn eigen gebruikslimiet, dan stopt de assistent voor alle klanten. |
| Oplossing en inspanning | Een rate limit en daglimiet per gebruiker op het endpoint, een kostenplafond en alarm bij de modelaanbieder, en een blokkade voor gratis accounts die de limiet blijven raken. Inspanning: S. |
| Status | Open — hertest na herstel |
Voorbeeldbevinding 2: engineeringkwaliteit (illustratief, geen klantgegevens)
| Veld | Inhoud |
|---|---|
| ID | F-11 |
| Titel | Betaaltests slagen ook als terugbetalingsbedragen fout zijn |
| Ernst | Medium (illustratief) — geen securityrisico; de inschatting hangt af van het aantal getroffen terugbetalingen, de bedragen en de werkelijke impact op klanten, en stijgt als een daarvan groot is |
| Categorie | Engineeringkwaliteit (testdekking) |
| Locatie | tests/checkout/ en de module voor terugbetalingen |
| Bewijs | De 42 checkouttests vervangen de betaalprovider door een mock (een nabootsing) en controleren alleen dat de terugbetalingsfunctie is aangeroepen. Na het wijzigen van de afronding van twee decimalen naar nul bleven alle 42 tests groen. |
| Zakelijke impact | Een fout in een terugbetaling bereikt klanten en de financiële afdeling voordat een test faalt. Het eerste signaal is een klacht van een klant of een verschil in de maandafsluiting. |
| Oplossing en inspanning | Contracttests tegen de sandbox van de betaalprovider voor drie flows (betaling, gedeeltelijke terugbetaling, volledige terugbetaling) die bedragen en valuta controleren. Inspanning: M. |
| Status | Open |
De twee voorbeelden laten zien waarom een rapport beide soorten bevindingen nodig heeft. Een securityscanner zou F-03 alleen melden als hij het zakelijke doel van het endpoint kende, en geen enkele securityscanner zou F-11 melden.
Wilt u bevindingen zoals deze voor uw eigen product?
Een AI-built product review legt elke bevinding uit in begrijpelijke taal, met het bewijs erachter en het effect op uw product, en maakt van de bevindingen een geprioriteerd actieplan waar uw team of uw AI-codingtool mee verder kan. Engineering en security worden samen beoordeeld, dus u krijgt één herstelvolgorde in plaats van twee rapporten die elkaar tegenspreken.
Hoe de ernst in een code audit-rapport wordt bepaald
De ernst in een code audit-rapport beschrijft hoe serieus een bevinding is, op vijf niveaus van Critical tot Informational. Securitykwetsbaarheden kunnen met CVSS v4.0 worden gescoord als dat framework van toepassing is: de CVSS v4.0-specificatie van FIRST noemt scores van 0,1–3,9 Low, 4,0–6,9 Medium, 7,0–8,9 High en 9,0–10,0 Critical. Andere bevindingen, zoals engineeringkwaliteit, operationele zwakke plekken en fouten in bedrijfslogica, vragen om een onderbouwde ernstinschatting op basis van waarschijnlijkheid, impact en de getroffen gebruikers of workflows.
| Ernst | Betekenis | Voorbeeld bij een AI-product | Illustratieve herstelprioriteit |
|---|---|---|---|
| Critical | Nu misbruikbaar, of breekt een kernflow voor alle gebruikers | Klantgegevens leesbaar zonder in te loggen; geheime sleutel van een betaalde dienst in de front-endcode | Vóór de lancering; eerst de blootstelling indammen |
| High | Ernstig en bereikbaar, met beperkte voorwaarden | Een klantaccount kan de gegevens van een ander account openen; AI-endpoint zonder limieten (F-03) | Vóór de lancering of de volgende zakelijke deal |
| Medium | Reëel risico onder specifieke voorwaarden, of fout gedrag met een workaround | Tests die betaalfouten niet kunnen vangen (F-11); geen afhandeling bij een storing van een externe dienst (OWASP A10:2025) | Binnen de volgende één of twee releases |
| Low | Beperkte impact of moeilijk uit te lokken | Uitgebreide foutmeldingen in productie; verouderd pakket zonder bekend misbruikpad | Geplande backlog |
| Informational | Geen direct risico; een opmerking over kwaliteit of onderhoudbaarheid | Dubbele logica in meerdere modules; ontbrekende architectuurnotities | Bij de volgende wijziging van de module |
Ernst beschrijft hoe serieus een bevinding is. Prioriteit bepaalt wat eerst wordt hersteld, op basis van ernst, misbruikbaarheid, zakelijke afhankelijkheden en komende mijlpalen. Een Medium-bevinding die de securityvragenlijst van een zakelijke klant blokkeert, mag terecht vóór een High-bevinding in een intern beheerscherm komen.
Andersom werkt prioriteit nooit: een probleem dat de lancering blokkeert, wordt niet aanvaardbaar door het alleen een latere streefdatum te geven. De herstelprioriteiten in tabel 3 zijn voorbeelden, geen vaste wachttijden voor elke bevinding op dat niveau.
Een code audit-rapport lezen als u niet technisch bent
Een niet-technische founder leest een code audit-rapport in vijf stappen, zonder code te lezen. De eerste twee stappen laten zien of de rest van het rapport uw plannen verandert.
- Lees het oordeel en de lijst “herstellen vóór de lancering” in sectie 1.
- Lees de titel en zakelijke impact van elke Critical- en High-bevinding; sla locatie en bewijs voorlopig over.
- Lees de grenzen in sectie 2 en noteer wat u niet tegen klanten kunt beweren.
- Leg het actieplan naast uw echte data: lancering, zakelijk contract of financieringsronde.
- Controleer of elk “nu herstellen”-punt een eigenaar met naam aan uw kant heeft.
Vijf vragen maken de toelichting met de reviewer nuttig:
- Welke ene bevinding zou u tegenhouden om te lanceren als dit uw product was?
- Wat heeft u niet beoordeeld, en is dat gat belangrijk voor onze volgende mijlpaal?
- Welke bevindingen heeft u gereproduceerd, en welke zijn risico’s die nog onderzocht moeten worden?
- Welke bevindingen kunnen veilig drie maanden wachten?
- Hoe wordt bevestigd dat een herstel is afgerond?
Wie na het rapport wat herstelt, en wanneer een bevinding als afgerond geldt, staat in de sectie over de periode na de audit in AI code audit.
Een goed rapport onderscheiden van een scannerexport
Een beslisklaar code audit-rapport verschilt op acht zichtbare punten van een scannerexport, en alle acht kunt u in een voorbeeldrapport controleren voordat u een review tekent.
| Signaal | Scannerexport of zwak rapport | Beslisklaar rapport |
|---|---|---|
| Bewijs | Patroonherkenning, geen bewijs dat het probleem bereikbaar is | Reproductiestappen of een testresultaat per bevinding |
| Zakelijke impact | Algemene risicotekst per regel | Impact op uw gebruikers, gegevens, geld of contracten |
| Dubbelingen | Hetzelfde probleem één keer per bestand vermeld | Gebundeld in één bevinding met alle locaties |
| False positives | Blijven in de lijst staan | Verwijderd, of gemarkeerd als “niet bevestigd” met de reden |
| Grenzen | Niet vermeld | Gebieden buiten de scope opgesomd |
| Herstelvolgorde | Gesorteerd op toolscore | Geprioriteerd ten opzichte van uw data |
| Samenvatting | Geen, of alleen een grafiek | Een oordeel in gewone taal op pagina één |
| Hertestpad | Geen | Statusveld en hertestlog |
Geautomatiseerde scans blijven input voor de review, niet de uitkomst ervan. Wij raden aan elke reviewer om één voorbeeldbevinding met alle negen velden te vragen voordat u tekent; een voorbeeld zonder bewijs of zakelijke impact voorspelt een volledig rapport zonder die velden.
Code audit-rapport, security assessment-rapport en pentestrapport vergeleken
Een code audit-rapport, een security assessment-rapport en een penetratietestrapport beantwoorden verschillende vragen, dus het ene kan het andere niet vervangen in een vragenlijst van een klant. NIST SP 800-115, de technische gids van het Amerikaanse National Institute of Standards and Technology voor securitytests en -beoordelingen, scheidt reviewtechnieken van technieken die kwetsbaarheden in het doelsysteem valideren, zoals penetratietesten — dezelfde grens die de twee documenten scheidt.
| Rapport | Gebaseerd op | Typisch bewijs | Meestal gevraagd als |
|---|---|---|---|
| Code audit-rapport | Broncode, configuratie en deployment-opzet — engineering en security | Bestand en regel, reproductie met testaccounts, testresultaten | Vóór de lancering, een zakelijke deal, due diligence of een overdracht |
| Security assessment-rapport | Beveiligingsmaatregelen, beleid, configuratie en processen; soms zonder codereview | Gaten in maatregelen ten opzichte van een framework zoals ISO/IEC 27001:2022 Annex A | Een klant, auditor of verzekeraar vraagt hoe security is geregeld |
| Penetratietestrapport | Aanvallen op de draaiende applicatie of het netwerk | Misbruikte paden, aanvalsketens, screenshots | Een klant of toezichthouder vraagt bewijs dat het live systeem aanvallen weerstaat |
Voor een AI-gebouwd product vóór de lancering komt het code audit-rapport meestal eerst, omdat het engineering en security in één herstelvolgorde dekt. Gaat de vraag over hoe het live systeem standhoudt tegen een aanvaller, dan legt de penetratietestgids uit wat een pentestrapport toevoegt.
Hoe Sunbytes rapporteert over een AI-built product review
De toets voor een code audit-rapport is of een beslisser op pagina één kan handelen en een engineer op pagina tien. Die toets bepaalt hoe Sunbytes AI-gebouwde producten beoordeelt.
Sunbytes beoordeelt AI-gebouwde producten binnen een afgesproken scope die de relevante code, architectuur, security, kritieke workflows en deployment-instellingen omvat. Engineers en securityspecialisten onderzoeken hetzelfde product en maken van de bevindingen een geprioriteerd actieplan en een technische overdracht. Herstel en hercontroles kunnen volgen waar nodig, met verantwoordelijkheden en scope die apart worden afgesproken. Zo kunnen founders beslissen wat vóór de lancering moet veranderen, en krijgt hun technische team een praktisch startpunt.
Toegang tot uw code valt onder een ISO/IEC 27001-gecertificeerd managementsysteem voor informatiebeveiliging met governance vanuit Nederland, en de review steunt op meer dan 15 jaar ervaring in softwareontwikkeling en meer dan 300 opgeleverde projecten.
Wilt u dit rapportformat toegepast zien op uw eigen product? Start met een AI-built product review of bespreek uw AI-gebouwde product met ons.
