Wat een geslaagde build werkelijk aantoont

Een groene build bewijst één ding: de controles die je hebt geschreven zijn geslaagd. Over de controles die je niet hebt geschreven zegt hij helemaal niets.

Toen code schrijven nog veel tijd kostte, vond een deel van het denkwerk tijdens het bouwen plaats. Nu kan een werkend prototype er binnen enkele dagen staan. De code is dan sneller klaar dan de analyse van wat ermee mis kan gaan. Het team heeft daardoor minder tijd om vóór de release dezelfde risico's te onderzoeken.

Waarom basale controles vaak ontbreken

Het ligt meestal niet aan een gebrek aan kennis. Vrijwel iedere softwareontwikkelaar kan uitleggen wat een negatieve autorisatietest doet.

Toch ontbreekt zo'n controle geregeld. Niemand heeft hem expliciet gevraagd, niemand wacht erop en in een demo is hij niet zichtbaar. De waarde blijkt pas wanneer een incident wordt voorkomen. Daardoor krijgt de controle gemakkelijk minder aandacht dan een functie die direct te zien is.

Bovendien profiteert meestal iemand anders van de controle dan degene die de functie uitrolt. Het ontwikkelteam levert de functie op, terwijl een ander team later de gevolgen van een incident moet opvangen.

Een geslaagde testset is niet genoeg voor een releasebesluit. Leg ook vast welke risico's door een test zijn afgedekt en welke nog niet zijn onderzocht.

De minimale controles vóór een release

Een bruikbare poort is kort en concreet. Geen document. Een verzameling dingen die waar moeten zijn en die iemand kan controleren.

Twee daarvan wegen bijzonder zwaar: een verzoek als uitgelogde gebruiker en een verzoek vanuit de verkeerde tenant. In beide gevallen mag geen beschermde informatie terugkomen. Zonder zulke tests is autorisatie alleen een ontwerpkeuze, geen aangetoonde eigenschap van het systeem. Een knop verbergen in de interface is dan niet genoeg.

Dekkingspercentages zijn hier een zwakke maat voor. Een percentage vertelt je hoeveel code er tijdens de tests langskwam, niet of het betaalpad, het autorisatiepad of het migratiepad ertussen zaten. Stuur op risico, niet op het getal.

Migraties verdienen een afzonderlijke controle. Het terugzetten van de applicatie maakt een destructieve datamigratie niet ongedaan. Terugrollen en een herstellende migratie uitvoeren zijn twee verschillende plannen. Dat onderscheid moet vóór de release duidelijk zijn.

Leg in de pull request vast welke controles zijn uitgevoerd, welke punten nog openstaan en wie het resterende risico heeft geaccepteerd. Een bevinding is pas afgehandeld als zij is opgelost of als een bevoegd persoon het risico expliciet heeft geaccepteerd.

Deze aanpak sluit aan op het Secure Software Development Framework van NIST, dat verificatie en het afhandelen van kwetsbaarheden in het ontwikkelproces plaatst.³ OWASP ASVS biedt een toetsbare catalogus van beveiligingseisen voor applicaties en dus geen enkel dekkingscijfer.⁴ De Secure by Design-richtlijn van CISA voegt de organisatorische verantwoordelijkheid toe: beveiliging hoort een kernvoorwaarde van het product te zijn en geen kostenpost die naar de gebruiker wordt doorgeschoven.⁵

Hoe AI het dreigingsbeeld verandert

Eén categorie controle is werkelijk nieuw, en die gaat niet over modelkwaliteit.

Zodra een product documenten, webpagina's, e-mails of tooluitvoer leest, is die inhoud onbetrouwbare invoer. Dat geldt ook voor stukken die eruitzien als instructies aan het model. De OWASP-richtlijn voor LLM-toepassingen zet promptinjectie precies daarom bovenaan.¹ De richtlijn voor agentische toepassingen uit 2026 verbreedt het risico naar onveilig toolgebruik, te ruime autonomie en onveilige communicatie tussen agents.⁶

Forenta behandelt gekoppelde context daarom als extern bewijs en niet als systeeminstructie. De precieze filtering en aansturing blijven intern. De publieke claim is kleiner en toetsbaar: externe inhoud krijgt geen bevoegdheid alleen omdat een taalmodel die kan lezen.

De ontwerpregel eronder is eenvoudiger dan hij klinkt: houd buiten het model wat deterministisch kan worden afgedwongen. Autorisatie, bedragen, limieten, statusovergangen en bedrijfsregels horen in code. Interpreteren, classificeren en genereren is waar het model voor is. Alles met echt gevolg, dus publiceren, geld, verwijderen of persoonsgegevens, krijgt een menselijke poort. Daar komt het NIST-profiel voor generatieve AI ook op uit.²

Kleine wijzigingen zijn eenvoudiger te controleren

Een kleine wijziging is eenvoudiger te beoordelen en terug te draaien. Laat elke taak daarom eindigen met een uitvoerbare controle, bijvoorbeeld een test, build of script dat een eenduidige uitkomst geeft. Dat levert bewijs op in plaats van alleen de mededeling dat het werk klaar is.

Dat is extra belangrijk wanneer een agent code schrijft. Een agent kan ook succes melden wanneer de uitkomst niet klopt. Alleen een uitvoerbare controle maakt het verschil zichtbaar. De agent moet die controle zelf kunnen uitvoeren, anders ontbreekt de terugkoppeling tijdens het werk.

De standaard voor releases van Forenta

Forenta past hetzelfde principe toe op het organisatieproces: operationele waarborgen worden buiten het taalmodel afgedwongen. Een blokkerend risico blijft zichtbaar, een ongeldige review wordt geen gewone uitkomst en verplichte controlepunten kunnen een faseovergang tegenhouden.

Een bevoegd persoon kan van het advies afwijken als de projectcontext daarom vraagt. De reden en het oorspronkelijke advies blijven in het auditspoor staan. Zo blijft de uiteindelijke bevoegdheid bij mensen zonder dat het proces zijn eigen geschiedenis kan herschrijven.

Deze aanpak maakt zichtbaar of code alleen heeft gedraaid of ook aantoonbaar aan de gestelde voorwaarden voldoet. Juist dat maakt gecontroleerd versnellen mogelijk.