Er bestaat geen aparte beveiligingsstandaard voor AI-gegenereerde code. Code van een AI-codeassistent, een agent of een AI app builder moet aan dezelfde standaarden voldoen als code die een developer schrijft. AI code security draait daarom om twee beslissingen: aan welke standaard u de code toetst, en hoe u het resultaat aantoont aan een klant, auditor of investeerder.
Het verschil tussen een gevoel van veiligheid en aantoonbare veiligheid is onderzocht. In een gebruikersstudie van Stanford, gepubliceerd op ACM CCS 2023, schreven deelnemers met een AI-codeassistent aantoonbaar minder veilige code dan een controlegroep, terwijl zij vaker dachten dat hun code veilig was (Perry et al., 47 deelnemers).
Dit artikel laat zien hoe de OWASP Top 10:2025 op AI-gebouwde code past, welke standaarden gelden, welke ISO 27001-controls ertoe doen en waar u begint, inclusief het bewijs dat u bewaart. Voor de volledige route van prototype naar lancering leest u AI-gegenereerde code in productie.
TL;DR
AI code security betekent dat code van AI-codetools vrij is van bekende kwetsbaarheidsklassen, en dat u dat kunt aantonen. Geen enkele standaard is alleen voor AI-gegenereerde code geschreven: OWASP en ISO/IEC 27001 gelden voor die code precies zoals voor code van een developer.
- De OWASP Top 10:2025 geeft AI-gebouwde code een gedeelde lijst van tien risicocategorieën; A01 Broken Access Control, A02 Security Misconfiguration en A03 Software Supply Chain Failures controleert u als eerste in een AI-gebouwd product.
- Drie standaarden beantwoorden de meeste klantvragen: OWASP ASVS 5.0 als toetsbare standaard voor veilig programmeren, de OWASP Top 10:2025 als gedeeld vocabulaire en ISO/IEC 27001:2022 Annex A als bewijs op organisatieniveau.
- ISO/IEC 27001:2022 Annex A 8.28 “Secure coding” geldt ook voor door AI geschreven code; controls 8.30 (uitbestede ontwikkeling) en 8.4 (toegang tot broncode) bepalen hoe u AI-codetools aanstuurt en wat u met ze deelt.
- Een product met persoonsgegevens van echte gebruikers start op ASVS Level 1, gebruikt Level 2 voor inloggen, toegangscontrole en gegevensverwerking, en houdt een startpakket van zes bewijsstukken bij.
Wat AI code security betekent
AI code security is het vrijhouden van code uit AI-codetools — assistenten, agents en AI app builders — van bekende kwetsbaarheidsklassen, en het kunnen aantonen daarvan. De standaarden zijn dezelfde als voor elke webapplicatie. Drie dingen veranderen wanneer een AI-tool de code schrijft.
- Volume. AI-codetools kunnen het aantal wijzigingen sterk verhogen, waardoor review op basis van risico en geautomatiseerde controles belangrijker worden.
- Context. De tool kent uw datamodel, gebruikersrollen en dreigingsmodel niet, tenzij iemand ze vastlegt. Regels die van uw bedrijf afhangen — wie welk record mag zien — laat u dan aan de gok van de tool over.
- Bewijs. De redenering achter beveiligingskeuzes van een AI-tool is vaak niet vastgelegd of niet begrepen door het team, dus het bewijs moet uit tests en reviews komen in plaats van uit het geheugen van een developer.
De kwetsbaarheden zelf zijn goed beschreven; vibe coding-beveiligingsrisico’s behandelt de zeven die in AI-gebouwde apps het zwaarst wegen. Een benoemde standaard zoals ISO/IEC 27001:2022 Annex A 8.28 voegt een referentie toe waaraan een klant of auditor de code kan toetsen.
De OWASP Top 10:2025 toegepast op AI-gegenereerde code
De OWASP Top 10:2025 geldt zonder aanpassing voor AI-gegenereerde code: de tien categorieën beschrijven wat er misgaat in webapplicaties, wie de code ook schreef. OWASP noemt de lijst zelf “a standard awareness document for developers and web application security” — een gedeeld vocabulaire, geen test waarvoor u slaagt (OWASP Top 10:2025).
Tabel 1 koppelt elke categorie uit 2025 aan de manier waarop die meestal in een AI-gebouwd product opduikt, met één vraag die een niet-technische eigenaar aan de developer kan stellen.
| Categorie (OWASP Top 10:2025) | Hoe het meestal opduikt in AI-gebouwde code | Vraag aan uw developer |
|---|---|---|
| A01 Broken Access Control | Pagina’s en API-routes controleren of iemand is ingelogd, niet of het record van die gebruiker is | Kan gebruiker A het record van gebruiker B openen door een ID in de URL te wijzigen? |
| A02 Security Misconfiguration | Debugmodus, open databaseregels of ruime cross-origin-instellingen uit het prototype | Welke instellingen zijn veranderd tussen prototype en productie? |
| A03 Software Supply Chain Failures | Packages zonder review toegevoegd, inclusief namen die de AI-tool voorstelde en die mogelijk niet bestaan | Wie keurde elke dependency goed, en wordt elke dependency gescand? |
| A04 Cryptographic Failures | Tokens of sleutels in frontendcode of als platte tekst opgeslagen | Waar staan API-sleutels, wachtwoorden en tokens? |
| A05 Injection | Gebruikersinvoer zonder validatie doorgegeven aan databasequeries, shellcommando’s of modelprompts | Wordt elke invoer op de server gevalideerd, niet alleen in de browser? |
| A06 Insecure Design | Bedrijfsregels zoals terugbetalingen, rollen en limieten staan alleen in prompts en zijn nooit vastgelegd | Waar staat de regel wie wat mag doen? |
| A07 Authentication Failures | Inlog-, sessie- en wachtwoordresetflows in één keer gegenereerd en nooit op misbruik getest | Is inloggen beperkt in aantal pogingen, en worden sessies ingetrokken bij uitloggen? |
| A08 Software or Data Integrity Failures | Webhooks zonder verificatie geaccepteerd; een buildpipeline die iedereen in het team kan wijzigen | Worden webhooks geverifieerd, en wie kan de pipeline wijzigen? |
| A09 Security Logging and Alerting Failures | Geen registratie van wie welke gegevens heeft ingezien | Zou iemand het merken als vannacht alle klantgegevens zijn gedownload? |
| A10 Mishandling of Exceptional Conditions | Foutmeldingen die stack traces tonen of een verzoek doorlaten als een dienst uitvalt | Wat doet de app als de database of betaalprovider niet reageert? |
Twee rijen verdienen een eigen herstelgids. Sleutels in frontendcode (A02 en A04) behandelt gelekte API-keys in AI-producten stap voor stap. Verzonnen packagenamen (A03) worden uitgelegd in de Sunbytes-gids over AI code review.
Wij raden aan A01, A02 en A03 als eerste te controleren in elk AI-gebouwd product met gegevens van echte gebruikers. A01 staat bovenaan in de ranglijst van 2025, Security Misconfiguration steeg van de vijfde plaats in 2021 naar de tweede, en Software Supply Chain Failures is een nieuwe categorie uit 2025 die voortbouwt op het eerdere “Vulnerable and Outdated Components” (OWASP Top 10:2025).
Welke beveiligingsstandaarden gelden voor AI-gegenereerde code?
Zes documenten dekken de beveiligingsvragen waar een AI-gebouwd product mee te maken krijgt: drie van OWASP voor de applicatie, één van OWASP voor AI-functies, ISO/IEC 27001:2022 voor de organisatie en het NIST Secure Software Development Framework voor vragenlijsten naar Amerikaans model. Geen ervan is specifiek voor AI-code, en geen ervan is een wet. Tabel 2 toont wat elk document een AI-gebouwd product oplevert en wanneer u het nodig hebt.
| Standaard | Wat het is | Wat het een AI-gebouwd product oplevert | Wanneer u het nodig hebt |
|---|---|---|---|
| OWASP Top 10:2025 | Awareness-document met tien risicocategorieën voor webapplicaties | Een gedeeld vocabulaire voor briefings, prompts en beveiligingsvragenlijsten | Vanaf het eerste prototype |
| OWASP ASVS 5.0.0 | Verificatiestandaard met genummerde eisen op drie niveaus; uitgebracht op 30 mei 2025 | Eisen die een reviewer als geslaagd of gezakt kan markeren, en een benoembare lat | Zodra echte gebruikers of klanten van het product afhangen |
| OWASP Developer Guide | Richtlijnen en checklists voor developers, inclusief de voormalige Secure Coding Practices-checklist | Een checklist voor wie de code schrijft of prompt | Wanneer een developer instapt of het werk overneemt |
| OWASP Top 10 for LLM Applications 2025 | Tien risico’s voor applicaties die een taalmodel aanroepen | Namen voor prompt injection, datalekken en ontsporende modelkosten | Alleen als het product tijdens gebruik een model aanroept |
| ISO/IEC 27001:2022 Annex A 8.25–8.29 | Controls van een managementsysteem voor informatiebeveiliging (ISMS) | Bewijs op organisatieniveau dat veilige ontwikkeling is vastgelegd, toegepast en getest | Als een klant, aanbesteding of uw eigen certificeringsplan erom vraagt |
| NIST SP 800-218 (SSDF 1.1) en SP 800-218A | Amerikaans Secure Software Development Framework (feb. 2022); 800-218A voegt praktijken voor generatieve AI toe (jul. 2024) | Een lijst met praktijken waar veel enterprise-vragenlijsten naar verwijzen | Als Amerikaanse of enterprise-klanten naar SSDF verwijzen |
Wij raden de OWASP Top 10:2025 aan als gedeeld vocabulaire en ASVS Level 1 als ondergrens voor elk AI-gebouwd product met echte gebruikers. Voeg ISO/IEC 27001:2022 Annex A toe zodra een klant of een certificeringsplan bewijs over de organisatie vraagt, en de LLM Top 10 alleen als het product gebruikersinvoer naar een model stuurt.
OWASP-standaarden voor veilig programmeren: ASVS en de Developer Guide
Het OWASP-document dat werkt als standaard voor veilig programmeren is de Application Security Verification Standard (ASVS). De Top 10 vat risico’s samen; ASVS geeft eisen die een reviewer als geslaagd of gezakt kan markeren. ASVS 5.0.0, uitgebracht op 30 mei 2025, nummert elke eis als hoofdstuk.sectie.eis, zodat een bevinding naar een exacte regel in de standaard kan verwijzen (OWASP ASVS).
ASVS kent drie niveaus. Level 1 is de basis waaraan elke applicatie moet voldoen, Level 2 past bij applicaties met persoonsgegevens of bedrijfsgevoelige gegevens, en Level 3 is bedoeld voor systemen met de hoogste zekerheidseisen. Wij raden Level 2 aan voor inloggen, toegangscontrole en de verwerking van persoonsgegevens zodra echte gebruikers het product gebruiken, omdat één gemiste regel daar gegevens van anderen blootlegt.
ASVS gebruiken met AI-codetools
- Zet eis-ID’s in de taak. Neem de relevante ASVS-eisnummers als acceptatiecriteria op in de prompt of het ticket.
- Review op de ID’s. Laat de reviewer per eis-ID vastleggen: geslaagd, gezakt of niet van toepassing — geen algemeen “ziet er goed uit”.
- Bewaar het resultaat. Sla het reviewverslag op bij de bijbehorende release; dat verslag is het bewijs waar een klant om vraagt.
OWASP-checklist voor veilig programmeren
De OWASP Secure Coding Practices Quick Reference Guide, lang gebruikt als checklist voor veilig programmeren, is inmiddels gearchiveerd. OWASP meldt dat de “checklists have also been migrated to the Developer Guide”; nieuwe projecten gebruiken dus de checklists in de OWASP Developer Guide (projectpagina OWASP Secure Coding Practices). De Developer Guide vertelt wie de code schrijft of prompt wat er moet gebeuren; ASVS vertelt de reviewer wat er gecontroleerd moet worden.
Vroeg een klant welke standaard uw code volgt?
Een AI-built product review controleert de onderdelen waar beveiligingsvragenlijsten naar vragen — toegang tot data, inloggen, secrets en dependencies — en levert bevindingen met het bewijs erachter. De review staat los van herstelwerk, en u krijgt de resultaten in begrijpelijke taal met een geprioriteerd actieplan dat u bij uw antwoord kunt voegen.
ISO 27001 en veilig programmeren: wat Annex A 8.28 vraagt als AI de code schrijft
ISO/IEC 27001:2022 Annex A 8.28 “Secure coding” vereist dat principes voor veilig programmeren worden toegepast bij softwareontwikkeling. De control schrijft geen regels op codeniveau voor; de organisatie kiest en documenteert zelf een set, en een benoemde OWASP-standaard zoals ASVS is een gangbare keuze. Annex A 8.28 geldt voor door AI geschreven code op dezelfde manier als voor code van een developer: de tool is niet uitgezonderd, en de persoon die de output accepteert evenmin.
Twee andere controls bepalen hoe AI-codetools in een ISMS passen. Annex A 8.30 “Outsourced development” vraagt de organisatie om ontwikkeling buiten het eigen team aan te sturen, te bewaken en te beoordelen; een praktische lezing is een AI-codetool te behandelen als een externe developer, wiens werk wordt gespecificeerd, gereviewd en goedgekeurd vóór de release. Annex A 8.4 “Access to source code” bepaalt welke code, sleutels en gegevens in een AI-tool geplakt mogen worden, en onder welke accountinstellingen.
| Annex A-control | Wat verandert als een AI-tool de code schrijft | Bewijs om te bewaren |
|---|---|---|
| 8.25 Secure development life cycle | De ontwikkelprocedure noemt de gebruikte AI-tools en wie hun output reviewt | Vastgelegde ontwikkelprocedure |
| 8.26 Application security requirements | Beveiligingseisen staan in prompts en tickets, bijvoorbeeld als ASVS-ID’s | Tickets met eis-ID’s |
| 8.27 Secure system architecture and engineering principles | Architectuurkeuzes van de tool worden achteraf vastgelegd | Korte architectuurnotities |
| 8.28 Secure coding | Een benoemde standaard (bijvoorbeeld ASVS 5.0) en een review van AI-output daartegen | Reviewverslag per eis |
| 8.29 Security testing in development and acceptance | Tests dekken toegangscontrole en misbruikscenario’s, niet alleen “de functie werkt” | Testresultaten per release |
| 8.30 Outsourced development | De AI-tool wordt aangestuurd, bewaakt en gereviewd als een externe developer | Review- en goedkeuringsverslagen |
| 8.4 Access to source code | Regels over welke code, sleutels en gegevens met AI-tools gedeeld mogen worden | Toolinstellingen en één vastgelegde regel |
Een ISO 27001-certificaat dekt het ISMS van een organisatie, niet de beveiliging van een specifieke codebase; wat ISO 27001-certificering betekent voor appontwikkeling legt uit wat het certificaat wel en niet aantoont. Vraagt een auditor “welke standaard voor veilig programmeren past u toe?”, dan is het antwoord een documentnaam met versie — bijvoorbeeld “OWASP ASVS 5.0.0, Level 1, Level 2 voor authenticatie en toegangscontrole” — en niet “best practices”.
Als uw app AI-functies heeft: de OWASP Top 10 for LLM Applications
Producten die tijdens gebruik een taalmodel aanroepen — een chatbot, zoeken in documenten of een agent — hebben een tweede lijst nodig: de OWASP Top 10 for LLM Applications 2025 (OWASP GenAI Security Project). De lijst gaat over functies die gebruikersinvoer naar een model sturen, niet over code die een AI-tool schreef. Vier onderdelen wegen het zwaarst voor een klein team:
- LLM01 Prompt Injection — tekst van een gebruiker of uit een document verandert de instructies van het model.
- LLM02 Sensitive Information Disclosure — het model geeft gegevens terug die de gebruiker niet mag zien.
- LLM06 Excessive Agency — het model kan zonder grenzen e-mails versturen, records wijzigen of tools aanroepen.
- LLM10 Unbounded Consumption — geen limiet op verzoeken of kosten, zodat één gebruiker de modelrekening kan opdrijven.
De andere zes zijn LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses en LLM09 Misinformation. Voor teams die modellen bouwen of aanpassen voegt NIST SP 800-218A (juli 2024) praktijken voor generatieve AI toe aan het SSDF. De modelcontroles vóór de lancering — minimale rechten, een prompt-injectietest en een kostenplafond — staan in de production readiness checklist.
Europese regels die naar deze standaarden wijzen
Geen Europese wet noemt OWASP of maakt ISO 27001 verplicht voor een AI-gebouwd product, maar drie EU-regels vragen beveiligingsmaatregelen die u met een benoemde standaard kunt aantonen.
- AVG (GDPR) artikel 32 vereist “passende technische en organisatorische maatregelen” voor persoonsgegevens, en artikel 25 vraagt gegevensbescherming door ontwerp en door standaardinstellingen. Een benoemde standaard zoals ASVS laat zien wat “passend” betekende; in Nederland houdt de Autoriteit Persoonsgegevens toezicht.
- NIS2 artikel 21, lid 2, onder e gaat over beveiliging bij de aanschaf, ontwikkeling en het onderhoud van netwerk- en informatiesystemen, inclusief de behandeling van kwetsbaarheden. Nederland heeft NIS2 omgezet in de Cyberbeveiligingswet, die sinds 15 augustus 2026 van kracht is (Staatsblad 2026, 187). Organisaties die eronder vallen, leggen deze eisen via contracten bij hun softwareleveranciers.
- De Cyberweerbaarheidsverordening (Cyber Resilience Act) (Verordening (EU) 2024/2847) geldt voor producten met digitale elementen, zoals installeerbare software en mobiele apps. De meldplichten gelden vanaf 11 september 2026 en de hoofdverplichtingen vanaf 11 december 2027. Software die puur als dienst wordt geleverd valt er doorgaans buiten, tenzij het gaat om gegevensverwerking op afstand die een gedekt product nodig heeft om te werken.
De EU AI-verordening reguleert AI-systemen, niet de code die een AI-tool voor u schrijft. Voor een SaaS-product zonder NIS2-klanten is AVG artikel 32 de regel die als eerste geldt; valt u of een klant onder NIS2, of verkoopt u een installeerbare app in de EU, dan komen de andere twee erbij.
Met welke standaard begint u?
De juiste startstandaard hangt af van wie de vraag stelt en welke gegevens het product bevat. Tabel 4 geeft het startpunt voor zes veelvoorkomende situaties van een AI-gebouwd product.
| Situatie | Begin met | Voeg toe wanneer |
|---|---|---|
| Interne tool of prototype met testdata | Bewustzijn van de OWASP Top 10:2025, secret scanning en dependency scanning | Echte gebruikers of echte gegevens komen erbij |
| Persoonsgegevens of betalingen van echte gebruikers | ASVS 5.0 Level 1 overal; Level 2 voor inloggen, toegangscontrole en gegevensverwerking | Een klant stuurt een beveiligingsvragenlijst |
| Beveiligingsvragenlijst van een enterprise-klant | ASVS-reviewverslag plus de Top 10-koppeling als bewijs | De klant vraagt om ISO 27001 of SOC 2 |
| ISO 27001-gecertificeerde klant, of uw eigen certificeringsplan | Procedures voor Annex A 8.25–8.30 met ASVS als benoemde standaard voor veilig programmeren | Een auditor plant een stage 1-audit |
| Product roept tijdens gebruik een AI-model aan | OWASP Top 10 for LLM Applications 2025 bovenop ASVS | Agents krijgen rechten om gegevens te wijzigen |
| Uw organisatie of klant valt onder NIS2; installeerbare app verkocht in de EU | Bewijs voor NIS2 artikel 21, lid 2, onder e en de CRA, opgebouwd uit dezelfde ASVS- en ISO-verslagen | De hoofdverplichtingen van de CRA gelden vanaf 11 december 2027 |
Wij raden af om met ISO 27001-certificering te beginnen om de vragenlijst van één klant te beantwoorden. De vragenlijst gaat over het product, en een reviewverslag op basis van ASVS beantwoordt die vraag direct, terwijl certificering de hele organisatie betreft en een volledige auditcyclus kost.
Welk bewijs u een klant of auditor laat zien
Een klant of auditor accepteert bewijs dat de standaard noemt, het resultaat toont en een datum heeft. Voor een AI-gebouwd product vormen deze zes stukken een praktisch startpakket; individuele klanten kunnen aanvullend bewijs vragen:
- Benoemde basislijn — bijvoorbeeld “OWASP ASVS 5.0.0 Level 1, Level 2 voor authenticatie en toegangscontrole”.
- Geautomatiseerde resultaten — statische analyse (SAST: een scan van de broncode op bekende zwakke patronen), software composition analysis (SCA: een scan van externe packages op bekende kwetsbaarheden) en secret scanning, allemaal van de release die de klant beoordeelt.
- Verslag van de menselijke review — wie reviewde, wanneer, en geslaagd of gezakt per eis-ID; de gids over AI code review legt uit hoe u die review uitvoert.
- Verslag van beveiligingstests — tests op toegangscontrole en misbruikscenario’s voor Annex A 8.29, inclusief een test dat de ene gebruiker de gegevens van een andere niet kan openen.
- Openstaande bevindingen — elk met een eigenaar en een streefdatum.
- Overzicht van AI-tools — één regel met de gebruikte AI-codetools en de Annex A 8.4-regel over wat met ze gedeeld mag worden. Teambrede regels voor AI-tools komen aan bod in AI code governance.
Scans van het prototype blijven bruikbaar als historisch bewijs, maar vervangen geen controles op de release die wordt beoordeeld. Is een verslag ouder dan die release, voer de controle dan opnieuw uit voordat u het pakket verstuurt.
Hoe Sunbytes AI-gebouwde producten beoordeelt voor beveiligingsvragen
Een beveiligingsstandaard maakt van “we denken dat de code veilig is” een lijst die een klant kan controleren. AI-codetools kunnen de code schrijven en de scanners draaien; een persoon moet het product nog steeds tegen die lijst toetsen.
De AI-built product review van Sunbytes helpt teams te zien waar de beveiligingsmaatregelen, de code en de technische opzet van hun product aandacht nodig hebben vóór de lancering of breder gebruik. De review begint met een afgesproken scope over de relevante onderdelen: beveiliging, architectuur, kritieke workflows, deployment en onderhoudbaarheid. Bevindingen uit engineering en security worden in begrijpelijke taal uitgelegd, met onderbouwend bewijs en een geprioriteerd actieplan.
Vraagt een klant om verificatie tegen specifieke OWASP ASVS-eisen of om een aparte beveiligingsbeoordeling, dan legt u die eisen vast tijdens het afbakenen van de scope. Zo blijft het bewijs gericht op de vraag van de klant, zonder dat een algemene productreview als certificering wordt gepresenteerd.
Voor een controle van alleen de beveiliging van de code zelf voert het cybersecurityteam van Sunbytes een secure code review uit. Beide diensten vallen onder het ISO/IEC 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes en steunen op ruim 300 opgeleverde projecten.
Wacht een beveiligingsvragenlijst of een lanceringsdatum op dit antwoord? Start met een AI-built product review.
Er bestaat geen aparte beveiligingsstandaard voor AI-gegenereerde code. Code van een AI-codeassistent, een agent of een AI app builder moet aan dezelfde standaarden voldoen als code die een developer schrijft. AI code security draait daarom om twee beslissingen: aan welke standaard u de code toetst, en hoe u het resultaat aantoont aan een klant, auditor of investeerder.
Het verschil tussen een gevoel van veiligheid en aantoonbare veiligheid is onderzocht. In een gebruikersstudie van Stanford, gepubliceerd op ACM CCS 2023, schreven deelnemers met een AI-codeassistent aantoonbaar minder veilige code dan een controlegroep, terwijl zij vaker dachten dat hun code veilig was (Perry et al., 47 deelnemers).
Dit artikel laat zien hoe de OWASP Top 10:2025 op AI-gebouwde code past, welke standaarden gelden, welke ISO 27001-controls ertoe doen en waar u begint, inclusief het bewijs dat u bewaart. Voor de volledige route van prototype naar lancering leest u AI-gegenereerde code in productie.
TL;DR
AI code security betekent dat code van AI-codetools vrij is van bekende kwetsbaarheidsklassen, en dat u dat kunt aantonen. Geen enkele standaard is alleen voor AI-gegenereerde code geschreven: OWASP en ISO/IEC 27001 gelden voor die code precies zoals voor code van een developer.
- De OWASP Top 10:2025 geeft AI-gebouwde code een gedeelde lijst van tien risicocategorieën; A01 Broken Access Control, A02 Security Misconfiguration en A03 Software Supply Chain Failures controleert u als eerste in een AI-gebouwd product.
- Drie standaarden beantwoorden de meeste klantvragen: OWASP ASVS 5.0 als toetsbare standaard voor veilig programmeren, de OWASP Top 10:2025 als gedeeld vocabulaire en ISO/IEC 27001:2022 Annex A als bewijs op organisatieniveau.
- ISO/IEC 27001:2022 Annex A 8.28 “Secure coding” geldt ook voor door AI geschreven code; controls 8.30 (uitbestede ontwikkeling) en 8.4 (toegang tot broncode) bepalen hoe u AI-codetools aanstuurt en wat u met ze deelt.
- Een product met persoonsgegevens van echte gebruikers start op ASVS Level 1, gebruikt Level 2 voor inloggen, toegangscontrole en gegevensverwerking, en houdt een startpakket van zes bewijsstukken bij.
Wat AI code security betekent
AI code security is het vrijhouden van code uit AI-codetools — assistenten, agents en AI app builders — van bekende kwetsbaarheidsklassen, en het kunnen aantonen daarvan. De standaarden zijn dezelfde als voor elke webapplicatie. Drie dingen veranderen wanneer een AI-tool de code schrijft.
- Volume. AI-codetools kunnen het aantal wijzigingen sterk verhogen, waardoor review op basis van risico en geautomatiseerde controles belangrijker worden.
- Context. De tool kent uw datamodel, gebruikersrollen en dreigingsmodel niet, tenzij iemand ze vastlegt. Regels die van uw bedrijf afhangen — wie welk record mag zien — laat u dan aan de gok van de tool over.
- Bewijs. De redenering achter beveiligingskeuzes van een AI-tool is vaak niet vastgelegd of niet begrepen door het team, dus het bewijs moet uit tests en reviews komen in plaats van uit het geheugen van een developer.
De kwetsbaarheden zelf zijn goed beschreven; vibe coding-beveiligingsrisico’s behandelt de zeven die in AI-gebouwde apps het zwaarst wegen. Een benoemde standaard zoals ISO/IEC 27001:2022 Annex A 8.28 voegt een referentie toe waaraan een klant of auditor de code kan toetsen.
De OWASP Top 10:2025 toegepast op AI-gegenereerde code
De OWASP Top 10:2025 geldt zonder aanpassing voor AI-gegenereerde code: de tien categorieën beschrijven wat er misgaat in webapplicaties, wie de code ook schreef. OWASP noemt de lijst zelf “a standard awareness document for developers and web application security” — een gedeeld vocabulaire, geen test waarvoor u slaagt (OWASP Top 10:2025).
Tabel 1 koppelt elke categorie uit 2025 aan de manier waarop die meestal in een AI-gebouwd product opduikt, met één vraag die een niet-technische eigenaar aan de developer kan stellen.
| Categorie (OWASP Top 10:2025) | Hoe het meestal opduikt in AI-gebouwde code | Vraag aan uw developer |
|---|---|---|
| A01 Broken Access Control | Pagina’s en API-routes controleren of iemand is ingelogd, niet of het record van die gebruiker is | Kan gebruiker A het record van gebruiker B openen door een ID in de URL te wijzigen? |
| A02 Security Misconfiguration | Debugmodus, open databaseregels of ruime cross-origin-instellingen uit het prototype | Welke instellingen zijn veranderd tussen prototype en productie? |
| A03 Software Supply Chain Failures | Packages zonder review toegevoegd, inclusief namen die de AI-tool voorstelde en die mogelijk niet bestaan | Wie keurde elke dependency goed, en wordt elke dependency gescand? |
| A04 Cryptographic Failures | Tokens of sleutels in frontendcode of als platte tekst opgeslagen | Waar staan API-sleutels, wachtwoorden en tokens? |
| A05 Injection | Gebruikersinvoer zonder validatie doorgegeven aan databasequeries, shellcommando’s of modelprompts | Wordt elke invoer op de server gevalideerd, niet alleen in de browser? |
| A06 Insecure Design | Bedrijfsregels zoals terugbetalingen, rollen en limieten staan alleen in prompts en zijn nooit vastgelegd | Waar staat de regel wie wat mag doen? |
| A07 Authentication Failures | Inlog-, sessie- en wachtwoordresetflows in één keer gegenereerd en nooit op misbruik getest | Is inloggen beperkt in aantal pogingen, en worden sessies ingetrokken bij uitloggen? |
| A08 Software or Data Integrity Failures | Webhooks zonder verificatie geaccepteerd; een buildpipeline die iedereen in het team kan wijzigen | Worden webhooks geverifieerd, en wie kan de pipeline wijzigen? |
| A09 Security Logging and Alerting Failures | Geen registratie van wie welke gegevens heeft ingezien | Zou iemand het merken als vannacht alle klantgegevens zijn gedownload? |
| A10 Mishandling of Exceptional Conditions | Foutmeldingen die stack traces tonen of een verzoek doorlaten als een dienst uitvalt | Wat doet de app als de database of betaalprovider niet reageert? |
Twee rijen verdienen een eigen herstelgids. Sleutels in frontendcode (A02 en A04) behandelt gelekte API-keys in AI-producten stap voor stap. Verzonnen packagenamen (A03) worden uitgelegd in de Sunbytes-gids over AI code review.
Wij raden aan A01, A02 en A03 als eerste te controleren in elk AI-gebouwd product met gegevens van echte gebruikers. A01 staat bovenaan in de ranglijst van 2025, Security Misconfiguration steeg van de vijfde plaats in 2021 naar de tweede, en Software Supply Chain Failures is een nieuwe categorie uit 2025 die voortbouwt op het eerdere “Vulnerable and Outdated Components” (OWASP Top 10:2025).
Welke beveiligingsstandaarden gelden voor AI-gegenereerde code?
Zes documenten dekken de beveiligingsvragen waar een AI-gebouwd product mee te maken krijgt: drie van OWASP voor de applicatie, één van OWASP voor AI-functies, ISO/IEC 27001:2022 voor de organisatie en het NIST Secure Software Development Framework voor vragenlijsten naar Amerikaans model. Geen ervan is specifiek voor AI-code, en geen ervan is een wet. Tabel 2 toont wat elk document een AI-gebouwd product oplevert en wanneer u het nodig hebt.
| Standaard | Wat het is | Wat het een AI-gebouwd product oplevert | Wanneer u het nodig hebt |
|---|---|---|---|
| OWASP Top 10:2025 | Awareness-document met tien risicocategorieën voor webapplicaties | Een gedeeld vocabulaire voor briefings, prompts en beveiligingsvragenlijsten | Vanaf het eerste prototype |
| OWASP ASVS 5.0.0 | Verificatiestandaard met genummerde eisen op drie niveaus; uitgebracht op 30 mei 2025 | Eisen die een reviewer als geslaagd of gezakt kan markeren, en een benoembare lat | Zodra echte gebruikers of klanten van het product afhangen |
| OWASP Developer Guide | Richtlijnen en checklists voor developers, inclusief de voormalige Secure Coding Practices-checklist | Een checklist voor wie de code schrijft of prompt | Wanneer een developer instapt of het werk overneemt |
| OWASP Top 10 for LLM Applications 2025 | Tien risico’s voor applicaties die een taalmodel aanroepen | Namen voor prompt injection, datalekken en ontsporende modelkosten | Alleen als het product tijdens gebruik een model aanroept |
| ISO/IEC 27001:2022 Annex A 8.25–8.29 | Controls van een managementsysteem voor informatiebeveiliging (ISMS) | Bewijs op organisatieniveau dat veilige ontwikkeling is vastgelegd, toegepast en getest | Als een klant, aanbesteding of uw eigen certificeringsplan erom vraagt |
| NIST SP 800-218 (SSDF 1.1) en SP 800-218A | Amerikaans Secure Software Development Framework (feb. 2022); 800-218A voegt praktijken voor generatieve AI toe (jul. 2024) | Een lijst met praktijken waar veel enterprise-vragenlijsten naar verwijzen | Als Amerikaanse of enterprise-klanten naar SSDF verwijzen |
Wij raden de OWASP Top 10:2025 aan als gedeeld vocabulaire en ASVS Level 1 als ondergrens voor elk AI-gebouwd product met echte gebruikers. Voeg ISO/IEC 27001:2022 Annex A toe zodra een klant of een certificeringsplan bewijs over de organisatie vraagt, en de LLM Top 10 alleen als het product gebruikersinvoer naar een model stuurt.
OWASP-standaarden voor veilig programmeren: ASVS en de Developer Guide
Het OWASP-document dat werkt als standaard voor veilig programmeren is de Application Security Verification Standard (ASVS). De Top 10 vat risico’s samen; ASVS geeft eisen die een reviewer als geslaagd of gezakt kan markeren. ASVS 5.0.0, uitgebracht op 30 mei 2025, nummert elke eis als hoofdstuk.sectie.eis, zodat een bevinding naar een exacte regel in de standaard kan verwijzen (OWASP ASVS).
ASVS kent drie niveaus. Level 1 is de basis waaraan elke applicatie moet voldoen, Level 2 past bij applicaties met persoonsgegevens of bedrijfsgevoelige gegevens, en Level 3 is bedoeld voor systemen met de hoogste zekerheidseisen. Wij raden Level 2 aan voor inloggen, toegangscontrole en de verwerking van persoonsgegevens zodra echte gebruikers het product gebruiken, omdat één gemiste regel daar gegevens van anderen blootlegt.
ASVS gebruiken met AI-codetools
- Zet eis-ID’s in de taak. Neem de relevante ASVS-eisnummers als acceptatiecriteria op in de prompt of het ticket.
- Review op de ID’s. Laat de reviewer per eis-ID vastleggen: geslaagd, gezakt of niet van toepassing — geen algemeen “ziet er goed uit”.
- Bewaar het resultaat. Sla het reviewverslag op bij de bijbehorende release; dat verslag is het bewijs waar een klant om vraagt.
OWASP-checklist voor veilig programmeren
De OWASP Secure Coding Practices Quick Reference Guide, lang gebruikt als checklist voor veilig programmeren, is inmiddels gearchiveerd. OWASP meldt dat de “checklists have also been migrated to the Developer Guide”; nieuwe projecten gebruiken dus de checklists in de OWASP Developer Guide (projectpagina OWASP Secure Coding Practices). De Developer Guide vertelt wie de code schrijft of prompt wat er moet gebeuren; ASVS vertelt de reviewer wat er gecontroleerd moet worden.
Vroeg een klant welke standaard uw code volgt?
Een AI-built product review controleert de onderdelen waar beveiligingsvragenlijsten naar vragen — toegang tot data, inloggen, secrets en dependencies — en levert bevindingen met het bewijs erachter. De review staat los van herstelwerk, en u krijgt de resultaten in begrijpelijke taal met een geprioriteerd actieplan dat u bij uw antwoord kunt voegen.
ISO 27001 en veilig programmeren: wat Annex A 8.28 vraagt als AI de code schrijft
ISO/IEC 27001:2022 Annex A 8.28 “Secure coding” vereist dat principes voor veilig programmeren worden toegepast bij softwareontwikkeling. De control schrijft geen regels op codeniveau voor; de organisatie kiest en documenteert zelf een set, en een benoemde OWASP-standaard zoals ASVS is een gangbare keuze. Annex A 8.28 geldt voor door AI geschreven code op dezelfde manier als voor code van een developer: de tool is niet uitgezonderd, en de persoon die de output accepteert evenmin.
Twee andere controls bepalen hoe AI-codetools in een ISMS passen. Annex A 8.30 “Outsourced development” vraagt de organisatie om ontwikkeling buiten het eigen team aan te sturen, te bewaken en te beoordelen; een praktische lezing is een AI-codetool te behandelen als een externe developer, wiens werk wordt gespecificeerd, gereviewd en goedgekeurd vóór de release. Annex A 8.4 “Access to source code” bepaalt welke code, sleutels en gegevens in een AI-tool geplakt mogen worden, en onder welke accountinstellingen.
| Annex A-control | Wat verandert als een AI-tool de code schrijft | Bewijs om te bewaren |
|---|---|---|
| 8.25 Secure development life cycle | De ontwikkelprocedure noemt de gebruikte AI-tools en wie hun output reviewt | Vastgelegde ontwikkelprocedure |
| 8.26 Application security requirements | Beveiligingseisen staan in prompts en tickets, bijvoorbeeld als ASVS-ID’s | Tickets met eis-ID’s |
| 8.27 Secure system architecture and engineering principles | Architectuurkeuzes van de tool worden achteraf vastgelegd | Korte architectuurnotities |
| 8.28 Secure coding | Een benoemde standaard (bijvoorbeeld ASVS 5.0) en een review van AI-output daartegen | Reviewverslag per eis |
| 8.29 Security testing in development and acceptance | Tests dekken toegangscontrole en misbruikscenario’s, niet alleen “de functie werkt” | Testresultaten per release |
| 8.30 Outsourced development | De AI-tool wordt aangestuurd, bewaakt en gereviewd als een externe developer | Review- en goedkeuringsverslagen |
| 8.4 Access to source code | Regels over welke code, sleutels en gegevens met AI-tools gedeeld mogen worden | Toolinstellingen en één vastgelegde regel |
Een ISO 27001-certificaat dekt het ISMS van een organisatie, niet de beveiliging van een specifieke codebase; wat ISO 27001-certificering betekent voor appontwikkeling legt uit wat het certificaat wel en niet aantoont. Vraagt een auditor “welke standaard voor veilig programmeren past u toe?”, dan is het antwoord een documentnaam met versie — bijvoorbeeld “OWASP ASVS 5.0.0, Level 1, Level 2 voor authenticatie en toegangscontrole” — en niet “best practices”.
Als uw app AI-functies heeft: de OWASP Top 10 for LLM Applications
Producten die tijdens gebruik een taalmodel aanroepen — een chatbot, zoeken in documenten of een agent — hebben een tweede lijst nodig: de OWASP Top 10 for LLM Applications 2025 (OWASP GenAI Security Project). De lijst gaat over functies die gebruikersinvoer naar een model sturen, niet over code die een AI-tool schreef. Vier onderdelen wegen het zwaarst voor een klein team:
- LLM01 Prompt Injection — tekst van een gebruiker of uit een document verandert de instructies van het model.
- LLM02 Sensitive Information Disclosure — het model geeft gegevens terug die de gebruiker niet mag zien.
- LLM06 Excessive Agency — het model kan zonder grenzen e-mails versturen, records wijzigen of tools aanroepen.
- LLM10 Unbounded Consumption — geen limiet op verzoeken of kosten, zodat één gebruiker de modelrekening kan opdrijven.
De andere zes zijn LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses en LLM09 Misinformation. Voor teams die modellen bouwen of aanpassen voegt NIST SP 800-218A (juli 2024) praktijken voor generatieve AI toe aan het SSDF. De modelcontroles vóór de lancering — minimale rechten, een prompt-injectietest en een kostenplafond — staan in de production readiness checklist.
Europese regels die naar deze standaarden wijzen
Geen Europese wet noemt OWASP of maakt ISO 27001 verplicht voor een AI-gebouwd product, maar drie EU-regels vragen beveiligingsmaatregelen die u met een benoemde standaard kunt aantonen.
- AVG (GDPR) artikel 32 vereist “passende technische en organisatorische maatregelen” voor persoonsgegevens, en artikel 25 vraagt gegevensbescherming door ontwerp en door standaardinstellingen. Een benoemde standaard zoals ASVS laat zien wat “passend” betekende; in Nederland houdt de Autoriteit Persoonsgegevens toezicht.
- NIS2 artikel 21, lid 2, onder e gaat over beveiliging bij de aanschaf, ontwikkeling en het onderhoud van netwerk- en informatiesystemen, inclusief de behandeling van kwetsbaarheden. Nederland heeft NIS2 omgezet in de Cyberbeveiligingswet, die sinds 15 augustus 2026 van kracht is (Staatsblad 2026, 187). Organisaties die eronder vallen, leggen deze eisen via contracten bij hun softwareleveranciers.
- De Cyberweerbaarheidsverordening (Cyber Resilience Act) (Verordening (EU) 2024/2847) geldt voor producten met digitale elementen, zoals installeerbare software en mobiele apps. De meldplichten gelden vanaf 11 september 2026 en de hoofdverplichtingen vanaf 11 december 2027. Software die puur als dienst wordt geleverd valt er doorgaans buiten, tenzij het gaat om gegevensverwerking op afstand die een gedekt product nodig heeft om te werken.
De EU AI-verordening reguleert AI-systemen, niet de code die een AI-tool voor u schrijft. Voor een SaaS-product zonder NIS2-klanten is AVG artikel 32 de regel die als eerste geldt; valt u of een klant onder NIS2, of verkoopt u een installeerbare app in de EU, dan komen de andere twee erbij.
Met welke standaard begint u?
De juiste startstandaard hangt af van wie de vraag stelt en welke gegevens het product bevat. Tabel 4 geeft het startpunt voor zes veelvoorkomende situaties van een AI-gebouwd product.
| Situatie | Begin met | Voeg toe wanneer |
|---|---|---|
| Interne tool of prototype met testdata | Bewustzijn van de OWASP Top 10:2025, secret scanning en dependency scanning | Echte gebruikers of echte gegevens komen erbij |
| Persoonsgegevens of betalingen van echte gebruikers | ASVS 5.0 Level 1 overal; Level 2 voor inloggen, toegangscontrole en gegevensverwerking | Een klant stuurt een beveiligingsvragenlijst |
| Beveiligingsvragenlijst van een enterprise-klant | ASVS-reviewverslag plus de Top 10-koppeling als bewijs | De klant vraagt om ISO 27001 of SOC 2 |
| ISO 27001-gecertificeerde klant, of uw eigen certificeringsplan | Procedures voor Annex A 8.25–8.30 met ASVS als benoemde standaard voor veilig programmeren | Een auditor plant een stage 1-audit |
| Product roept tijdens gebruik een AI-model aan | OWASP Top 10 for LLM Applications 2025 bovenop ASVS | Agents krijgen rechten om gegevens te wijzigen |
| Uw organisatie of klant valt onder NIS2; installeerbare app verkocht in de EU | Bewijs voor NIS2 artikel 21, lid 2, onder e en de CRA, opgebouwd uit dezelfde ASVS- en ISO-verslagen | De hoofdverplichtingen van de CRA gelden vanaf 11 december 2027 |
Wij raden af om met ISO 27001-certificering te beginnen om de vragenlijst van één klant te beantwoorden. De vragenlijst gaat over het product, en een reviewverslag op basis van ASVS beantwoordt die vraag direct, terwijl certificering de hele organisatie betreft en een volledige auditcyclus kost.
Welk bewijs u een klant of auditor laat zien
Een klant of auditor accepteert bewijs dat de standaard noemt, het resultaat toont en een datum heeft. Voor een AI-gebouwd product vormen deze zes stukken een praktisch startpakket; individuele klanten kunnen aanvullend bewijs vragen:
- Benoemde basislijn — bijvoorbeeld “OWASP ASVS 5.0.0 Level 1, Level 2 voor authenticatie en toegangscontrole”.
- Geautomatiseerde resultaten — statische analyse (SAST: een scan van de broncode op bekende zwakke patronen), software composition analysis (SCA: een scan van externe packages op bekende kwetsbaarheden) en secret scanning, allemaal van de release die de klant beoordeelt.
- Verslag van de menselijke review — wie reviewde, wanneer, en geslaagd of gezakt per eis-ID; de gids over AI code review legt uit hoe u die review uitvoert.
- Verslag van beveiligingstests — tests op toegangscontrole en misbruikscenario’s voor Annex A 8.29, inclusief een test dat de ene gebruiker de gegevens van een andere niet kan openen.
- Openstaande bevindingen — elk met een eigenaar en een streefdatum.
- Overzicht van AI-tools — één regel met de gebruikte AI-codetools en de Annex A 8.4-regel over wat met ze gedeeld mag worden. Teambrede regels voor AI-tools komen aan bod in AI code governance.
Scans van het prototype blijven bruikbaar als historisch bewijs, maar vervangen geen controles op de release die wordt beoordeeld. Is een verslag ouder dan die release, voer de controle dan opnieuw uit voordat u het pakket verstuurt.
Hoe Sunbytes AI-gebouwde producten beoordeelt voor beveiligingsvragen
Een beveiligingsstandaard maakt van “we denken dat de code veilig is” een lijst die een klant kan controleren. AI-codetools kunnen de code schrijven en de scanners draaien; een persoon moet het product nog steeds tegen die lijst toetsen.
De AI-built product review van Sunbytes helpt teams te zien waar de beveiligingsmaatregelen, de code en de technische opzet van hun product aandacht nodig hebben vóór de lancering of breder gebruik. De review begint met een afgesproken scope over de relevante onderdelen: beveiliging, architectuur, kritieke workflows, deployment en onderhoudbaarheid. Bevindingen uit engineering en security worden in begrijpelijke taal uitgelegd, met onderbouwend bewijs en een geprioriteerd actieplan.
Vraagt een klant om verificatie tegen specifieke OWASP ASVS-eisen of om een aparte beveiligingsbeoordeling, dan legt u die eisen vast tijdens het afbakenen van de scope. Zo blijft het bewijs gericht op de vraag van de klant, zonder dat een algemene productreview als certificering wordt gepresenteerd.
Voor een controle van alleen de beveiliging van de code zelf voert het cybersecurityteam van Sunbytes een secure code review uit. Beide diensten vallen onder het ISO/IEC 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes en steunen op ruim 300 opgeleverde projecten.
Wacht een beveiligingsvragenlijst of een lanceringsdatum op dit antwoord? Start met een AI-built product review.
