Hoe maak je jouw vibe-gecodeerde app ISO-compliant
(Met gratis vibe-naar-compliance checklist)
Compliance klinkt misschien als een vibe-killer, maar het is niet per se de vijand van snelheid — het is de enabler van vertrouwen. Vertrouwen dat jouw software veilig is, privacygevoelige informatie beschermt en geen kwetsbaarheden introduceert in jouw organisatie.
Je had het idee.
Je hebt de prompts getypt. Je hebt de prompts verfijnd. Je bent tegen doodlopende wegen aangelopen. Je hebt de hallucinaties ontrafeld. En nu heb je werkende software die interne hoofdpijn kan verlichten of door een klant kan worden gebruikt. Gefeliciteerd!
Maar er is een klein probleempje.
Het snelle prototypen, de vele (vele) prompts en het niet-zo-deskundige teamlid dat je heeft geholpen om dit ding in een paar dagen in elkaar te zetten, nou ja, dat heeft ertoe geleid dat er een paar dingen zijn blijven liggen.
Dat "mooie" stukje code dat werkt (voor nu), moet productiesoftware worden. Het moet veilig zijn, en het moet... nou ja... compliant zijn.
Compliance klinkt misschien als een vibe-killer, maar het is niet per se de vijand van snelheid — het is de enabler van vertrouwen. Vertrouwen dat jouw software veilig is, privacygevoelige informatie beschermt en geen kwetsbaarheden introduceert in jouw organisatie.
Hulp is hier. Hier heeft jouw vibe-gecodeerde app waarschijnlijk steken laten vallen op het gebied van compliance, en dit kun je eraan doen.
De compliance-kloof: wat vibe coding achterlaat
Laten we eerlijk zijn over wat er ontbreekt als je je weg naar een werkende app vibe-codet.
Documentatie? Welke documentatie? Jouw AI-assistent heeft geen ontwerpdocument geschreven. Het heeft niet uitgelegd waarom het voor die databasestructuur of die authenticatiemethode heeft gekozen. Het heeft het gewoon... gedaan. En jij accepteerde het omdat het werkte. Auditors zijn minder onder de indruk van "het werkt."
Traceerbaarheid mag geen mysterie zijn. In een compliant ontwikkelproces kun je een lijn trekken van eisen naar implementatie naar testen. In een vibe-gecodeerde app waren de "eisen" een reeks prompts, de "implementatie" was wat de AI genereerde, en het "testen" was jij die rondklikte totdat er niets meer kapotging.
Beveiliging wordt aangenomen, niet geverifieerd. AI-modellen zijn getraind op veel code. Sommige van die code is geweldig. Sommige heeft kwetsbaarheden die al jarenlang over het internet worden gekopieerd en geplakt. Als je vibe-codet, erf je de beveiligingsaannames die meekwamen.
Wijzigingsbeheer? Die kennen we niet. Je hebt waarschijnlijk je prompts niet onder versiebeheer gezet. Je hebt zeker niet gedocumenteerd waarom je op dinsdagavond om 23:00 uur van aanpak A naar aanpak B bent overgestapt. De code bestaat. De geschiedenis van hoe het daar is gekomen? Dat is een kies-je-eigen-avontuur-roman met ontbrekende pagina's.
Hier is de ongemakkelijke waarheid: auditors hebben papieren sporen nodig. "Het werkt op mijn machine" is geen compliance-strategie.
Welke ISO-normen zijn echt belangrijk?
Voordat we verdergaan, laten we de afkortingensoep ontrafelen. ISO-normen zijn niet allemaal relevant voor elk project. Dit zijn de normen die het meest waarschijnlijk van belang zijn voor jouw vibe-gecodeerde app:
ISO 27001:
Informatiebeveiligingsmanagement Dit is de grote. Als jouw app enige vorm van gevoelige gegevens verwerkt (gebruikersinformatie, bedrijfsgegevens, inloggegevens), dan staat ISO 27001 waarschijnlijk op je radar. Het gaat erom aan te tonen dat je een systematische aanpak hebt om informatie veilig te houden.
ISO 27701:
Privacy-informatiemanagement Zie dit als het privacygerichte broertje van ISO 27001. Als je met persoonsgegevens werkt en moet aansluiten bij de AVG of vergelijkbare regelgeving, dan is deze voor jou.
ISO 9001:
Kwaliteitsmanagementsystemen Minder over beveiliging, meer over consistente kwaliteit. Relevant als jouw app klantgericht is en betrouwbare processen moet aantonen.
ISO 25010:
Softwareproductkwaliteit Een raamwerk voor het evalueren van softwarekwaliteit — betrouwbaarheid, prestaties, onderhoudbaarheid. Handig als je moet bewijzen dat jouw app niet bij elkaar wordt gehouden met ducttape en goede bedoelingen.
Voor de meeste vibe-gecodeerde apps die naar productie gaan, is ISO 27001 de norm die als eerste ter sprake komt. Daar zullen we ons dan ook op richten.
De brug bouwen (zonder de vibe te doden)
Oké, genoeg somberheid. Het goede nieuws is dat je waarschijnlijk niet alles hoeft weg te gooien en opnieuw hoeft te beginnen. Je kunt compliance achteraf toevoegen aan jouw vibe-gecodeerde app. Het kost wat werk, maar het is te doen.
Retroactieve documentatie
Jouw code bestaat. Nu moet je het uitleggen — aan auditors, aan toekomstige ontwikkelaars, aan jezelf over zes maanden wanneer je alles bent vergeten.
Begin met de basis: wat doet deze app? Welke gegevens verwerkt het? Waar gaan die gegevens naartoe? Je kunt tools zoals dependency graph generators gebruiken om de architectuur van je app te visualiseren. Zelfs een handgetekend diagram is beter dan niets.
Maak een "prompt-logboek" als je nog toegang hebt tot je gespreksgeschiedenis met de AI. Het is geen formele eisendocumentatie, maar het laat je denkproces zien. Het laat iteratie zien. Het laat zien dat er beslissingen zijn genomen, zelfs als die om 2 uur 's nachts zijn genomen terwijl je pizza at.
Schrijf achteraf besluitvormingsverslagen. Een eenvoudig sjabloon: "We kozen X vanwege Y. We overwogen Z maar verwierpen het vanwege W." Zelfs als je deze uit je geheugen reconstrueert, is het beter dan stilte.
Beveiligingsverharding
Jouw AI-gegenereerde code heeft een beveiligingscheck nodig. Het goede nieuws is dat je dit niet handmatig hoeft te doen.
Voer static analysis (SAST) tools uit op je codebase. Tools zoals Semgrep, SonarQube of Snyk kunnen veelvoorkomende kwetsbaarheden automatisch identificeren. Los op wat ze vinden. Documenteer wat je hebt opgelost en waarom.
Controleer je dependencies. Jouw app heeft waarschijnlijk meer packages dan je denkt. Genereer een Software Bill of Materials (SBOM) zodat je precies weet wat erin zit. Controleer die dependencies op bekende kwetsbaarheden. Werk de risicovolle bij.
Doe wat basis threat modeling. Het hoeft niet uitgebreid te zijn. Vraag jezelf af: wat kan er misgaan? Welke gegevens kunnen worden blootgesteld? Wat zou een kwaadwillende gebruiker proberen te doen? Schrijf je antwoorden op en wat je hebt gedaan om ze aan te pakken.
Traceerbaarheid opzetten
Je moet lijnen trekken tussen wat de app doet, waarom het dat doet, en hoe je weet dat het werkt.
Koppel je oorspronkelijke prompts (of gereconstrueerde eisen) aan features in de app. Koppel die features vervolgens aan tests die bewijzen dat ze werken. Dit hoeft geen fancy systeem te zijn — een spreadsheet werkt prima.
Introduceer lichtgewicht ticketing, al is het alleen voor jezelf. Elke wijziging krijgt vanaf nu een ticket. Het ticket legt uit wat er verandert en waarom. Dit geeft je een audit trail voor de toekomst.
Ruim je versiebeheer op. Betekenisvolle commit-berichten. Branches voor features. Geen commits meer die alleen "stuff" zeggen. Je git-geschiedenis moet een verhaal vertellen, niet lezen als een mysterieroman.
Kwaliteitspoorten die je niet vertragen
Compliance gaat er niet om je te vertragen — het gaat erom problemen op te vangen voordat ze duur worden. Automatisering is hier je vriend.
Zet een CI/CD-pipeline op als je die nog niet hebt. Laat deze automatisch je tests uitvoeren. Laat deze automatisch je beveiligingsscans uitvoeren. Als iets faalt, stopt de deployment. Dit beschermt je tegen jezelf.
Stel minimale testdekking vast. Je hebt geen 100% dekking nodig. Maar je hebt genoeg nodig zodat je het zou merken als er iets kritisch kapotgaat.
Voeg pre-commit hooks toe die voor de hand liggende problemen opvangen voordat ze zelfs maar in de repository terechtkomen. Linting, formatting, basis beveiligingscontroles. Kleine wrijving die grote hoofdpijn voorkomt.
Jouw ISO 27001 compliance checklist
Hier is een praktische checklist om te zien waar je staat. Wees eerlijk tegen jezelf — een vakje aanvinken betekent niet dat je compliant bent, het betekent dat je compliance kunt aantonen als daarom wordt gevraagd.
[ ] Je hebt gedocumenteerd welke gegevens de app verwerkt en waar deze worden opgeslagen
[ ] Je hebt een inventarisatie gemaakt van third-party dependencies en integraties
Toegangscontrole
[ ] Alleen geautoriseerde personen hebben toegang tot productiesystemen
[ ] Je hebt een proces voor het verlenen en intrekken van toegang
[ ] Beheerderstoegang wordt gelogd en is controleerbaar
[ ] Je gebruikt rolgebaseerde toegang, niet "iedereen is admin"
Gegevensbescherming
[ ] Gevoelige gegevens zijn versleuteld in rust en tijdens transport
[ ] Je weet waar persoonsgegevens zich bevinden en hoe lang je ze bewaart
[ ] Er is een proces voor het afhandelen van verzoeken van betrokkenen (indien van toepassing)
[ ] Back-ups bestaan en zijn getest
Incidentrespons
[ ] Je hebt een plan voor als er iets misgaat
[ ] Iemand is verantwoordelijk voor beveiligingsincidenten
[ ] Er is een manier om te detecteren of er iets is misgegaan
[ ] Je hebt gedocumenteerd hoe je zou communiceren over een datalek
Risicobeoordeling
[ ] Je hebt geidentificeerd wat er mis kan gaan met jouw app
[ ] Je hebt de waarschijnlijkheid en impact van die risico's beoordeeld
[ ] Je hebt maatregelen getroffen voor de grootste risico's
[ ] Je bekijkt en actualiseert dit periodiek
Ontwikkelpraktijken
[ ] Je kunt uitleggen hoe code van idee naar productie gaat
[ ] Wijzigingen worden beoordeeld voor deployment
[ ] Er is versiebeheer met een betekenisvolle geschiedenis
[ ] Je hebt omgevingen om te testen voor productie
Risico van derden
[ ] Je weet van welke externe diensten jouw app afhankelijk is
[ ] Je hebt de beveiligingsstatus van kritieke leveranciers beoordeeld
[ ] Je hebt een plan als een belangrijke leverancier een storing of datalek heeft
Wanneer te stoppen met vibing en beginnen met engineering
Hier is de eerlijke boodschap: vibe coding is een tool voor bepaalde situaties. Het is geen permanente werkwijze voor serieuze software.
Tekenen dat jouw project vibe coding is ontgroeid:
- Echte gebruikers zijn er dagelijks van afhankelijk
- Er gaat geld doorheen
- Het verwerkt gevoelige of gereguleerde gegevens
- Je team groeit verder dan alleen jij
- Een storing zou ernstige gevolgen hebben
Op dit punt is het tijd om te schakelen. Dat betekent niet dat je weggooit wat je hebt gebouwd. Het betekent dat je wat je hebt gebouwd behandelt als een prototype en bewust de productieversie engineert. (Wij kunnen daarbij helpen.)
De bottom line
En hé — er is een concurrentievoordeel aan snel EN gecertificeerd zijn. Je concurrenten die nog steeds hun weg door productie-incidenten vibing, zouden het daar waarschijnlijk mee eens zijn.
Voel je je een beetje verloren met compliance? Wij zijn goed thuis in ISO en andere compliance-grootheden.