Wordt software veiliger met AI-coding agents als Claude Mythos — of juist onveiliger?

Elke nieuwe golf tooling in softwareontwikkeling roept dezelfde tweedeling op. De een ziet hefboomwerking. De ander ziet risico.
Claude Mythos zit precies op die grens. Het is niet zomaar weer een coding assistant. Het leest omvangrijke codebases, vindt kwetsbaarheden, en gaat soms nog een stap verder — door uit te zoeken hoe die zwakke plekken daadwerkelijk misbruikt zouden kunnen worden.
Die combinatie maakt het interessant, en tegelijk ongemakkelijk om over na te denken.
Als securitywerk begint te schalen
Een van de hardnekkigste beperkingen in security is altijd tijd geweest.
Codebases groeien, systemen raken sterker verweven, en het aantal mogelijke problemen neemt sneller toe dan teams realistisch kunnen nakijken. Zelfs met toegewijde security engineers blijft er simpelweg een hoop oppervlak onbekeken.
Tools als Mythos veranderen die dynamiek. Ze bewegen zich snel door een systeem, toetsen aannames en brengen patronen boven water waar je handmatig veel langer over zou doen. Voor teams die hun securityproces al redelijk op orde hebben, is die dekking waardevol. Gaten worden eerder zichtbaar, en er is meer context over waar het risico werkelijk zit.
Het verlaagt ook de drempel. Developers die geen securityspecialist zijn, kunnen nu zinnige vragen stellen en er zinnige antwoorden op krijgen. Daardoor schuift het securitygesprek dichter naar het dagelijkse ontwikkelwerk, in plaats van dat het een aparte fase of een apart team blijft.
Het backlogprobleem verdwijnt niet
Problemen vinden was nooit de enige uitdaging.
De meeste teams hebben al een backlog van bekende kwetsbaarheden, en die worden lang niet altijd snel opgelost. Sommige fixes zijn rechttoe rechtaan. Andere raken kritieke delen van het systeem en vragen om voorzichtigheid, waardoor ze blijven liggen.
Gaat het ontdekken sneller, dan krimpt die backlog niet vanzelf. Hij groeit.
In plaats van een handvol bevindingen houd je er misschien honderden over. Veel ervan terecht. Veel ervan de moeite van het oplossen waard. En allemaal concurreren ze met productwerk en lopend onderhoud.
Verander je niets aan hoe je het oplossen organiseert, dan verandert betere detectie in een ander soort druk. Meer zicht, maar niet per se meer capaciteit om er iets mee te doen.
Hetzelfde gereedschap werkt beide kanten op
Er zit nog een laag aan die zich lastig laat negeren.
De capaciteiten waarmee verdedigers systemen beter doorgronden, laten zich net zo goed andersom inzetten. Een codebase verkennen, zwakke plekken vinden, ze aan elkaar knopen — dat is geen exclusief verdedigingswerk.
Naarmate deze tools toegankelijker worden, daalt het expertiseniveau dat je nodig hebt om bepaalde aanvallen uit te voeren. Je hoeft niet elk detail van een systeem te begrijpen als je een model de verkenning kunt laten doen.
Tegelijk krijgen verdedigers vergelijkbare mogelijkheden. Beide kanten gaan sneller.
Security kende altijd al die scheve balans, waarin kleine voordelen grote gevolgen hebben. Tools als Mythos halen die dynamiek niet weg, maar ze veranderen wel hoe snel hij zich voltrekt.
Codegeneratie voegt nog een laag toe
Dan is er nog de vraag hoe deze systemen de code beïnvloeden die überhaupt geschreven wordt.
AI-ondersteund ontwikkelen is al gemeengoed. Het versnelt implementeren, vult boilerplate in en helpt bij patronen die je niet kent. Maar het verandert ook hoe zorgvuldig er nagekeken wordt. Als iets snel gegenereerd is en er redelijk uitziet, accepteer je het makkelijker zonder verder te graven.
Daar sluipen subtiele problemen in. Niet zozeer voor de hand liggende bugs, maar aannames die net niet kloppen, randgevallen die niet helemaal afgedekt zijn, of afhankelijkheden die onverwacht risico meebrengen.
Zo ontstaat er een kringloop waarin AI de code helpt maken én helpt analyseren, terwijl het menselijk begrip er ergens tussenin hangt. Wordt die tussenlaag dunner, dan wordt het systeem lastiger te doorgronden, ook al ziet elk onderdeel er op zichzelf prima uit.
En er speelt een meer speculatieve zorg die in onderzoekskringen langskomt: het idee dat zeer capabele modellen wijzigingen kunnen introduceren die technisch correct zijn, maar zonder vergelijkbare tooling nauwelijks volledig te beoordelen. Daar lopen de meeste teams vandaag niet tegenaan, maar het hoort bij het bredere gesprek.
Waar de rol van de developer verschuift
Naarmate deze tools meer kunnen, verschuift de aard van het werk.
Er gaat minder tijd zitten in het schrijven van rechttoe rechtaan code. Er gaat meer tijd zitten in beslissen wat er überhaupt zou moeten bestaan, hoe onderdelen op elkaar inwerken, en of voorgestelde wijzigingen in deze context wel hout snijden.
Security past in diezelfde verschuiving. In plaats van handmatig op problemen jagen, gaat het werk meer over bevindingen duiden, impact inschatten en bepalen wat nú aandacht nodig heeft en wat later kan.
Dat vraagt een ander soort aandacht. Context wordt belangrijker dan ruwe output. Weten hoe een systeem zich hóórt te gedragen telt zwaarder dan snel een fix kunnen bouwen.
Worden systemen hier veiliger van?
Het antwoord is niet bepaald schoon.
In omgevingen waar teams security al serieus nemen, rekken deze tools op wat mogelijk is. Meer dekking, sneller feedback, minder blinde vlekken. Dat duwt de boel de goede kant op.
In omgevingen waar snelheid het wint van begrip, kan de uitkomst er anders uitzien. Er gaat meer code de deur uit, er stapelen zich meer wijzigingen op, en problemen worden sneller gevonden dan ze opgelost kunnen worden. Op termijn wordt het systeem daar lastiger van te onderhouden en te doorgronden.
De tooling duwt uit zichzelf geen kant op. Ze versterkt wat er al ligt.
Wat in de praktijk lijkt uit te maken
Teams die hier waarde uit halen, behandelen het meestal als onderdeel van een breder proces, niet als vervanging ervan.
Ze kijken wijzigingen nog steeds zorgvuldig na. Ze denken nog steeds na over de grenzen tussen services. Ze beslissen nog steeds bewust wat wanneer gerepareerd wordt.
Het verschil is dat ze meer informatie hebben om mee te werken, en hun systemen kunnen verkennen op manieren die eerder niet haalbaar waren.
Teams die het zwaar hebben, leunen op de output zonder de gewoontes eromheen te bouwen. Daar wordt het gat zichtbaar.
Een verschuiving die je lastig kunt negeren
Lange tijd betekende betere beveiliging: meer problemen vinden en ze sneller oplossen.
Die vergelijking begint te kantelen. Problemen vinden wordt makkelijker. Soms bijna triviaal. Het lastige is alles wat daarna komt: bepalen wat ertoe doet, veilig wijzigen, en het systeem begrijpelijk houden terwijl het meegroeit.
Tools als Claude Mythos halen die complexiteit niet weg. Ze maken hem een stuk zichtbaarder.

Softwareontwikkeling ontmoeilijken
Laat ZEN Software uw softwareontwikkeling analyseren en optimaliseren.
Lees ook:

Waarom IAM misschien wel het gevaarlijkste deel van je cloud is
Vraag iemand waar het risico in de cloud zit, en je krijgt meestal dezelfde antwoorden: blootgestelde databases, verkeer...

Als AI de juniorrollen overneemt, waar komen de seniors dan vandaan?
Er zit een stille tegenstrijdigheid in hoe we over AI in softwareontwikkeling praten. Aan de ene kant is er enthousiasm...

Wordt software veiliger met AI-coding agents als Claude Mythos — of juist onveiliger?
Elke nieuwe golf tooling in softwareontwikkeling roept dezelfde tweedeling op. De een ziet hefboomwerking. De ander ziet...

Secrets roteren in productie zonder downtime: veilig én in de lucht blijven
Goede securitypraktijk zegt: “roteer je secrets regelmatig”. Maar draait je applicatie in productie, dan is dat makkelij...

Bugs fixen in het tijdperk van AI: coding agents gebruiken zonder je codebase in spaghetti te veranderen
Bugs fixen is veranderd. Niet omdat bugs anders zijn. Het zijn nog steeds null references, race conditions, aannames di...

AI-moeheid in development: waarom constante AI-hulp je kan uitputten
Er zit een herkenbaar patroon in developers die een tijdje met AI-tools werken: eerst nieuwsgierigheid, dan een periode ...
